Репликация MySQL для резервного сценария

Когда у меня есть два сервера mysql, которые имеют разные задания (содержат разные базы данных), но хотят иметь возможность использовать один из них, чтобы проскользнуть в случае сбоя другого, что бы вы посоветовали, как я сохраню данные на обоих из них "близкими" в реальном времени "?

Очевидно, что невозможно создать полный дамп базы данных каждые x минут.

Я читал о двоичном журнале, это путь, который мне нужно идти? Не сильно ли это замедлит работу резервного сервера? Есть ли способ не включать некоторые таблицы в двоичный журнал - где это не имеет значения, что данные изменились?

2 ответа

Решение

Двоичный журнал, безусловно, путь. Тем не менее, вы должны знать, что с MySQL вы не можете просто переключаться между такими серверами.

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

Если вам нужны настоящие базы данных с возможностью горячей замены, вам может потребоваться перейти на систему, отличную от MySQL. Если все, что вам нужно, это оперативная резервная копия только для чтения, которую вы можете использовать мгновенно в худшем случае (мастер окончательно уничтожен), Binary Log вам вполне подойдет.

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

Для server1 я бы добавил --replicate-do-db=server_2_db и на сервере2 --replicate-do-db=server_1_db в ваш my.cnf (или my.ini в Windows). Это будет означать, что только операторы для server_1_db будут реплицированы на server2 и наоборот.

Также убедитесь, что вы выполняете полное резервное копирование на регулярной основе, а не просто полагаетесь на репликацию, поскольку она не обеспечивает безопасность от случайного DROP DATABASE заявления или тому подобное.

Другие вопросы по тегам