История изменений

2. С oldsql снять подный дамп (все БД и таблицы)
3. Перенести дамп на newsql, импортировать
4. Настроить репликацию master-slave между oldsql и newsql

Это делается в несколько другой последовательности:

0. отключить все сервисы которые цепляются к oldsql.

1. Переделать конфиг oldsql как master с row-based репликацию, потом временно запустить в read-only режиме.

2. С oldsql снять годный ПОЛНыЙ дамп (все БД и таблицы И ПРОЦЕДУРы И АККАУНТы и т.д.), и ЗАОДНО с этом дампе снять и записать позицию для слейва для синхронизации с бинлогах.

3. Можно запустить обратно oldsql нормально в read-write (и сервисы)

Далее можно конфигурить слейв как и когда удобно:

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

1. Разные версии mysql на хостах, есть проблемы с репликацией?

Скорее всего будут. Нужно читать доки - но разница в версий слишком большая - а это всегда было слабым местом при mysql репликации.

Я бы для верности сделал без репликацию:

• подготавливаем наперед полностью сервер с newsql и необходимое окружение (пока oldsql работает).
• Потом в один присест: выключаем все сервисы, выставляем oldsql в read-only, делаем полный дамп, импортируем его на новом сервере в newsql, переключаем конфиги сервисов чтобы работали с машине где newsql, выключаем oldsql полностью, запускаем сервисы.

Дополнительный даунтайм (по сравнению со сценарием с репликации), будет на:

• перетаскивание дампа с одного сервера на другого
• импортирование дампа в newsql
• переключениe конфигов apps/services чтобы конектились к newsql

Это возможно, не так много (зависит от размера базы).

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

2. С oldsql снять подный дамп (все БД и таблицы)
3. Перенести дамп на newsql, импортировать
4. Настроить репликацию master-slave между oldsql и newsql

Это делается в несколько другой последовательности:

0. отключить все сервисы которые цепляются к oldsql.

1. Переделать конфиг oldsql как master с raw-based репликацию, потом временно запустить в read-only режиме.

2. С oldsql снять годный ПОЛНыЙ дамп (все БД и таблицы И ПРОЦЕДУРы И АККАУНТы и т.д.), и ЗАОДНО с этом дампе снять и записать позицию для слейва для синхронизации с бинлогах.

3. Можно запустить обратно oldsql нормально в read-write (и сервисы)

Далее можно конфигурить слейв как и когда удобно:

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

1. Разные версии mysql на хостах, есть проблемы с репликацией?

Скорее всего будут. Нужно читать доки - но разница в версий слишком большая - а это всегда было слабым местом при mysql репликации.

Я бы для верности сделал без репликацию:

• подготавливаем наперед полностью сервер с newsql и необходимое окружение (пока oldsql работает).
• Потом в один присест: выключаем все сервисы, выставляем oldsql в read-only, делаем полный дамп, импортируем его на новом сервере в newsql, переключаем конфиги сервисов чтобы работали с машине где newsql, выключаем oldsql полностью, запускаем сервисы.

Дополнительный даунтайм (по сравнению со сценарием с репликации), будет на:

• перетаскивание дампа с одного сервера на другого
• импортирование дампа в newsql
• переключениe конфигов apps/services чтобы конектились к newsql

Это возможно, не так много (зависит от размера базы).

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