Когда у меня есть два сервера mysql, которые имеют разные задания (содержат разные базы данных), но хотят иметь возможность использовать один из них, чтобы проскользнуть в случае сбоя другого, что бы вы посоветовали, как я сохраню данные на обоих из них равными "close в реальном времени "?
Очевидно, что невозможно создать полный дамп базы данных каждые х минут.
Я читал о двоичном журнале , это путь, который мне нужно идти? Не сильно ли это замедлит работу резервного сервера? Есть ли способ не включать некоторые таблицы в двоичный журнал - где это не имеет значения, что данные изменились?
Двоичный журнал, безусловно, путь. Тем не менее, вы должны знать, что с MySQL вы не можете просто переключаться между такими серверами.
Один сервер будет ведущим, а другой - ведомым. Вы пишете / читаете мастер, но можете читать только с подчиненного сервера. Если вы когда-нибудь напишете ведомому, они будут не синхронизированы, и нет простого способа заставить их снова синхронизироваться (в основном, вы должны поменять их местами, чтобы мастер стал новым ведомым, но это утомительный ручной процесс ).
Если вам нужны настоящие резервные копии баз данных с возможностью горячей замены, вам, возможно, придется перейти на систему, отличную от MySQL . Если все, что вам нужно, это оперативная резервная копия только для чтения, которую вы можете использовать мгновенно в худшем случае (мастер окончательно уничтожен), Binary Log вам вполне подойдет.
Возможно, вы захотите рассмотреть сценарий репликации мастер-мастер , но с небольшим поворотом. Вы можете указать, какие базы данных нужно реплицировать, и ограничить репликацию для каждого сервера.
Для 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заявлений или тому подобного.