Использование репликации MYSQL для ускорения изменений схемы и оптимизации таблиц

Я слышал, что многие люди используют схемы «ведущий-подчиненный», чтобы сократить время, затрачиваемое на смену схем, используя репликацию для установки нового временного мастера, затем останавливая перемещение и затем меняя роли, прежде чем начать снова. Я нашел пример (ниже), найденный при переполнении стека.

  1. Настройка ведомого
  2. Остановить репликацию.
  3. Сделать ALTER на подчиненном
  4. Пусть раб догонит хозяина
  5. поменяйте местами главный и подчиненный, чтобы подчиненный стал производственным сервером с измененной структурой и минимальным временем простоя

Это все очень хорошо, однако я не понимаю шаг 4, мне это не ясно.

Интересно, может ли кто-нибудь объяснить процедуру яснее.


mysql schema replication master-slave alter-table
person Community    schedule 01.12.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Пусть раб догонит хозяина

Пусть ведомый догонит ведущего, что означает, что ведомый отстает от ведущего на 0 секунд.

Это означает, что если репликация остановилась в какой-то момент (чтобы вы изменили таблицу),
она зарегистрирует время последней репликации.

Когда репликация возобновится,
она сравнивает текущую запись на главном сервере с последним временем репликации на подчиненном устройстве.

Однако эти процедуры кажутся недостатками.
Вы не можете изменить ведомое устройство и
ожидаемая схема в обновленном подчиненном устройстве такая же, как и в главном устройстве.

В столбце событий изменен тип, столбец удален,
что может привести к сбою репликации.

person ajreal    schedule 01.12.2010
comment
Вот о чем я думал, как можно реплицировать данные из старой схемы в новую, это не работает! любая идея, как придумать процедуру, которая делает? - person ; 01.12.2010
comment
Я полагаю, что только сценарий может выполнить эту работу, если я что-то упустил? - person ; 01.12.2010
comment
@andicrook - Если позволяет время простоя, выполните изменение непосредственно на главном сервере (изменение заблокирует чтение / запись таблицы), и mysql реплицирует изменение на каждое ваше подчиненное устройство. Насколько велика ваша база данных? В настоящее время вы выполняете какую-либо репликацию? - person ajreal; 01.12.2010
comment
@ajreal В данный момент я только изучаю масштабируемость mysql, и я пытаюсь добиться того, чтобы вносить изменения в схему в больших базах данных с минимальным временем простоя. Я читал много документов от людей, примерно объясняющих, как они достигают этого, многие говорят, используя репликацию master/slave и трюк с обменом рулонами master/slave (как в приведенном выше вопросе) или используя репликацию master/master, однако в них отсутствуют подробности или они пропускают детали. так что я не могу видеть всю картину. - person ; 01.12.2010
comment
Я понимаю, что они говорят, что для уловки мастер / ведомый заключается в том, что связь репликации нарушена, роли переключаются, поэтому система все еще работает, а затем вносятся изменения, однако недостающий бит заключается в том, как их снова синхронизировать без простоя - person ; 01.12.2010
comment
@andicrook - Вы можете определить время отсечки. После того, как ведомое устройство станет ведущим, вы можете добавить обратные записи, вставленные/обновленные/удаленные по истечении времени отключения от старого мастера к новому мастеру (сложно, не так просто обнаружить, можно выкопать из двоичного журнала). Однако, если вы разрешите использовать flush tables with read lock - dev.mysql.com/doc /refman/5.0/en/flush.html , которые упрощают весь переход (но этот блок пишется и ставится в очередь) - person ajreal; 01.12.2010
comment
Я думаю, что работа с копией таблицы вместо этого, обновление данных, а затем замена трюка - лучшее решение, как это делает facebook, но это скорее решение на основе сценария. - person ; 01.12.2010

arrow_upward
0
arrow_downward

секунд_за_мастером должно быть 0.

person kedar    schedule 01.12.2010
comment
да, но старые данные нельзя просто реплицировать в новую схему - person ; 01.12.2010