# Historian splitter -\> remote history provider + local database history provider **URL:** \ **Category:** Ignition\ **Tags:** database, ignition81\ **Created:** [April 22, 2024, 10:11pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245 "2024-04-22T22:11:08Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Joe\_Chlimoun](https://avatars.discourse-cdn.com/v4/letter/j/54ee81/32.png) [@Joe\_Chlimoun](https://forum.inductiveautomation.com/u/Joe_Chlimoun)\ **Post date:** [April 22, 2024, 10:11pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/1 "2024-04-22T22:11:08Z")
I have two stations, each running their own gateway, and I want to ensure that historical data is synchronized between them in case one goes offline for a brief period. Can I set up a local historical database on each one and configure a remote history provider to cross between them, then put those both in a splitter with store+forward? The idea here is that if station 1 is down, station 2 will buffer data that needs to be written to station 1's local database, so when station 1 comes back online it will forwarded and brought up to date. Queries locally would be fine if the store/forward will work. My concern is that they'll both be logging at the same time, so I presume it would create duplicate entries. If the gateway name is recorded, then that would keep the entries unique, but then would the offline station benefit from the store/forward activity, or will it still have a gap for data it can't see because it's under the other gateway's name? Redundant gateways is not an option. The fact that the redundant partner can't start up from a cold boot after the failure of the primary is a deal breaker. I can't have a redundancy mechanism that turns a recoverable failure like a power fluctuation into a unrecoverable failure. ---
**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:** [April 22, 2024, 10:14pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/2 "2024-04-22T22:14:09Z")
Sounds like you are trying to cobble together redundancy, where you could (should) just use redundancy. (Save $$ on the license, too.) I suspect you won't get the desired behavior from history splitters. ---
**Author:** ![Joe\_Chlimoun](https://avatars.discourse-cdn.com/v4/letter/j/54ee81/32.png) [@Joe\_Chlimoun](https://forum.inductiveautomation.com/u/Joe_Chlimoun)\ **Post date:** [April 22, 2024, 10:16pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/3 "2024-04-22T22:16:05Z")
I thought someone would say that after I posted, so I updated my post to say redundancy, as Ignition implements it, is not an option. I wish I could go that route, but a crippled secondary isn't truly redundant, it's just a failover. ---
**Author:** ![Joe\_Chlimoun](https://avatars.discourse-cdn.com/v4/letter/j/54ee81/32.png) [@Joe\_Chlimoun](https://forum.inductiveautomation.com/u/Joe_Chlimoun)\ **Post date:** [April 22, 2024, 10:26pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/4 "2024-04-22T22:26:28Z")
I would rather deal with duplicate data than a failure to sync, so if there's a way to do that I would. ---
**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:** [April 22, 2024, 10:55pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/5 "2024-04-22T22:55:56Z")
> [@Joe\_Chlimoun](#): > > The fact that the redundant partner can't start up from a cold boot after the failure of the primary is a deal breaker. I don't understand what you mean by this. A backup gateway can absolutely 'cold start' and assume responsibility if the primary is not available. ---
**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:** [April 22, 2024, 10:57pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/6 "2024-04-22T22:57:20Z")
> [@Joe\_Chlimoun](#): > > but a crippled secondary I'd like to know what aspect of Ignition redundancy makes you call it "crippled". ---
**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:** [April 22, 2024, 11:05pm UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/7 "2024-04-22T23:05:26Z")
> [@Joe\_Chlimoun](#): > > a remote history provider to cross between them This will die when a station dies, so you still won't get that data. Each station gateway would need its own connections to your PLCs. With Ignition redundancy, both master and backup make connections, but inactive gateway isn't polling all the time. Separate stations can't do this. ---
**Author:** ![Joe\_Chlimoun](https://avatars.discourse-cdn.com/v4/letter/j/54ee81/32.png) [@Joe\_Chlimoun](https://forum.inductiveautomation.com/u/Joe_Chlimoun)\ **Post date:** [April 23, 2024, 1:05am UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/8 "2024-04-23T01:05:14Z")
Maybe I misunderstood the redundancy functionality… I thought I read somewhere that a server with a redundancy license can’t boot up and function in the absence of the primary server. After I got that in my head, I didn’t bother going down that path. If I’m wrong about that, then that could potentially make this work more smoothly. ---
**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:** [April 23, 2024, 11:30am UTC](https://forum.inductiveautomation.com/t/historian-splitter-remote-history-provider-local-database-history-provider/89245/9 "2024-04-23T11:30:38Z")
Yeah, you're wrong about that. You may be confusing the issue that **browsers** cannot get started pointing at a dead master gateway. Vision Client Launchers and Perspective workstation can be given both gateway addresses for startup, so they work regardless. Any client, once started, will gather the address of the redundant peer for its connection, and switch over after a failure time. Perspective clients may have to re-authenticate, depending on their Identity Provider's capabilities. Do note that **designers** do not connect to backup servers. That is the key thing you give up for the half-price license.