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

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

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

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

Ответов (2)

Решение

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

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

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

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

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

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