Я пытаюсь перенести данные между экземплярами RDS MySQL. Я не могу использовать снимки, потому что при этой миграции я хочу зашифровать базовый диск и обновить версии (с 5.1.73a до 5.5.41). Данные в подавляющем большинстве расположены в одной таблице; в целом БД весит 24,3 ГБ, а 23,9 ГБ сосредоточены в одной таблице (таблица входа пользователя).
Стремясь ограничить время простоя, я создаю резервную копию исторических данных в этой одной таблице, то есть перед простоями передаю все чтения из таблицы входа в систему, где идентификатор меньше 89000000, и во время простоев строк, где идентификатор больше, чем или равно 89 000 000. Команда такая:
mysqldump -u${source_user} --opt --skip-add-drop-table -p${source_password} --host=${source_host} ${database} ${table_name} --where="${where_clause}" | sed 's/CREATE TABLE/CREATE TABLE IF NOT EXISTS/g' | mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database}
Это хакерский метод, но раньше он работал хорошо. Запускаю с третьего сервера.
Однако на этот раз у меня возникают проблемы. Я запустил его несколькими способами. Когда я запускаю его как один блок, пропускная способность чрезвычайно варьируется, и в конечном итоге весь процесс зависает без какой-либо сетевой нагрузки, продемонстрированной на координирующем сервере. Я также попытался разбить строки по идентификатору (т.е. seq 0 100000 89000000), который начинается отлично, но зависает на определенных фрагментах - например, средний фрагмент из 100 тыс. строк занимает около 8 секунд, но, возможно, одна из десяти строк занимает более 300 секунд. Меня бы даже не волновало, что иногда это длилось так долго, но бывает и такое:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table at row: 42158
Целевой экземпляр показывает использование ЦП на 100%, очень загруженные журналы бункера, пик записи iops, близкий к 600, и глубина очереди, снова острая, около 20. Я пробовал устанавливать почти каждый тайм-аут до 1000 секунд, удваивая размер журнала бункера. , с очень небольшим эффектом. Мой коллега предполагает, что это проблема с записью IOPS (это экземпляр на основе SSD без выделенных IOPS для записи), но мы использовали тот же подход с аналогичными серверами и не сталкивались с такой же проблемой. Источник - недавнее изображение текущего производственного сервера с магнитным приводом.
Что мне не хватает? Спасибо.
Вместо того, чтобы делать дамп и перезагрузку, я бы временно настроил репликацию между двумя серверами MySQL, где главный - старый сервер, а подчиненный - новый. Затем вы можете просто позволить этому занять столько времени, сколько потребуется для завершения, и когда это будет сделано, вы можете прервать репликацию, отключить новый экземпляр в качестве ведомого устройства репликации и начать использовать его вместо исходного сервера. Это ограничивает необходимое время простоя всего несколькими моментами в самом конце процесса, когда вы прерываете репликацию и переключаете сервер MySQL, который использует ваше приложение.
В моей ситуации подход, который наконец-то сработал, включал отключение использования журнала bin, как упоминалось Вот. В частности, я вернул свои настройки группы параметров в нормальное состояние, отключил журнал bin, установив значение 0 для хранения резервных копий, выгружал SQL в файл, а затем просто загружал его. mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database} < ${filename}.
Весь упомянутый выше мониторинг теперь намного более стабилен, при этом число операций записи в секунду остается стабильным на уровне ~ 600, а глубина очереди - на уровне ~ 10 (а журнал bin, конечно, равен 0). Фактический процесс составляет в среднем около 1 МБ / с, что могло бы быть быстрее, но все же примерно в три раза быстрее, чем то, что я испытывал раньше - и, конечно же, я не отключаю соединения сейчас.