# OpenPDC - openHistorian : any 'failover' option/mechanism for the STTP connection string? **URL:** \ **Category:** openHistorian\ **Created:** [October 20, 2022, 1:02pm UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111 "2022-10-20T13:02:40Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Korunekosama](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/korunekosama/32/708_2.png) [@Korunekosama](http://discussions.gridprotectionalliance.org/u/Korunekosama)\ **Post date:** [October 20, 2022, 1:02pm UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/1 "2022-10-20T13:02:41Z")
Hello, I am building an environment with the following characteristics: - 2 openPDC servers each receiving the same C37.118 stream as input from a third-party PDC. With a ‘share’ of the MySQL openPDC database between these two servers (using Windows DFSR), I managed to have a sort of active/active server configuration. - 1 openHistorian server connected to one of the two openPDC servers arbitrarily designated as ‘the primary openPDC source server’, in STTP. I manage to manually switch the openHistorian server data feed from one openPDC server (the ‘primary’ declared server) to the other ; by changing the IP address of the source openPDC server in the concentrator device STTP connection string declared in openHistorian. I’m happy because the measurements in openHistorian stand ‘consistents’ even if the input STTP stream coming from the primary or secondary openPDC server (no duplicated measurements or loss in the data feed when switching from one to the other). The last point I would like to improve is the manual aspect of this toggle in openHistorian’s feed. I would like to know if there is an option to perform this data source switch from one to the other of the two openPDC servers automatically; for example on the fail of openHistorian to connect to the one declared as being the primary one (server=). for example a string connection parameter like failover\_server=XXX.XXX.XXX.XXX:7165 If the main server would become available again after switching to the failover one (primary server finally came back in line after a certain delay); then the connexion would automatically switch back to it … Thank you very much for your answer. Have a nice day, Regards, Stephane. ---
**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\ **Post date:** [October 28, 2022, 1:30am UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/2 "2022-10-28T01:30:56Z")
This is already built-in, you can specify as many servers as you want using a comma, for example: `server=machine1:7165,machine2:7165,machine3:7165` Just put them in priority order. Thanks! Ritchie ---
**Author:** ![Korunekosama](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/korunekosama/32/708_2.png) [@Korunekosama](http://discussions.gridprotectionalliance.org/u/Korunekosama)\ **Post date:** [October 28, 2022, 1:50pm UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/3 "2022-10-28T13:50:00Z")
Hello Ritchie ! Thanks a lot for the quick reply. I hoped that there would be a ‘hidden’ switch or a trivial trick to make it ; but did not imagine that it would already built-in and in a so simple way. Perfect ! Regards, Stephane. ---
**Author:** ![Janio\_Leonardo\_Los](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/janio_leonardo_los/32/1174_2.png) [@Janio\_Leonardo\_Los](http://discussions.gridprotectionalliance.org/u/Janio_Leonardo_Los)\ **Post date:** [November 23, 2023, 2:33pm UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/4 "2023-11-23T14:33:38Z")
This feature is valid for C37118 connections on OpenPDC? I have 2 links from the same PMU and I want have an automatic faillover when the principal link is down to the another link. It is the same configuration? ---
**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\ **Post date:** [November 26, 2023, 5:41am UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/5 "2023-11-26T05:41:39Z")
Yes, any TCP connection including IEEE C37.118. ---
**Author:** ![Korunekosama](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/korunekosama/32/708_2.png) [@Korunekosama](http://discussions.gridprotectionalliance.org/u/Korunekosama)\ **Post date:** [November 29, 2023, 10:02am UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/6 "2023-11-29T10:02:03Z")
Hello ! I’ve also noticed that if (when) the first (primary) declared PDC is back online, the connection does not swap back automatically to it ; and stays on the secondary PDC (failover) declared. Regards ---
**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\ **Post date:** [December 3, 2023, 7:10am UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/7 "2023-12-03T07:10:22Z")
That is true - it does not automatically monitor for primary connection state status. It would only (currently) reconnect to primary when it loses connection to backup. We could setup a slow monitor (like check once a minute, by default) for primary connection status in the background which would make sense in the case where you have two connections (primary / backup) - but what about cases when you have 3, 4, or more connections defined? Have any thoughts or suggestions? Thanks! Ritchie ---
**Author:** ![Korunekosama](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/korunekosama/32/708_2.png) [@Korunekosama](http://discussions.gridprotectionalliance.org/u/Korunekosama)\ **Post date:** [December 5, 2023, 4:07pm UTC](http://discussions.gridprotectionalliance.org/t/openpdc-openhistorian-any-failover-option-mechanism-for-the-sttp-connection-string/1111/8 "2023-12-05T16:07:29Z")
Hello Ritchie, I finally not use this function because I’ve implemented an active/passive mode ; using a FQDN to manually swap from the primary server to the backup one ; as the connection string only uses this FQDN name instead of IP adresses. The reason is that I’ve deported some openPDC files (logs, archive files, reports, statistics …) on an online NAS storage shared by the two servers ; and I don’t want both of them access to it at the same time (which could make some ‘locked files’ access issues). Regards, Stephane.