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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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