После масштабной проблемы с данными от моего провайдера в Германии мне теперь приходится иметь дело со сценариями отказоустойчивости. Но есть несколько вопросов, на которые я не могу найти реальных ответов. Поэтому я надеюсь, что кто-то сможет мне здесь помочь.
В настоящее время у меня есть server1, на котором запущены две базы данных MySQL в отдельных контейнерах docker. Теперь их следует реплицировать на второй сервер. В случае сбоя server1 я могу относительно быстро переключиться на server2 через ClusterIP.
На всякий случай важно знать: программное обеспечение, использующее базу данных, представляет собой систему управления спортивными соревнованиями, которая выполняет множество операций записи в базу данных (не тестировалось, но в целом это не операции записи и чтения).
Теперь у меня возникли следующие вопросы:
- Какой метод репликации наиболее подходит?
- Насколько я понимаю, MASTER <-> MASTER было бы наиболее уместно. Но я также читал здесь снова и снова, что могут возникнуть проблемы.
- При MASTER <-> SLAVE возникает вопрос, может ли slave только читать. Что произойдет, если master выйдет из строя? Станет ли slave автоматически master и сможет ли также писать?
- Или кластер — лучшее решение? На данный момент у меня только один активный узел. В будущем может быть добавлен еще один узел БД в США. Но на данный момент его не существует.
Я действительно ценю любую помощь, потому что мне нужно быстрое работающее решение, а эта общая тема, похоже, очень обширна и не так уж проста.
решение1
Вы поднимаете два вопроса.
Топология MySQLПо порядку (от хорошего к лучшему)
- Первичный -> Реплика — «отказоустойчивость» может быть достигнута, но это требует ручных усилий, а значит, времени.
- Основной <=> Основной — настройка немного сложнее, но при этом обеспечивается «мгновенное» использование другого сервера.
- Кластер из не менее 3 серверов. Это дополнительно автоматизирует отказоустойчивость. См. "InnoDB CLuster" (MySQL 8) или "Galera" (входит в состав MariaDB).
География — помните, что даже центр обработки данных может выйти из строя. Например, какую часть, скажем, Флориды, может отключить один ураган?
Будьте в курсе сценария «разделенного мозга». Это когда у вас всего два сервера, и оба работают и здоровы, но сеть не работает. Они не могут сказать, и вы не можете сказать, в чем дело. Если каждый думает, что он единственный работающий сервер и продолжает выполнять запись, вы получите беспорядок. Поэтому вместо этого вам придется предположить, что вся система не работает.
Итог — вам понадобится как минимум 3 сервера, физически разделенных.
Прокси
Проблема все еще существуетклиентызнание того, какая часть системы базы данных активна (для чтения и/или записи). Когда важно только «чтение», достаточно многих топологий с любым количеством реплик — и они обеспечивают «неограниченное» масштабирование. «Записи» — вот где настоящие проблемы.
Есть несколько сторонних продуктов, которые хорошо замечают, что один сервер не работает, и «делают правильно», перенаправляя трафик на другой сервер. Изучите их.
Кодирование
При возникновении сбоя ваш код, скорее всего, получит какую-то ошибку. Вы должны проверить наличие ошибок, некоторые из них не являются самовосстанавливающимися. И для обнаружения большинства сетевых ошибок требуется некоторое время.