Сравнивать все вышеизложенное не могу, т.к. не все пробовал, поделюсь схемой которая год в проде.
Используется Galera-кластер на базе Percona Xtradb. В нем две физические ноды (база живет на SSD в mdadm RAID1), разнесенные по городам (~200км) + арбитратор на виртуалке (нужен для кворума т.к. кластер не должен содержать четное кол-во нод). Любой INSERT\UPDATE\DELETE апрувится всеми нодами и только тогда считается закоммиченым. Запросы разруливаются с помощью живущего на виртуалке прокси Maxscale. Одна из нод является мастером, на нее идут запросы на запись, вторая - слейв, получает запросы на чтение. В случае падения одной из нод вторая автоматически берет на себя ее функции (точнее, сами ноды о своих ролях знать не знают, рулит процессом Maxscale). Когда нода поднимается, она всасывает в себя произошедшие с момента падения изменения IST (Incremental State Transfer) если объем произошедших изменений не превышает размер galera cache (просто файл, размер указывается в конфиге mysql) или, в худшем случае загружается вся база. При этом нода-донор продолжает обрабатывать запросы клиентов как ни в чем не бывало. Присоединившаяся нода становится слейвом, т.к. смена мастера приводит к обрыванию соединений и ее лучше делать вручную, ночью.
Для повышений надежности у обеих нод есть по одному слейву, куда в реальном времени реплицируются все изменения. С них удобно делать бекап в любой время, не боясь нагрузить базу (используем нативный перконовский Innobackupex, который очень быстро и без блокировок бекапит базу налету) или же выполнять тяжелые селекты.
Если есть вопросы - задавайте, постараюсь ответить.
Простой
