3 ms·
"Which means that promoting a slave to master will by definition lose some committed writes." Sure. But that is where the application code comes in. You usuall
by ransom1538 8y ago
"Which means that promoting a slave to master will by definition lose some committed writes."
Sure. But that is where the application code comes in. You usually have at least two db connections one to the slave connection and one to master. If you are checking if an account exists [important] you can ask the master since it will be in an up to date state. If you want to build someone's feed on github, then doing all your sql though the slave is fine. They also probably have layers of atomic cache on top which handles 99% of the requests [memcache,redis,whatever]. EG. Does the account exist? Check the cache, check master.
- specialist 8y agoRestating what I think you're suggesting: Use master for transactional read/writes. Use replicas (slaves) for readonly. More or less?
- sethammons 8y agoI'm sure that is what they do. But application code does not save you from this scenario. If your master changes, the application does not know that the new master was a node that did not have full replication.