nabassa1323 commented on issue #14172: URL: https://github.com/apache/cloudstack/issues/14172#issuecomment-6017351870
> [@nabassa1323](https://github.com/nabassa1323) I had claudecode create a PR; [#14279](https://github.com/apache/cloudstack/pull/14279). Can you see if this meets your requirements and test it? > > I think this was never implemented seriously and I think we would need to classifyt it as a new feature, though some claims had been made. Hi @DaanHoogland, Thanks for pointing to #14279 — we tested a backport of the change on CloudStack 4.22.1.0 (injected TransactionLegacy into the management fat JAR on both MS). Setup 2 management servers MariaDB GTID, primary + replica db.ha.enabled=true with StaticStrategy replica listed in db.cloud.replicas / db.usage.replicas PR timeouts: connectTimeout=3000, socketTimeout=30000, loadBalanceBlocklistTimeout=30000 Test Stopped the primary MySQL and the management server on the primary site, leaving the other MS (and the replica DB) up. Result The new path is active (com.mysql.cj.jdbc.ha.MultiHostConnectionProxy in the stack). No more UI / API slowness compared to before — the previous hang is gone. We also did not see HikariPool / createTimeoutException in this run. The remaining MS talked to the replica, but write paths failed with: The MySQL server is running with the --read-only option so it cannot execute this statement e.g. SELECT … FROM op_ha_work … FOR UPDATE from HighAvailabilityDaoImpl.take. So the latency/hang issue looks fixed by the PR. After losing the primary MS + primary DB, without promoting the replica to read/write, the surviving MS stays responsive but write operations fail on read-only. Is the expected model for db.ha + loadbalance that the replica must be promoted (or already writable) for CloudStack to remain fully usable after primary loss? Happy to retest with any config tweak you recommend. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
