Распределенная синхронизация mysql
Я использую сервер, который подключен к хосту SQL. У меня есть другой сервер, и я решил запустить его как резервную копию SQL. Итак, у меня есть 3 из них. Srv A является хостом SQL, srv B является резервной копией.
Я знаю, что есть репликация mysql, но это просто не то, что мне нравится (поправьте меня, если я ошибаюсь). Я бы хотел, чтобы что-то было распространено, поэтому, если srv A вернется, он не будет перезаписывать базу данных, созданную во время простоя на srv B. У меня есть только 3 сервера, поэтому настройка кластера не вариант.
Я был бы рад, если бы кто-нибудь мог помочь мне с этим.
2 ответа
Использование конфигурации "ведущий-ведомый" и снятие резервных копий с ведомого устройства является довольно стандартной стратегией для базы данных MySQL. Процесс защиты данных от перезаписи рассматривается на этапе восстановления после сбоя и восстановления после сбоя.
Обычно вы используете ведомый сервер B для полного или инкрементного резервного копирования базы данных (mysqldump -h serverB --all-databases --lock-tables --other-options), согласованно, без влияния на базу данных master с блокировками во время дампов. Это полезно, потому что ведомый является идентичной копией мастера.
Сначала ведущий A настраивается с помощью директивы mysql bin-log, чтобы сделать репликацию доступной для ведомых B .. и, возможно, C,D и т. Д.
Но и ведомый B настроен на ведение бинарного журнала транзакций. (который обычно будет пустым, так как он не должен регистрировать обновления репликации, если вы не являетесь цепочкой подчиненных)
После сбоя сервера A главная роль перемещается на сервер B, и теперь B начинает регистрировать свой собственный файл журнала bin. На этом этапе операции аварийного переключения вы бы вручную отключили репликацию с A на B, ( mysql -h serverB -e 'stop slave' ) потому что, как вы упоминаете, вы хотите защитить B от отказавшего сервера A.
Под "главной ролью переносится с сервера A на сервер B" я имею в виду то, что вы изменили бы свое приложение для записи операций CRUD (создание, замена, обновление, удаление) по адресу сервера B. например mysql -h serverB -e 'INSERT INTO table X', В установке с двумя узлами вы также должны перенести запросы SELECT, поскольку у вас нет кластерной роли только для чтения, отличной от главной роли.
Теперь задача sys-admin вернуть A в режим онлайн как раба B.
Если это был чистый сбой, то теперь А находится за определенным числом событий позади B, но журнал B содержит запись этих событий. Следовательно, вы можете воспроизвести binlog masterB на slaveA (он содержит базовые операторы SQL)
Если сервер A был полностью разрушен, вы можете восстановить mysql для A, используя полную резервную копию, взятую из B, используя либо недавний дамп, либо используя инструмент, подобный сценарию percona innobackex из пакета xtrabackup.
Теперь вы должны настроить репликацию в обратном направлении, чтобы позволить slaveA выполнять репликацию из masterB.
Теперь А и В должны быть идентичны. Если у вас есть веская причина, например, то, что slaveA- это машина с более высокими характеристиками, теперь вы можете переключиться в направлении репликации, чтобы восстановить конфигурацию masterA-slave B.
Другие стратегии для решения этого сценария (аварийного переключения и восстановления после отказа) включают MMM, репликацию с несколькими хозяевами или инструмент управления репликацией percona (который я не пробовал в работе)
У меня только 3 сервера, поэтому настройка кластера не возможна.
Если вы передаете данные между ними, то они по определению являются кластером. И кластер - это именно то, что вы описываете как свою цель. В MyQL говорят, что есть очень специфический тип конфигурации, называемый кластером NDB - это, вероятно, не правильное решение для вас.
поэтому, если srv A вернется, он не будет перезаписывать базу данных, созданную во время простоя на srv B
Это будет сделано только в том случае, если вы используете столбцы с автоинкрементом или другие значения, сгенерированные из последовательности, - и MySQL имеет специальные функции, позволяющие этого избежать.
Я использую сервер, который подключен к хосту SQL. У меня есть другой сервер, и я решил запустить его как резервную копию SQL. Итак, у меня есть 3 из них. Srv A является хостом SQL, srv B является резервной копией.
Я не слежу - у вас есть три сервера баз данных? Или 2?
Независимо от того, вам нужно настроить их как пару мастер-мастер с асинхронной репликацией (НЕ ведущий-ведомый). Если вы хотите добавить третий узел, то добавьте его только в качестве ведомого. Это избавляет от необходимости беспокоиться о продвижении ведомых в случае сбоя - вам просто нужно направить трафик на другой узел (это также удобно для резервного копирования и обновления схемы). Есть много способов достичь этого, но наиболее разумными являются фехтование на клиенте или использование виртуального адреса.
Я не буду описывать процесс здесь, потому что пространство ограничено, и вам нужно точно понимать, что вы делаете. В Интернете также есть много руководств, но вы можете пойти и купить хорошую книгу (только что заметили, что О'Рейли выпустил эту книгу, которая еще более уместна). и придерживаться методов, описанных там.