mysql master-master setup как способ простого продвижения master-slave
Я пытаюсь понять, является ли следующий план жизнеспособным. Цель здесь состоит в том, чтобы иметь возможность выполнять HA (время безотказной работы) и не обязательно для загрузки - запись выполняется на одном сервере MySQL 5.5 (с innodb), но не совсем возможна, когда база данных не работает.
В настоящее время у меня есть настройка репликации master-slave, которая работает нормально, за исключением того, что она не имеет автоматического продвижения (очевидно). то, что я планирую сделать, это настроить репликацию мастер-мастер, чтобы, возможно, выполнить это "автоматическое продвижение" с помощью Amazon Route 53 DNS Failover (проверки работоспособности). Чего я пытаюсь избежать, так это то, что НЕ нужно делать трюк с автоинкрементом, потому что "деловые люди" привыкли к автоинкрементному PK как последовательные числа (да, я знаю, что это плохо, но данные за 2004 год).
Итак, настройте репликацию мастер-мастер БЕЗ бита предотвращения коллизий с автоинкрементом. Основной мастер - db1.domain.com, а вторичный мастер - db2.domain.com.
В Amazon Route 53 настройте запись аварийного переключения DNS для db.domain.com -> первичное аварийное переключение - db1.domain.com -> с помощью проверки работоспособности TCP на порт IP-адреса 3306 -> вторичное аварийное переключение - db2.domain.com -> с помощью Проверка работоспособности TCP на порт IP-адреса 3306
Большую часть времени (99%), если tcp://db1.domain.com:3306 не работает, db1.domain.com будет обслуживаться при попадании DNS на db.domain.com. На самом деле, надеюсь, это 100%. Возможные недостатки этого - потеря первичного ключа (коллизия), и я думаю, что я в порядке с потерей одного заказа. Мы являемся бизнесом малого объема данных и можем просто позвонить нашему клиенту, если это произойдет (например, исчезновение заказа).
Похоже ли это на хороший план?
Затем я также буду запускать другую подчиненную репликацию на db1.domain.com как "master" для slave-db1.domain.com - не знаю почему, может быть, для тяжелых SELECTs?
3 ответа
Это не так просто сделать DNS Failover для базы данных. Есть много причин, но вот несколько, которые могут вызвать проблемы.
Многие приложения используют библиотеки пула подключений, поэтому они могут создавать постоянные подключения к базе данных, поэтому предположение о том, что аварийное переключение DNS может фактически заставить весь трафик приложения (чтение и запись) перейти на новый сервер, и предотвратит ситуации, когда запись может случиться с обоими и вызвать столкновения первичного ключа.
Теперь ситуация, описанная выше, может не быть проблемой, если основная база данных будет фактически отключена, так как это уничтожит все присутствующие соединения SQL и, следовательно, приведет к уменьшению любых проблем двойной записи. Проблемы будут происходить, когда под высокой нагрузкой сервер MySQL начинает отклонять новые соединения. Запустится аварийное переключение DNS, существующие соединения останутся на текущем сервере, а новые соединения будут созданы с целью аварийного переключения. Теперь у вас неприятности!
Задержка репликации и репликация с несколькими хозяевами могут добавить еще одну касательную к этому уравнению. Вы действительно не хотите быть слишком далеко от основного при выполнении безопасного аварийного переключения; проблемы, которые могут возникнуть в результате этого, слишком велики, чтобы перечислять их здесь.
Взгляните на решение, подобное ScaleArc. Он учитывает состояние и понимает такие вещи, как задержка репликации, и предлагает несколько опций высокой доступности, наряду со многими другими функциями, такими как кеширование, аналитика и т. Д.
пытаться избежать, чтобы не делать трюк с автоинкрементом
Преодолей это.
Таким образом, по-видимому, у вас также нет транзакций, и вы довольны временем простоя для обновления схемы.
Если ваши "деловые люди" хотят, чтобы автоматически сгенерированные идентификаторы были последовательными, спросите их, как реализовать безопасную систему высокой доступности без этого. Это вполне возможно, но это очень, ОЧЕНЬ медленно и не в состоянии справиться со всеми другими плохими вещами, которые исправляет репликация мастер-мастер.
Вы заметите, что в документации Amazon говорится только об использовании их сервисов отработки отказа для работы с веб-серверами - для этого есть причина (и, возможно, это даже не очень хорошая стратегия для веб-серверов). Существуют контексты, в которых реализация высокой доступности на клиенте является хорошей идеей (и они основаны на циклической адресации, а не на отказоустойчивости).
Я думаю, что я в порядке с потерей одного заказа
Даже при 0 с TTL вы можете ожидать, что распространение займет около 2 часов. Вы подробно рассказали о вашем программном стеке и о том, где он находится. С PHP/ непостоянным запуском внутри AWS вы получите более быстрое восстановление, но с постоянными подключениями (например, Java) вы можете получить очень длительный сбой.
Это звучит как осуществимый план. Я бы не использовал DNS для отказа. Я бы использовал что-то вроде LinuxHA или ucarp для управления плавающим IP-адресом, который определит вашу базу данных писателя. Это особенно верно, если у вас есть несколько клиентов, использующих эти базы данных.