Я готовлюсь к установке отношений MySQL master-slave или master-master. Прямо сейчас у меня есть один производственный сервер MySQL, и, конечно же, я не хочу простоев, пока подключаю ведомый.
Нет ли способа заставить подключить пустой ведомый и позволить ему «медленно» синхронизировать данные от ведущего, пока они не станут идентичными?
Я заметил, что я могу сделать дамп транзакции с mysqldump на главном устройстве, а затем импортировать его в подчиненное устройство, но к тому времени, когда подчиненное устройство импортировало дамп, будет записано много новых строк, и как подчиненное устройство получит их ?
Надеюсь, мне здесь не хватает чего-то очевидного, но обширный поиск в Google дает такие советы, как «поскольку это приведет к сокращению простоев в будущем, некоторые простои сейчас, возможно, не так уж и плохи». Но мне бы очень хотелось этого избежать.
Связанный вопрос для MyISAM, но я использую InnoDB.
Если вы используете 100% InnoDB, то вам повезло. Ты можешь использовать XtraBackup чтобы сделать полную резервную копию вашей главной базы данных без простоев или блокировок таблиц. Это будет последовательная резервная копия в стиле моментальных снимков, такая же, как и в случае, когда вы делаете FLUSH TABLES WITH READ LOCK или --master-data параметры.
Инструмент XtraBackup также помещает дополнительный файл в каталог резервных копий, который содержит информацию MASTER_LOG_POS и MASTER_LOG_FILE, необходимую для запуска репликации на ведомом устройстве.
Когда вы закончите резервное копирование, вам нужно будет запустить XtraBackup --prepare опцию резервного копирования, загрузите его в ведомое устройство, запустите резервный процесс MySQL ведомого устройства и сообщите ему новые необходимые значения MASTER_LOG_POS и MASTER_LOG_FILE.
Ты захочешь skip-slave-start в вашем my.cnf, прежде чем запускать раб.
Также имейте в виду, что mysql схема - это MyISAM по умолчанию (и если память работает правильно, это может быть только MyISAM), поэтому вам все равно придется быть осторожным, чтобы не вносить никаких изменений в любую из этих таблиц во время резервного копирования. Пока вы придерживаетесь этого правила, основная информация будет верной.
Часто бывает хорошей идеей игнорировать mysql схема в вашем my.cnf на ведомом устройстве и создавать пользователей только с привилегиями SELECT. Несогласованные и несинхронизированные ведомые устройства трудно обнаружить, и с ними трудно справиться даже при использовании инструментов, которые Percona (и Maatkit до них) предоставляют для этого.
Редактировать:
Хотя вы сказали, что используете InnoDB, для полноты картины есть другой способ, если вы используете таблицы MyISAM. Если у вас есть диспетчер томов со снимками (например, ZFS или LVM), вы можете запустить FLUSH TABLES WITH READ LOCK за которым следует SHOW MASTER STATUS, создайте снимок и запустите UNLOCK TABLES. Время простоя должно быть минимальным. Для сравнения: вчера вечером задание cron, которое выполняло это для резервного копирования одной из наших баз данных, заняло 6 секунд для создания моментального снимка, который является битом, в котором база данных «не работает», и 27 минут для копирования файлов из моментального снимка на сервер резервного копирования.
Невозможно запустить репликацию mysql "с нуля".
Вместо этого вы можете использовать mysqldump с --master-data=2 параметр при выгрузке ваших баз данных - то есть вот так:
mysqldump --master-data=2 --all-databases --opt -p > myinitialdump.sql
Эта команда заблокирует все таблицы в затронутых базах данных во время дампа и запишет координаты репликации в заголовок дампа в закомментированном виде, например:
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000018', MASTER_LOG_POS=106;
После завершения импорта вы можете вручную запустить команду «изменить мастер на», добавив имя хоста вашего мастера и данные аутентификации - репликация начнется в точке дампа.
Имейте в виду, что процесс mysqldump сам по себе вызовет "простои" из-за конфликта блокировок - он устанавливает блокировки чтения для всех таблиц (аналогично тому, что делает команда FLUSH TABLES WITH READ LOCK) на все время создания дампа. Таким образом, запросы на запись ни в одну из таблиц не вернутся, если дамп не будет завершен. Кроме того, запросы на запись, вероятно, также будут блокировать любые последующие запросы чтения, если вы не указали low_priority_updates в вашей конфигурации MySQL или выдал SET GLOBAL LOW_PRIORITY_UPDATES = 1 перед дампом.