What I found really misleading is the section about master-master.
Especially this one:
> This architecture is too risky for a service company.
> All it takes is for the master to be down, which will
> happen, and clients will start having indexing errors.
Actually having a single master has benefits and you should never consider a multi-master setup if you don't need to scale writes. It's way easier to handle that, than to handle split brain and other stuff, especially on inter region connections.
Keeping a queue in front of the database, etc pp.
As said only if you really need write scalability, you should use a master-master approach. Else your problems could be way worse than just "master" is offline.
> This architecture is too risky for a service company. > All it takes is for the master to be down, which will > happen, and clients will start having indexing errors.
Actually having a single master has benefits and you should never consider a multi-master setup if you don't need to scale writes. It's way easier to handle that, than to handle split brain and other stuff, especially on inter region connections. Keeping a queue in front of the database, etc pp. As said only if you really need write scalability, you should use a master-master approach. Else your problems could be way worse than just "master" is offline.