AWS RDS mysqldump висит
Я пытаюсь перенести данные между экземплярами RDS MySQL. Я не могу использовать моментальные снимки, потому что с помощью этой миграции я хочу зашифровать базовый диск и обновить версии (5.1.73a до 5.5.41). Данные в подавляющем большинстве находятся в одной таблице; В целом, БД весит 24,3 ГБ, а 23,9 ГБ сосредоточены в одной таблице (таблица входа пользователя).
Стремясь ограничить время простоя, я создаю резервные копии исторических данных в этой одной таблице - то есть до простоя перенесу все чтения из таблицы входа в систему, где идентификатор меньше 89 000 000, и во время строк простоя, где идентификатор больше, чем или равно 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, и глубины очереди, снова spikey, около 20. Я попытался установить почти каждый тайм-аут до 1000 секунд, удваивая размер журнала бина, очень мало эффекта. Мой коллега полагает, что это проблема с записью IOPS (это экземпляр на основе SSD без подготовленных IOPS для записи), но мы взяли ту же тактику с аналогичными серверами и не сталкивались с такой же проблемой. Источником является недавнее изображение текущего производственного сервера с магнитным диском.
Что мне не хватает? Благодарю.
2 ответа
В моей ситуации подход, который в конечном итоге сработал, включал в себя отключение использования журнала bin, как упоминалось здесь. В частности, я вернул настройки группы параметров обратно в нормальное состояние, отключил журнал bin, установив сохранение 0, сбросил SQL в файл, а затем просто загрузил его mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database} < ${filename},
Весь упомянутый выше мониторинг теперь намного более стабилен: записи в iops остаются стабильными на уровне ~600, а глубина очереди на уровне ~10 (и журнал bin, конечно, равен 0). Фактический процесс составляет в среднем около 1 МБ / с, что может быть быстрее, но все равно примерно в три раза быстрее, чем то, что я испытывал раньше - и, конечно, я сейчас не разрываю соединения.
Вместо выполнения дампа и перезагрузки я бы временно настроил репликацию между двумя серверами MySQL, где главный - это старый сервер, а ведомый - новый. Затем вы можете просто позволить этому занять столько времени, сколько потребуется, чтобы закончить, и когда это будет сделано, вы можете прервать репликацию, отменить настройку нового экземпляра как подчиненного устройства репликации и начать использовать его вместо исходного сервера. Это ограничивает требуемое время простоя всего несколькими моментами в самом конце процесса, когда вы нарушаете репликацию и переключаете сервер MySQL, используемый вашим приложением.