I setup a Hot Spare server that has all the database tables being syncd through replication and all the files being syncd with rsync so in the even the primary server goes down I just have to flip the dns setting to the hotspare.
I was wondering though, wouldn’t it be wise to turn the cron task that Suite runs every minute off on the hot spare and only turn it on if I’m switching over to it. So far it seems to not create a problem but I’m wondering if there could be conflicts caused such as reading inbound email into cases. With the DB and files being syncd from the production server, anything the cron even did on the production server that modified any database tables or files will already be in the updated files being syncd. So theoretically if the Hot Spare isn’t being used there really shouldn’t be anything the cron even needs to be doing.
Hello @jcrist
how did you do the db replication?
dump, rsync, restore via cron?
Or master / slave replication?
Usually on the hot standby (or hot spare) server, you’d do multiple changes for a failover / swap scenario:
- dns (as you wrote already)
- deactivate crons
- (to be very safe) change the SMTP settings
As long as you don’t have any logic, running through the scheduler, you could keep your crons switched on.
But if you have any logic (like cases / email campaigns etc.) then your hot standby is suddenly doing things actively (not just waiting there for the worst case szenario).
It’s the first time I’ve thought about this, but to me it would make sense to keep the crons turned off in the spare server.
The database sync would take care of moving over anything that the crons do in the primary server.
And it would avoid any other spurious changes that actually take your servers out of sync. The spare server shouldn’t have any “initiative”…
cron off.
You never know if there is a workflow that adds +1 at midnight, and with 2 crons running you may end up adding +2.