# Ignition Redundance and Database failover

**URL:** <https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008>\
**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:** 1\
**Showing post:** 4

<div class="post-metadata">

**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")

</div>

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 …

---

_[View the full topic](https://forum.inductiveautomation.com/t/ignition-redundance-and-database-failover/60008)._