Я готовлюсь к настройке MySQL master-slave или master-master отношений. Сейчас у меня есть один сервер MySQL production, и, конечно, я не хочу много простоев, пока я подключаю slave.
Нет ли способа подключить пустое подчиненное устройство и позволить ему «медленно» синхронизировать данные с главным устройством, пока они не станут идентичными?
Я заметил, что могу сделать дамп транзакций с помощью mysqldump на главном сервере, а затем импортировать его на подчиненный сервер, но к тому времени, как подчиненный сервер импортирует дамп, будет записано много новых строк, и как подчиненный сервер их получит?
Надеюсь, я упускаю что-то очевидное, но обширное гугление дает такие советы, как «поскольку это приведет к меньшему времени простоя в будущем, некоторое время простоя сейчас, возможно, не так уж и плохо». Но мне бы очень хотелось этого избежать.
Связанныйвопрос для MyISAM, но я использую InnoDB.
решение1
Если вы используете 100% InnoDB, то вам повезло. Вы можете использоватьXtraBackupдля создания полной резервной копии вашей главной базы данных без простоя или блокировки таблиц. Это будет последовательная резервная копия в стиле моментального снимка, такая же, как та, которую вы получаете, когда используете опции FLUSH TABLES WITH READ LOCKили --master-data.
Инструмент XtraBackup также помещает в каталог резервного копирования дополнительный файл, содержащий информацию MASTER_LOG_POS и MASTER_LOG_FILE, необходимую для запуска репликации на подчиненном устройстве.
После завершения резервного копирования вам нужно будет запустить --prepareопцию XtraBackup для резервной копии, загрузить ее на подчиненный сервер, запустить на подчиненном сервере процесс резервного копирования MySQL и сообщить ему новые необходимые значения MASTER_LOG_POS и MASTER_LOG_FILE.
skip-slave-startПеред запуском подчиненного устройства вам понадобится файл my.cnf.
Также имейте в виду, что mysqlсхема по умолчанию — MyISAM (и если память не изменяет, она может быть только MyISAM), поэтому вам все равно придется быть осторожным, чтобы не вносить никаких изменений в любую из этих таблиц во время выполнения резервного копирования. Пока вы придерживаетесь этого правила, основная информация будет по-прежнему корректной.
Часто бывает полезноигнорировать mysqlсхему в вашем my.cnfна подчиненном устройстве и только когда-либо создавать пользователей с привилегиями SELECT. Несогласованные и несинхронизированные подчиненные устройства трудно обнаружить и с ними трудно иметь дело, даже при использовании инструментов, которые Percona (и Maatkit до них) предоставляют для этого.
Редактировать:
Хотя вы сказали, что используете InnoDB, для полноты картины есть другой способ, если вы используете таблицы MyISAM. Если у вас есть менеджер томов с функцией моментальных снимков (например,ЗФСилиЛВМ), вы можете запустить а FLUSH TABLES WITH READ LOCKзатем SHOW MASTER STATUS, создать снимок и запустить UNLOCK TABLES. Время простоя должно быть довольно минимальным. Для сравнения, задание cron прошлой ночью, которое сделало это для резервного копирования одной из наших баз данных, заняло 6 секунд для создания снимка, который является частью, где база данных «не работает», и 27 минут для копирования файлов из снимка на сервер резервного копирования.
решение2
Невозможно запустить репликацию 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) на весь срок дампа. Таким образом, никакие запросы на запись в любую из таблиц не будут возвращены, пока дамп не будет завершен. Кроме того, запросы на запись, вероятно, также заблокируют любые последующие запросы на чтение, если вы не указалиобновления_с_низким_приоритетомв конфигурации MySQL или выполните команду SET GLOBAL LOW_PRIORITY_UPDATES=1 перед дампом.