Репликация базы данных MySQL с "непостоянной" записью
Я работаю с производственной базой данных MySQL и хотел бы:
- Создайте доступную только для чтения подчиненную копию базы данных, которая получает обновления от мастера. Мастер - единственный, на кого можно писать.
- Имейте доступ "непостоянной записи" к ведомой копии базы данных. Под "непостоянным" я подразумеваю, что пользователи могут писать в базу данных и что-то менять, но когда-нибудь, скажем, завтра, все изменения исчезнут, и все станет точной копией мастера.
QUESTION 1: Это возможно? Я знаю (1) возможно, потому что здесь есть некоторая документация http://dev.mysql.com/doc/refman/5.0/en/replication.html. Но я не уверен, что смогу получить и (1), и (2). Я спрашиваю, потому что мне нужно написать код, который обращается к базе данных, и поскольку это производственная база данных, используемая всеми, бывают случаи, когда я не могу использовать базу данных. Я хотел бы написать тестовые программы, использующие реплицированное ведомое устройство (с непостоянным доступом для записи), и когда я убедился, что все в порядке, я буду запускать свою программу, используя базу данных master, чтобы изменения были постоянными. Я хотел бы, чтобы мои записи отображались в подчиненном, чтобы я мог убедиться, что правильные вещи написаны.
QUESTION 2: Можно ли легко скопировать базу данных по частям? В базе данных есть действительно огромная таблица. Я думаю, что база данных составляет порядка 4 ГБ. Я могу делать репликацию только на выходных, чтобы не беспокоить всех. Но я боюсь, что одного выходного не хватит для репликации всей базы данных. Итак, есть ли способ сделать это по частям? Или есть какой-то супер быстрый способ репликации базы данных?
QUESTION 3: Насколько сложно будет все настроить? Я предполагаю, что это займет у меня много времени из-за неопытности, но предположим, что у меня есть администратор базы данных, чтобы сделать работу за меня, сколько проблем я причиняю ему / ей?
Любая помощь будет оценена! Кстати, я очень плохо знаком с MySQL и базами данных в целом, так что будьте осторожны:)
2 ответа
Мы используем такую ситуацию в нашем офисе для тестирования / резервного копирования / производства.
Наша ситуация такова:
- Производство получает все пишет
- Реплика Prod Slave получает все обновления (при сбое)
- Локальная подчиненная реплика получает все обновления (для ro /backup)
- Тестовый сервер перезаписывается каждое утро от локального раба.
Чтобы упростить последнюю часть, сначала мы блокируем локальное ведомое устройство ("FLUSH TABLES WITH READ LOCK;"), затем мы просто используем linux LVM, чтобы сделать снимок хранилища данных локальной подчиненной реплики (поэтому мы имеем согласованное снимок диска). Затем мы используем rsync для копирования из снимка локального ведомого поверх dar dir на тестовом сервере. Это побочный эффект от хранения новых таблиц, которые не были перенесены в производство, так что текущие проекты с новой функциональностью не будут сорваны.
Это прекрасно работает с таблицами MyISAM, что мы и используем, мы не переключились на InnoDB. Боюсь, я не уверен, что часть rsync будет работать правильно с InnoDB. Если вы используете InnoDB, вы, вероятно, можете обойтись без mysqldump> dumpfile.sql и mysql
Вопрос 1:
В Linux вы можете использовать записываемые снимки LVM для создания замороженных изображений вашей реплики, которые затем вы можете изменить на содержимое своего сердца, не затрагивая вашу истинную копию.
Это может работать примерно так:
На реплике:
stop true-replica mysql instance;
create a writeable snapshot;
start throwaway-replica mysql instance;
restart true-replica and restart replication;
Затем вы можете делать все, что вам нравится, с одноразовой репликой, а затем, как только вы закончите с ней, остановите экземпляр и удалите снимок.
Вопрос 2: Мне не ясно, что вы имеете в виду. Как правило, репликация MySQL работает непрерывно, поддерживая актуальность вашей реплики, почти не влияя на мастер.
Вопрос 3: MySQL очень прост в администрировании. LVM может потребоваться немного привыкнуть, и может потребоваться дополнительное дисковое пространство.
Шломо - какая-то ваша терминология сбивает с толку. Для баз данных термин "репликация" имеет тенденцию означать механизм для поддержания удаленной копии базы данных в актуальном состоянии. Для этого необходимо, чтобы мастер репликации отслеживал изменения данных - что MySQL делает с двоичным журналом, содержащим все обновления, вставки, удаления, которые были применены. Ведомое устройство репликации должно получить эти зарегистрированные изменения и затем применить их к своему собственному набору данных.
Инициализация раба может быть сложной. Вам нужен дамп, содержащий моментальный снимок базы данных master в данный момент времени - что даст вам большинство механизмов дампа базы данных - и точка в журнале репликации, что будет записано следующее обновление / удаление / вставка - опять же, многие базы данных процессы дампа могут включать эту точку репликации в дамп. Затем вы восстанавливаете подчиненное устройство репликации, используя дамп, и настраиваете его для репликации из точки репликации, в которой был создан дамп.
Создание файла дампа может быть навязчивым: для таблиц MyISAM вам необходимо либо остановить сервер MySQL и скопировать содержимое datadir в ваш файл дампа, либо заблокировать все таблицы, которые будут включены в дамп, и либо скопировать файлы необработанных таблиц из datadir или mysqldump необходимые таблицы, удерживая блокировку на время. Пока блокировка удерживается, обновления заблокированных таблиц будут остановлены на время процесса дампа, что может быть навязчивым.
Для Innodb mysqldump может использоваться для создания дампа без особого влияния на ваших постоянных пользователей базы данных. Внутренне он создаст моментальный снимок сбрасываемых данных, что позволит включить согласованный набор данных в дамп, даже когда пользователи обновляют одни и те же таблицы. Это повлияет на производительность, а также потребует места для хранения снимка - примерно такого же размера строк, которые были изменены другими пользователями во время создания дампа. Очевидно, что чем больше изменений, тем больше используется дисковое пространство. После завершения дампа возвращается пространство, используемое для хранения снимка.
Как только ваша реплика построена, влияние на ведение репликации на ведомое устройство будет незначительным - обычно всего несколько процентов. Вся настоящая работа выполняется ведомым, обновляющим свой набор данных, когда изменения извлекаются из журналов репликации. Используя встроенную функцию репликации MySQL, большинство пользователей могут поддерживать репликацию в течение всего дня, не оказывая значительного влияния на основную базу данных.
Если вы хотите, чтобы подчиненное устройство передавало изменения, все, что вам нужно сделать, это запустить и остановить репликацию на подчиненном устройстве в начале и конце периода. Пока ваш мастер не очень занят, ведомый обычно довольно быстро догоняет текущее состояние.
Административные издержки - ведение журналов репликации на главном сервере. На диске должно быть достаточно места для хранения журналов, по крайней мере, на несколько дней, предпочтительно на несколько недель. Чем дольше хранятся журналы репликации, тем дольше ваши дампы остаются жизнеспособными для использования при инициализации реплик. Если журналы репликации, связанные с вашим дампом, были очищены, то ваш дамп нельзя использовать для создания реплики. MySQL может быть настроен на удаление журналов после того, как они превысили определенный возрастной порог, поэтому не требуется никаких сценариев ротации журналов.
Обычный шаблон состоит в том, что, когда у вас есть хорошая реплика, вы используете ее для создания дампов, что позволяет вообще избежать какого-либо воздействия на главный сервер. В реплике, из которой вы берете дампы, должна быть включена функция "log-slave-updates", чтобы она, в свою очередь, поддерживала журнал репликации всех изменений, внесенных в нее напрямую (что является плохой идеей, поскольку тогда ваша реплика будет отклоняться от главной) и каждое изменение, поступившее через поток репликации, которое по умолчанию не добавляется в журнал репликации.
Я предлагаю вам поиграть с некоторыми тестовыми машинами, настроить репликацию и посмотреть, что произойдет. Это очень легко и быстро сделать, если у вас есть навык. Также обратите внимание на доступные опции фильтрации репликации, которые могут быть полезны, если вы хотите реплицировать только подмножество базы данных master. Это в руководстве MySQL: