Ускорение преобразования из MyISAM в InnoDB

У меня есть MySQL MyISAM-таблица MySQL объемом 1,5 ГБ (данные 1,0 ГБ, индексы 0,5 ГБ), которые я собираюсь преобразовать в InnoDB.

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

Мои вопросы:

  • Какие параметры конфигурации MySQL необходимо настроить для ускорения ALTER TABLE table_name ENGINE=InnoDB;?

  • Какие еще трюки можно использовать для ускорения преобразования таблицы производственной базы данных из MyISAM в InnoDB?

Ответы

Ответ 1

  • Установка большого файла innodb_buffer_pool_size (2 ГБ или более)
  • preeread ваши старые файлы данных/индексации myisam с помощью команд оболочки
  • увеличить innodb_log_file_size (256 МБ)
  • Сделайте таблицу alter в X параллельных потоках, где X - количество ядер процессора на вашем сервере.
  • другие мелкие настройки для преобразования (innodb_doublewrite = 0, innodb_flush_log_at_trx_commit = 0)

настройка innodb_buffer_pool_size как можно выше является типичным способом ускорения создания таблиц innodb - ваш набор данных выглядит так, как будто он может вписываться в пул буферов innodb объемом 2 ГБ, поэтому любой достойный сервер с 64 битами должен это допускать. alter table type = innodb также быстрее, чем dump + reimport, и его легко запускать параллельно.

Также убедитесь, что вы увеличили файл innodb_log_file_size со значения по умолчанию от 5Mb до 128 или 256MB. Осторожно с этим, и ему нужно чистое выключение + стирание старого ib_logfile *.

Если у вашего сервера есть что-то вроде 8 ГБ оперативной памяти, и что вы запускаете 64-разрядную версию mysql, я бы предложил 2GB innodb_buffer_pool, и вы даже можете предварительно просмотреть старые файлы MYD и MYI перед закрытием на время простоя, чтобы они быть в кеше OS OS, когда начинается реальная работа.

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

Удачи.

Ответ 2

Если вы после быстрого (хотя и довольно lo-fi) решения, вы можете просто экспортировать данные в текстовый файл (через mysqldump), изменить тип таблицы на InnoDB в результирующем текстовом файле и затем повторно импортировать данных.

Тем не менее, вам нужно будет протестировать это, импортировав в другую базу данных, чтобы не было проблем.

Ответ 3

Таблица будет недоступна только для записи; reads будет продолжать доступ к старой таблице MyISAM на время ALTER.

Серьезно, восстановление таблицы 1.5G не должно занять много времени, если ваше приложение не может терпеть это количество времени простоя, у вас должна быть какая-то система HA, уже используемая для этого. Предположительно, ваша группа технической поддержки может опубликовать уведомление, чтобы сообщить пользователям о времени простоя и дать достаточное предупреждение, вы сделаете это в спокойное время дня/недели (обычно мы находим, что утреннее утро - хорошее время, но это может измениться, если у вас много клиентов в мусульманских странах)

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

Ответ 4

Используя pt-online-schema-change, ваша проблема будет неактуальной. pt-online-schema-change - это инструмент командной строки, разработанный Percona (возможно, это топ-консультант MySQL в мире), чтобы решить эту проблему очень проблема. Он позволяет вам выполнять инструкции ALTER на любой таблице, не блокируя ни чтения, ни записи, что, скорее всего, ваша цель ACTUAL, если вы говорите, что пытаетесь ускорить это преобразование в процессе производства.

После установки Percona Toolkit вы просто выполните следующую команду в своей оболочке O/S:

$ pt-online-schema-change h=your_host.com,t=your_db.your_target_table --alter "ENGINE=InnoDB"