Посоветуйте как грамтоней сделать failover сайта.

отказоустойчивым [..] так сказать best practice

Abandon hope all ye who enter here.

Ну хорошо, допустим в деталях. Действительно ли master-master опасен для данных или это заявление не актуально для новых версий мускуля/марии/перконы ?
Допустим, у меня master-slave синхронная репликация, если мастер помер не синхронизировавшись со слэйвом, что произойдёт с БД, после возвращения мастера в строй ?

Сударь, вы упорот? MS-репликация представляет из себя тупое прокатывание бинлога. На каком месте мастер поднимется - с того и продолжит.

1. drbd говно. 2. Галера говно. 3. Статику синхронизировать подойдет что-то типа ceph. 4. nginx кроме собственно раскидывания нагрузки умеет дохера еще чего полезного (например, кормить клиента заранее гзипованной статикой, делать тамбнейлы из картинок и все такое).

ceph не будет дичайшим оверхедом для обычного сайтика ?

Т.е. если изменения пришли в слейв, то разницу надо как-то руками выдирать или что с этим делать потом ?

В master/slave по определению изменения пишутся на мастер.

Учитывая, что базы в вебе преимущественно работают на чтение - именно в этом и есть разница между маковыми булками и развитым социализьмом. Много слейвов для readonly и 1-2 мастера для записи.

И да, даже в master-master конфигурации писать одновременно в две базы крайне не советуется - можно смачно половить дедлоков.

Спасибо.
Т.е. в случае только с двумя серверами master и slave, делать slave основным на время недоступности мастера - очень плохая идея ?

В случае MS ты вообще не сможешь переписать изменения, поскольку слейв читает бинлог с мастера, а не наоборот.

Почти все известные технологии HA хранения данных будут вполне адекватно работать. От remus'а до какого-нибудь master-master mysql. Нода упадёт, юзеры не заметят. Но здесь зарыта лягушка.

Проблемы начнутся когда ты починишь упавшую ноду и попытаешься её запустить. Во всех случаях будет геморрой вручную и с большой вероятностью какая-нибудь жопа, что сводит всю эту хероту с HA на нет.

Наиболее адекватно подъём упавших нод отрабатывает галера на трёх машинах. И то есть проблемы.

По большому счёту, все имеющиеся HA решения предполагают следующую логику работы:

1. Всё работает

2. Одна тачка внезапно сдохла, всё продолжает работать.

3. В удобное для _нас_ время останавливаем сервис, поднимаем починеную ноду.

В общем-то даже аппаратный рейд не всегда нормально отрабатывает замену сдохшего диска на нулёвый (иногда таки надо лезть в биос контроллера и тыкать его носом, что это таки новый диск и да, он часть рейда, и да, на него надо сцуко отзеркалить), так что ничего удивительного во всей этой катавасии нет.

Почти все известные технологии HA хранения данных будут вполне адекватно работать.

А тут пишут, что нет.

Вероятные поломки делают Master-Master репликацию непривлекательной. Выход из строя одного из серверов практически всегда приводит к потере каких-то данных. Последующее восстановление также сильно затрудняется необходимостью ручного анализа данных, которые успели либо не успели скопироваться.

master-master MySQL - вообще сложно назвать HA технологией. Это вообще какой-то побочный продукт каких-то мутных экспериментов с репликацией. :) И, как я уже говорил, даже в этом случае, основные проблемы начнутся вовсе не при сдыхании ноды, а при её восстановлении.

Для MySQL лучше пользовать галеру. Правда, понадобится 3 машины, а не 2.

Где можно почитать про тонкости использования галеры ? Почему потребуется 3 машины ?

Нельзя просто так взять и включить мастер-мастер в мускуле для рандомного приложения. Приложение должно учитывать особенности мастер-мастер в мускуле, иначе данные рискуют быть неконсистентными. Нужно просто почитать как разработчики медиавики рекомендуют деплоить их поделку.

Где можно почитать про тонкости использования галеры ?

загугли MariaDB Galera. Уже достаточно много инфы.

Почему потребуется 3 машины ?

Для проведения голосований без участия человеков при восстановлении одной из нод, так сказать. :) Впрочем, если сдохнут сразу две ноды, то могут быть проблемы, однако, такое развитие событий менее вероятно.

загугли MariaDB Galera

Инет кишит противоречивой инфой, поэтому спросил что можно почитать, кроме официальной документации. Из документации не всегда вытекают тонкости использования.

Нужно просто почитать как разработчики медиавики рекомендуют деплоить их поделку.

Честно говоря, не осилил загуглить что разработчики рекомендуют.

Инет кишит противоречивой инфой, поэтому спросил что можно почитать, кроме официальной документации. Из документации не всегда вытекают тонкости использования.

Насчёт тонкостей - «there is only one way to find out». :) Тонкости очень сильно зависят от твоего юзкейса. Готовой хаутушки про всё в этой области просто не существует из-за весьма ограниченного круга пользователей.

Так что читай всю инфу, поднимай галеру, а там, по ходу дела уже разберёшься.

Ясно. Спасибо.