# Ignition Redundance and Database failover **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [May 25, 2022, 1:50pm UTC](https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008 "2022-05-25T13:50:18Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Dustin\_VanKeuren](https://avatars.discourse-cdn.com/v4/letter/d/b782af/32.png) [@Dustin\_VanKeuren](https://forum.inductiveautomation.com/u/Dustin_VanKeuren)\ **Post date:** [May 25, 2022, 1:50pm UTC](https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008/1 "2022-05-25T13:50:18Z")
Looking for some ideas, or perhaps best practice. I am working on a system with a redundant pair of Ignition servers. Each server has its own SQL server instance. As I was setting this up, I was wondering about the best way to set up the database failover. The database is nothing fancy, so I opted for basic availability groups in SQL Server 2019 (acts like a failover pair in earlier versions). Problem is, the database will most likely not fail over at the same time as Ignition, unless the server itself dies or loses network. Just curios how others have approached this situation. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 25, 2022, 2:49pm UTC](https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008/2 "2022-05-25T14:49:53Z")
> [@Dustin\_VanKeuren](#): > > Each server has its own SQL server instance Ewww! > [@Dustin\_VanKeuren](#): > > basic availability groups in SQL Server 2019 (acts like a failover pair in earlier versions). I'm not terribly familiar with these options, but my customers using SQL Server do the DB failover completely separate from Ignition failover. Both Ignition master and backup point at the SQL Server "cluster". ("group" now, I gather?) Of course, this makes sense only when the DB servers are not in the same servers as Ignition. (Could be some common hypervisors, as long as the combinations cover all redundancy requirements.) ---
**Author:** ![Dustin\_VanKeuren](https://avatars.discourse-cdn.com/v4/letter/d/b782af/32.png) [@Dustin\_VanKeuren](https://forum.inductiveautomation.com/u/Dustin_VanKeuren)\ **Post date:** [May 25, 2022, 3:29pm UTC](https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008/3 "2022-05-25T15:29:48Z")
I am not really familiar with the new methods for this is SQL server. Since their is only one database, and it is small, I was trying to go as simple as possible. I am proceeding with (trying to) setting up the db fail-over and have the Ignition config point to both. Will just have a fail-over connection in Ignition that points to the second SQL server on the secondary node. I know this means that the active HMI and active database will not always be on the same server. We should have virtualized, but didn’t due to cost. This would have been soo much easier. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [May 25, 2022, 3:35pm UTC](https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008/4 "2022-05-25T15:35:18Z")
Going to copy and paste this comment over: > [@Database Redundancy ( Failover Datasource )](https://forum.inductiveautomation.com/t/database-redundancy-failover-datasource/52489/2): > > In almost all scenarios, I would recommend relying on your RDBMS’s failover rather than Ignition’s failover settings. Many RDBMS failover scenarios offer some kind of ‘virtual IP’ or hostname; Ignition connects to that as a client, and if there’s a problem with DB A, queries will automatically be rerouted to DB B. Ignition’s failover is basically the same idea, but it’s “dumb”; all it does is see that a query to DB A failed and immediately attempt to run the same query on DB B. You don’t need …