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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Для 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 заявления или им подобные.