Это сложно. Я хочу иметь возможность перемещать одну базу данных с одного сервера на другой без простоев. Я мог сделать снимок данных на первичном сервере, перейти на вторичный, запустить репликацию, получить актуальные данные на вторичном сервере, переместить запросы на вторичный.
Но что, если вторичный сервер уже является производственным сервером MySQL, который я не могу перезапустить, и который должен принимать входящие «передачи баз данных» от нескольких серверов-источников?
Я просто хотел бы вкратце познакомиться с этим вопросом.
Так что да, правильный способ сделать это - использовать кластеризацию / репликацию. Вот несколько неправильных (но, вероятно, функциональных в особых случаях) способов сделать это:
Если вы используете MyISAM в ZFS или какой-либо другой файловой системе, которая может поддерживать моментальные снимки, вы можете заблокировать таблицу для записи, выполнить сброс таблиц, сделать моментальный снимок файловой системы, а затем разблокировать таблицы. Затем перейдите в моментальный снимок, скопируйте все файлы и загрузите их на подчиненный сервер. Конечно, передача их на подчиненный сервер является своего рода обратной процедурой, описанной выше, за исключением того, что вместо обратного снимка есть удаление и перемещение. Примечание: я бы не стал серьезно рекомендовать это никому в производственной системе.
Вы можете написать сценарий, который создает временные таблицы в подчиненной системе, используя определение таблиц, в которые вы собираетесь реплицировать, затем подключается к главной системе, выполняет выбор * и копирует результаты в целевые таблицы памяти, затем когда все они будут выполнены, заблокируйте (или сделайте транзакцию) таблицы и скопируйте данные из памяти в реальные таблицы (т. е. удалите, а затем замените, или замените и затем удалите); затем разблокировать и пи.
Оба они практически не требуют простоя (в зависимости от размеров вашей таблицы и т. Д. Он может заблокировать БД на короткое время, возможно, самое большее на несколько секунд, что, вероятно, нормально, если вы не делаете это слишком часто).
Однако оба этих решения не очень хороши тем, что создают пики нагрузки и приводят к периодам между синхронизациями, когда данные ведомого устройства не обновляются. Вы не указали, что вам это нужно в своем вопросе, отсюда и предложения, а просто указали, что если это действительно требуется, то да, вам нужна репликация.
Я использую что-то вроде первой идеи для резервного копирования на очень конкретном сервере БД, который у нас есть (и они работают нормально), а вторую - для синхронизации данных из восходящего источника, который я не контролирую, до сервера, который я контролирую, чтобы я мог работать с данными. Как я уже сказал, здесь нет отличных общих решений, но в этих конкретных случаях они работают.
Поскольку это очень сложно сделать без встроенной поддержки в самой базе данных, вы можете изучить возможность использования Кластер MySQL с асинхронной репликацией. это воляоднако требуется, чтобы вы использовали дистрибутив MySQL Cluster, а не обычный дистрибутив MySQL.
В противном случае, как предполагает ответ @ RolandoMySQLDBA, просто невозможно реплицировать базу данных без некоторой базовой поддержки для зеркального отображения обновлений для каждой базы данных. Он не поясняет, что это не вызывает время простоя- сайт может оставаться в состоянии только для чтения, пока база данных выгружается и загружается.
Я также думаю, что кластер MySQL - ваше решение. Вы можете установить активное / пассивное решение. Что я сделал, так это настроил аварийное переключение на моем DNS-сервере, в случае сбоя я балансирую сервер на пассивный, а затем я выполняю аварийное переключение ...
Конечно, лучшее решение active / active - лучшее, но когда я это сделал, это было нетривиально или я был намного глупее, чем сейчас: P
В любом случае я думаю, что ваше решение определенно будет ориентировано на настройку кластера.