Назад | Перейти на главную страницу

Изменение длины столбца на большой таблице Innodb с минимальным временем простоя

Мне нужно изменить длину столбца в таблице MySQL innodb с 164 млн строк. Вот сценарий, который я хочу запустить: ALTER TABLE SESSION_DECISION CHANGE COLUMN NAME NAME VARCHAR (255);

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

(это было посреди ночи - использование было минимальным, но я нервничал).

Я использую MySQL 5.0.77.

Есть ли предложения относительно того, как я могу изменить столбец с минимальным временем простоя?

Лучше всего настроить подчиненную базу данных с помощью репликации mysql. Предполагая, что изменение схемы является аддитивным, вы можете выпустить обновление для этой реплики, которая будет заблокирована на время обновления. Как только это будет сделано, и убедитесь, что ваше ведомое устройство догнало все обновления, затем объявите небольшое время простоя, чтобы продвинуть вашу подчиненную базу данных на ведущее устройство.

Вы можете найти инструкции по настройке репликация mysql здесь.

Если ваши данные строго вставлены (а не обновлены), вы, вероятно, могли бы сделать что-то вроде:

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

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

Что касается способа сокращения времени простоя, - напрямую вы не можете этого сделать. Я полагаю, у вас нет резервной копии базы данных?

Я слышу, как многие люди передергиваются, когда вы упоминаете о запуске базы данных на виртуальной машине. По правде говоря, это зависит от ВМ. Если вы не виртуализируете оборудование, вы не страдаете от потери производительности, которой они опасаются. Используя паравиртуализацию через Xen (я слышал хорошие отзывы об OpenVZ, но не использовал его), вы можете делать в точности то, что сказал Дейв Чейни (что является правильным подходом), и использовать только одно оборудование.

Инструменты / концепции в игре:

  1. Xen Virtualization (для паравиртуализации)
  2. LVM (для копирования ваших данных через снимок)
  3. виртуальные интерфейсы (eth0: 1, eth0: 2 и т. д.), ifup и ifdown для реализации ...
  4. STONITH

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