Reduncy and backup databases

The setup:
Redundant SQLTags drivers (ie: external to Ignition driven by a different product)
Redundant 7.3.1 gateways
Redundant history databases

So while testing this setup I’m trying a number of failure modes, first up is failed SQLTag databases.
Switch off main SQLTags database (and driving app) and everything keeps working just fine. Cool!
Restore.
Make a change to a tags meta data through Ignition.
Switch off main SQLTag database (and driving app) and change is still there in Ignition. Cooler!
Check backup db for change. Not there :frowning: Not so cool.
Make another change to Tag meta data. Now the new change and the last one are in the backup. Ok.
Restore main SQLTag DB.
Ignition still has the new change. main DB has the old change :frowning:

So, a backup database has to be externally synced with the main db and somehow the main db has to be externally synced with the backup after its been restored.

Is there any way that the gateway can be made to write to both databases?

edit: After a system restart, the gateway has the correct (read last) information.
When does the gateway load the SQLTag data from an external tags db?

So, you had your two database connections, with A set to failover to B, correct?

Ignition monitors the tables for changes all the time, but through queries like “where configchange>X” where X is the last time it checked. So, when you switch back to a different DB, it’s possible that changes there might not get noticed, because they happened “in the past” from Ignition’s point of view.

As a work around, you might try setting configchange to CURRENT_TIMESTAMP to force a full reload when you detect that the db connection state changes (you could use the new Gateway system tags and a change script, or transaction group). Obviously, we should probably do something similar in code. Right now the external tag driver doesn’t really have much logic in it to handle db connection state changes.

Regards,

Hi Robert,

When you say redundant Databases, have you setup some replication for the two databases to synch?
If the Databases are synched (via replication) you shouldn’t have a problem.

P.s.: if you are using mysql for replication please note that the setup has recently changed on accomplishing this. The configuration in the my.inf is now different to previous versions.
Also some of the commands have changed.

Regards
Sascha

Hi Sascha

No the databases are not synced in any way. I’m finally getting around to playing with redundancy and just set it up. One thing that is not mentioned above is I only have two machines. Each has a Windoze OS with a linux VM. The linux VM has the SQLTags db, the Windoze has the Ignition gateway and a postgresql history db. (There are reasons for this setup the I don’t want to go into. It’s what I have to work with)

@Colby I can work around the Meta data issues to ensure that the backup stays in sync. Is there a quick way to tell if a database is failed over? (it’s ok to tell me to RTFM)

How does the history DB work? Given the above config, if the master gateway goes down chances are the main history DB will be down as well. In this case I would want the backup gateway to store all the changes until the main database comes backup. Possibly several days later.

I found the gateway database tags. What does ‘available through failover’ mean. It seems like it’s just reflecting the available tag.

The database failover mechanism is transparent to the application. If a connection is set up to failover, and the main connection is down, trying to open a connection on it will automatically open one on the secondary connection. “Available Through Failover” means that the main connection is down, but the failover is up, so if you try to connect to the main, it’ll work.

If both available and available through failover are false, it means both connections are down.

Hope this helps,

Then why is ‘available through failover’ set on non redundant databases?