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