У меня есть кластер из 3 серверов mySQL/PHP/Apache (каждый на разных континентах для максимальной устойчивости). Я прочитал много советов, которые все говорят - не делайте этого!
По сути, вот причины, по которым я хочу это сделать:
- Устойчивость — 2 из 3 серверов могут выйти из строя, но пользователи все равно смогут войти в систему и просмотреть свои данные/выполнить свою работу.
- Резервное копирование - как указано выше
- Распределение нагрузки — я могу распределить нагрузку на front-end и процессы back-end сервера по разным компьютерам.
Я рассматривал разные варианты, включая percona galera, похоже, у всех есть недостатки. Главное — прозрачность: в какой-то момент ссылка или сервер отключаются, затем вы получаете неопределенные ошибки BINLOG, и тогда это становится огромной проблемой...
Поэтому я реализовал это сам - у меня есть набор скриптов, которые создают триггеры INSERT/UPDATE/DELETE для каждой таблицы - любые изменения регистрируются в таблице репликации. Каждую минуту процесс отправляет эти изменения на два других сервера. У меня также есть процессы, которые проверяют КОНТРОЛЬНУЮ СУММУ и оповещают о любых несоответствиях.
Работает отлично. Согласен, нелегко! Множество хлопотных вещей, в том числе:
- не используется тип столбца float (0,3434 не равно 0,3434...)
- избегание автоинкрементных ключей (если данные вставляются на два разных сервера в одну и ту же минуту, они оба могут принять следующее значение, и тогда взаимные вставки завершатся ошибкой).
- не забудьте перезапустить скрипт создания триггеров, если вы измените структуру таблицы
Итак, мой вопрос... Что может пойти не так? Где/почему это может пойти не так? Чего я не знаю?
решение1
В противовес вышесказанному, я думаю, что это отличный вопрос. Они не просят анализа того, что они сделали, а просто общее "4-е окно" того, что есть неизвестные неизвестные.
Приложения с интенсивным использованием данных — этоотличная книга Они называют это репликацией Multi-leader, а не master-master, и хорошо обсуждают, почему это имеет подводные камни. Как вы видели, сервисы с Galera и Percona этого не делают — так что должна быть веская причина (я пока не играл с Blackhole).
Я думаю, что ключевой момент заключается в том, что вам нужно убедиться, что структура таблицы может справиться с репликацией нескольких ведущих, то есть если на отдельных серверах добавляются 2 новые записи, вам не захочется (как вы говорите) иметь поле ключа с автоматическим приращением. Вам нужно спроектировать таблицу и приложение так, чтобы они могли использовать, возможно, идентификатор пользователя, временную метку и т. д. (так что это ручная работа).
Вам также, вероятно, понадобятся хорошие инструменты, чтобы иметь возможность быстро сравнивать таблицы в разных базах данных и выявлять несоответствия.