To provide high availability of data, client is having two data servers. We need to check for existing database connection failure in FME Work flow and pull data from backup data server. If there is no failure at 1st connection, then no need to proceed for backup server. Is there any possibility for this king of approach in FME?
+60- 2940 replies
I would try and use a FeatureReader (Initiated by a Creator) reading from the first connection. Then a NoFeaturesTester, if no output use a second FeatureReader with the second connection. Rejected Feature Handling should be set to Continue Translation. You can set this in the Navigator, under workspace parameters, translation.
+44- Influencer
- 3434 replies
I would try and use a FeatureReader (Initiated by a Creator) reading from the first connection. Then a NoFeaturesTester, if no output use a second FeatureReader with the second connection. Rejected Feature Handling should be set to Continue Translation. You can set this in the Navigator, under workspace parameters, translation.
If using a FeatureReader you can just initiate a second FeatureReader from the rejected port in the event of database connection failure
+63- Celebrity
- 1632 replies
How are you ensuring data is the same across the two databases?
A more robust approach would be to setup the servers in High Availability and have the failover at the database level rather than relying on the clients to switch over in the event of an outage
+63- Celebrity
- 1632 replies
I would try and use a FeatureReader (Initiated by a Creator) reading from the first connection. Then a NoFeaturesTester, if no output use a second FeatureReader with the second connection. Rejected Feature Handling should be set to Continue Translation. You can set this in the Navigator, under workspace parameters, translation.
A question on this approach is what constitutes a failure on the first reader?
- if you get no features returned, is that because the DB failed internally, or an SQL statement returns no features?
- What if it times out? is that because the database is down/running slow, or there is just a lot of data
- Obviously a failed to connect/rejected output is valid failure
+2- Participant
- 9 replies
How are you ensuring data is the same across the two databases?
A more robust approach would be to setup the servers in High Availability and have the failover at the database level rather than relying on the clients to switch over in the event of an outage
Client is maintaining that for high availability. So we are assured by customer that data is same on both servers.
+2- Participant
- 9 replies
If using a FeatureReader you can just initiate a second FeatureReader from the rejected port in the event of database connection failure
Thanks for a simple and clear answer.
+2- Participant
- 9 replies
A question on this approach is what constitutes a failure on the first reader?
- if you get no features returned, is that because the DB failed internally, or an SQL statement returns no features?
- What if it times out? is that because the database is down/running slow, or there is just a lot of data
- Obviously a failed to connect/rejected output is valid failure
Thanks for detailing on many possible cases.