У меня есть две базы данных Sql, «MASTER» и «SLAVE», и я использую репликацию Sql для их синхронизации. Я использую MariaDB 10 для обеих баз данных.
База данных MASTER устанавливается на ПЛК Linux с помощью Docker.
SLAVE находится на сервере NAS, который также использует Docker.
Он работает нормально, пока я не отключу питание ПЛК ... когда я перезапускаю его, ВЕДОМОМУ не удается прочитать двоичный журнал, и процесс репликации останавливается.
Кажется, это довольно распространенная проблема, но я не нашел решения, чтобы репликация снова работала после автоматического отключения электроэнергии ...
Есть ли способ решить эту проблему?
Я видел, что PerconaDB может быть решением, но мой ПЛК armv7 несовместим.
Спасибо
Есть несколько способов решить эту проблему, но не автоматически! Но сначала сообщение об ошибке может помочь понять причину. Обычно ведомое устройство пытается повторно подключиться к ведущему и продолжает репликацию самостоятельно. Итак, вопрос в том, какова текущая проблема?
Решения вручную:
Решение №1 Может произойти ошибка пропуска Dataloss!
УСТАНОВИТЬ ГЛОБАЛЬНЫЙ SQL_SLAVE_SKIP_COUNTER = 1; запустить раб; показать статус ведомого \ G; Повторяйте это до тех пор, пока раб работает. Но имейте в виду, данные могут быть потеряны.
Решение № 2 Дамп SQL / Восстановление резервной копии.
На мастере: сначала выполните блокировку базы данных.
show master status \g;
Result may look like:
show master status \g;
+------------------+-----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+-----------+--------------+------------------+-------------------+
| mysql-bin.000063 | 176085122 | | | |
+------------------+-----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
Сделайте дамп SQL на Master и всех базах данных. Восстановите дамп SQL на подчиненном сервере. Возможно, удалите master.info или отредактируйте его с помощью новых файлов и журналов Master.
Освободите блокировку DB на главном устройстве. Запустите Slave, репликация должна снова запуститься.
Решение № 3 Ведущая и ведомая базы данных должны быть одной версии, той же аппаратной архитектуры и операционной системы.
Вместо дампа mysql вы можете остановить базу данных на главном и подчиненном. Просто скопируйте или синхронизируйте файлы базы данных от главного к подчиненному.
auto.conf содержит уникальный идентификатор сервера. Удалите этот файл или отредактируйте идентификатор в подчиненной системе перед запуском подчиненного сервера.
Дополнительная информация для "change_master_to" https://mariadb.com/kb/en/library/change-master-to/
Надеюсь, вы знаете основы настройки репликации главный / подчиненный.
Однако эти шаги могут быть выполнены скриптом и инициированы crontab (@reboot). Но я бы никогда не сделал это автоматически, только меня не волнуют данные и их согласованность.
Что, если меня не беспокоит потеря некоторых данных? Потеря примерно 1 часа сбора данных не проблема, но мне действительно нужна репликация для автоматического и надежного восстановления.
Мне это не нравится. Лучше выясните, почему, и остановите mariadb для очистки / сброса мастера после перезапуска. Это было бы лучшим решением.
Автоматически: создайте простой скрипт и выполните его в crontab @reboot.
RESULT=$(mysql -NLr -e 'show master status')
FILE=$(echo ${RESULT} | cut -d ' ' -f 1)
LOGPOS=$(echo ${RESULT} | cut -d ' ' -f 2)
and maybe execute remote: mysql -h slavedb -e "CHANGE MASTER TO MASTER_LOG_FILE=$FILE, MASTER_LOG_POS=$LOGPOS;"
И, может быть, здесь вы найдете более безопасный способ автоматического восстановления базы данных. Но не забывайте бросать / убирать раба раньше. Не уверен в ваших данных. Может потребоваться время.
Просто возьмите это в cronjob: Инициализировать подчиненный сервер MySQL, расположенный в сети, отличной от главной.
mysqldump --all-databases --master-data=1 | mysql -h slavedb
Все, что вам нужно, это подключение к ведомой базе данных и суперпользователь / root с правами администратора от ведущего к ведомому. Пользователь также должен существовать на мастере. Будет перезаписан после дампа / восстановления.