Hi Malcolm,

using a license server is recommended in multi server deployments. But that will not alleviate the issue that users need to login again after a failover. The issue here is that the webgateway loses the login connection to the iris instance on failover and needs to reauthenticate and reestablish. In case of a stateless application this has no user impact, but in case of a non-stateless application the user needs to reauthenticate and all data in flight is lost. 

To resolve this issue you should consider going to a multi-tier setup with appservers using ECP.   
Highlevel design:
webserver(webgateway) connects to
appserver(authenticates and serves the application)
connects to mirror via ecp

ECP is mirror aware and will failover transparently for the appservers. So users stay logged in and don't notice the failover.

Caveat: This only works if the failover is fast and happens before the appservers do any ECP operation and the ECP connection then times out.

refer to: Distributed Cluster

Hi,

a 404 error usually comes from Apache. As we don't know your Apache setup its difficult to advise. It might be that you need to add additional config to allow the new path to be accessible.
Also seeing you call this using a port number other than 80/443, i guess you are using still using PWS, which is not supported for production loads.

It would be good to understand what versions you are talking about. You marked this s IRIS2024.1 but you are talking about Cache odbc drivers. Also it would be good to know which licenses you are using as you are talking of a paywall... Usually IRIS is not limited if you are using a full license. Only limitations in using community are resources, connections and access to some enterprise level protocols (like ECP, Sharding, API Manager). 

Hi Norman,

we need to seperate 2 areas of fragmentation.
1. filesystem/OS level fragmentation
     nothing that we can do anything about it except running your trusted defrag if the filesystem has one and actually is in need of defragging.
2. database/global fragmentation:
     This is a very interesting topic, usually nothing needs to be done for an IRIS database, IRIS is pretty good in managing global block density. (refer to https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...)

You can use the output of an integrity check to see how your global density is per global in the database. Both defrag and compact operations are non-destructive and non interruptive, so even if they don't finish they can just be started again and will continue on.

Hi Scott,

Check mirror monitor if all databases are caught up on the backup. Or is there one database that is stuck on dejournaling because of that journal file?

Usually happens if the the backup is out of sync for a long time and the file got corrupted/deleted and is no longer available on the Primary or other mirror members.

Two option that i know of here is to 1. restore that file from backup and supply it in the folder that BACKUP complains about. Or rebuild the backup from your primary.

Hi,
Couple of things to check.

Is there any difference in Server design? .e.g. number of disks, scsi controllers, volume/storage distribution etc
Is the VM definition the same? e.g. storage driver versions (generic scsi controller vs hyperV SCSI controller)
Is the OS on the host and in HyperV the same? 
Is the storage provider design the same? 
Is the IRIS config the same (i.e. cpf file), especially are below settings present?

[config]
wduseasyncio=1
asyncwij=8

I guess both IRIS versions are the exactly the same build although i never heard that to affect disk performance.