The topic of HA is interesting. On Trafodion side, there are multiple options (some only available in EsgynDB) the commercial version of Trafodion.
The DB can be running on 2 clusters (or more), and these clusters (of several nodes each) can be ether Active/Passive or active/active. Meaning you can have one cluster active and the other being asynchronously kept in sync via a mechanism like “log shipping”. The same thing that you are thinking with Cassandra replaying commands (logs are replay of mutations). Or you can have active/active configuration, where you guaranty that both (clusters) DB are always in sync, no lag, basically at transaction level, we are making sure rows are committed on both cluster, or transaction is not assumed committed. This comes at a cost in term of performance obviously. And these can be configured on a per table basis, depending of the use case you want. Hope this makes sense, Eric From: Juhan Aasaru <[email protected]> Sent: Thursday, October 24, 2019 11:43 AM To: Victor Romero <[email protected]> Cc: Dev <[email protected]>; Niklas Uhrberg <[email protected]> Subject: Re: Usage of Cassandra in Fineract CN External Hi! I just recently learned that this design would also help on recovering from a disaster. Cassandra can be easily replicated so the risk of loosing all the Cassandra nodes is relatively small. And even if that happens you only loose the commands that are not executed yet (not a huge problem since any command could fail after it is issued). Postgres can also be replicated but at one point the database (and replica) could become corrupt. So you restore it from the recent backup but you face the problem that the backup is probably at least several hours old. To solve the issue you could replay the commands in Cassandra to bring the database restored fromt the backup to the lasest state. The current problem however is that there are some commands that when they get executed, they create other commands as a result (when you replay such a command you will create a command again - although it exists already) So there should be a mechanism in place in Fineract-CN to identify such commands so one could skip executing them during replay (or some other stattegy to deal with this). Juhan Kontakt Victor Romero (<[email protected]<mailto:[email protected]>>) kirjutas kuupäeval N, 24. oktoober 2019 kell 17:28: Yes it is. https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+Project+Structure#FineractCNProjectStructure-cassandra El 24 de octubre de 2019 a las 08:11 AM Niklas Uhrberg <[email protected]<mailto:[email protected]>> escribió: Hi! I didn't pay much attention to the Cassandra database when looking at Fineract CN, but now I read https://cwiki.apache.org/confluence/display/FINERACT/CQRS+in+Fineract+CN and I conclude from this documentation that the only usage of Cassandra is to persist the commands. Furthermore that one and the same database is used in the processing of the commands , i.e. the state changes in the Postgres db as a consequence of a command being processed occur in the same Postgres database used to serve read style requests (since there is only one Postgres db) Is this correctly understood? Best regards Niklas [cid:[email protected]] Niklas Uhrberg Konsult IT Development | Loans & Credit Resurs Bank AB Växel: +46 42 38 20 00 E-post: [email protected]<mailto:[email protected]> Webb: www.resursbank.se<http://www.resursbank.se>
