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