Я работаю с производственной базой данных MySQL и хотел бы:
QUESTION 1: Это возможно? Я знаю, что (1) возможно, потому что здесь есть документация http://dev.mysql.com/doc/refman/5.0/en/replication.html. Но я не уверен, что смогу получить и (1), и (2). Я спрашиваю, потому что мне нужно написать код, который обращается к базе данных, и поскольку это производственная база данных, используемая всеми, бывают случаи, когда я не могу использовать базу данных. Я хотел бы написать тестовые программы, использующие реплицированное ведомое устройство (с непостоянным доступом на запись), и когда я убедился, что все в порядке, я запустил свою программу, используя главную базу данных, чтобы изменения были постоянными. Я хотел бы, чтобы мои записи отображались в ведомом устройстве, чтобы я мог убедиться, что они написаны правильно.
QUESTION 2: Можно ли легко реплицировать базу данных по частям? В базе данных есть таблица, которая действительно огромна. Я думаю, что база данных составляет порядка 4 ГБ. Я могу сделать репликацию только на выходных, чтобы не беспокоить всех. Но я боюсь, что одних выходных недостаточно для репликации всей базы данных. Итак, есть ли способ сделать это по частям? Или есть какой-нибудь сверхбыстрый способ репликации базы данных?
QUESTION 3: Насколько сложно будет все настроить? Я предполагаю, что это займет у меня много времени из-за неопытности, но предположим, что у меня есть администратор баз данных, который сделает эту работу за меня, сколько проблем я доставляю ему / ей?
Любая помощь будет оценена! Кстати, я новичок в MySQL и базах данных в целом, так что будьте осторожны :)
Мы используем такую ситуацию в нашем офисе для тестирования / резервного копирования / производства.
Наша ситуация такова:
Чтобы упростить последнюю часть, сначала мы блокируем локальное подчиненное устройство ("FLUSH TABLES WITH READ LOCK;"), затем мы просто используем LVM Linux для создания снимка хранилища данных локальной подчиненной реплики (так что у нас есть согласованный on- снимок диска). Затем мы используем rsync для копирования из моментального снимка локального подчиненного устройства поверх каталога dar на тестовом сервере. Это имеет побочный эффект, заключающийся в сохранении новых таблиц, которые не были перенесены в производственную среду, поэтому текущие проекты с новой функциональностью не сдуваются.
Это прекрасно работает с таблицами MyISAM, которые мы используем, мы не перешли на InnoDB. Боюсь, я не уверен, будет ли часть rsync работать правильно с InnoDB. Если вы используете InnoDB, вам, вероятно, удастся избежать проблем с mysqldump> dumpfile.sql и mysql <dumpfile.sql на тестовом сервере.
Вопрос 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 делает с двоичным журналом, содержащим все примененные обновления, вставки и удаления. Подчиненное устройство репликации должно получить эти зарегистрированные изменения и затем применить их к своему собственному набору данных.
Инициализация ведомого устройства может быть сложной задачей. Вам нужен дамп, содержащий моментальный снимок основной базы данных в данный момент времени - что дает вам большинство механизмов дампа базы данных - и точка в журналах репликации, в которой будет записано следующее обновление / удаление / вставка - опять же, многие базы данных процессы дампа могут включать эту точку репликации в дамп. Затем вы восстанавливаете подчиненное устройство репликации, используя дамп, и настраиваете его для репликации из точки репликации, в которой был создан дамп.
Создание файла дампа может быть навязчивым: для таблиц MyISAM вам нужно либо остановить сервер MySQL и скопировать содержимое datadir в файл дампа, либо заблокировать все таблицы, которые будут включены в дамп, и либо скопировать необработанные файлы таблиц из datadir. или mysqldump требуемые таблицы, удерживая блокировку на время. Пока блокировка удерживается, обновления заблокированных таблиц будут приостановлены на время процесса дампа, что может быть навязчивым.
Для Innodb mysqldump можно использовать для создания дампа без особого влияния на обычных пользователей базы данных. Внутренне он будет генерировать моментальный снимок сбрасываемых данных, позволяющий включить согласованный набор данных в дамп, даже когда пользователи обновляют одни и те же таблицы. Это повлияет на производительность, а также потребует места для хранения моментального снимка - примерно того же размера, что и строки, изменяемые другими пользователями во время создания дампа. Очевидно, что чем больше изменений, тем больше используется дисковое пространство. После завершения дампа возвращается пространство, занятое удерживанием снимка.
Как только ваша реплика будет построена, влияние на ведущее устройство поддержки репликации на ведомое устройство будет минимальным - обычно всего несколько процентов. Вся реальная работа выполняется ведомым устройством, обновляющим свой набор данных по мере того, как изменения проходят через журналы репликации. Используя встроенную функцию репликации MySQL, большинство пользователей могут поддерживать репликацию в течение всего дня без значительного воздействия на их основную базу данных.
Если вы хотите, чтобы подчиненное устройство передавало изменения, все, что вам нужно сделать, это запустить и остановить репликацию на подчиненном устройстве в начале и в конце периода. Пока ваш мастер не очень занят, подчиненный обычно довольно быстро догонит текущее состояние.
Административные издержки связаны с ведением журналов репликации на главном сервере. На диске должно быть достаточно места для хранения журналов за несколько дней, желательно за несколько недель. Чем дольше хранятся журналы репликации, тем дольше ваши дампы остаются пригодными для использования при инициализации реплик. Если журналы репликации, связанные с вашим дампом, были очищены, то ваш дамп нельзя использовать для создания реплики. MySQL может быть настроен на удаление журналов после того, как они превысили определенный возрастной порог, поэтому сценарии ротации журналов не требуются.
Как правило, после создания хорошей реплики вы используете ее для создания дампов, тем самым избегая какого-либо воздействия на главный сервер. Реплика, из которой вы берете дамп, должна иметь "log-slave-updates", чтобы он, в свою очередь, вел журнал репликации всех изменений, внесенных в нее напрямую (что является плохой идеей, потому что тогда ваша реплика будет отличаться от главной) и каждое изменение, прошедшее через поток репликации, которое по умолчанию не будет добавлено в журнал репликации.
Я предлагаю вам поиграть с некоторыми тестовыми машинами, настроить репликацию и посмотреть, что произойдет. Это очень легко и быстро сделать, если вы научитесь. Также обратите внимание на доступные параметры фильтрации репликации, которые могут быть полезны, если вы хотите реплицировать только подмножество главной базы данных. Это в руководстве MySQL: