После шагов по репликации существующего сервера кажется, что большинство методов полагаются на возможность либо полностью остановить главный сервер, либо, по крайней мере, предотвратить его запись с использованием flush tables with read lock; что фактически приводит к простоям, поскольку многие приложения не могут должным образом реагировать, когда не могут выполнять запись в базу данных.
Есть ли безопасный способ репликации ведущего устройства на ведомое устройство, гарантирующий нулевое время простоя и полную синхронизацию информации базы данных?
В нашем сценарии у нас есть один мастер и один подчиненный, и они оба работали хорошо. Ошибка MySQL во время обновления с 5.5 до 5.6 привела к тому, что ведомое устройство немного рассинхронизировалось, и теперь мы хотим полностью воссоздать его базы данных. На данный момент, когда мы получаем спорадические ошибки, мы пропускаем их, используя STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; но это только означает, что репликация не на 100% похожа на мастер.
Спасибо
Хотя это старый вопрос, но если вы все еще ищете ответ - попробуйте percona xtrabackup. Если у вас есть таблицы MyISAM, используйте параметр --rsync. С его помощью мы добились почти бесшовного дампа (блокировка занимала около 5-10 секунд для БД размером около 1 ГБ).
Там есть. Когда все механизмы базы данных являются InnoDB и вы указали --single-transaction переключатель. Сюда flush tables with read lock; или --lock-all-tables не нужен.
В противном случае, думаю, других вариантов нет. Мои соболезнования.
По сути, увеличение счетчика пропуска подчиненных - это плохо, если вы не уверены, что это безопасно (например, при репликации отсутствующих пользователей grant заявления и тому подобное).