ALTER TABLE без блокировки стола?

Question

При выполнении инструкции ALTER TABLE в MySQL вся таблица блокируется на чтение на время выполнения инструкции. Если это большая таблица, это означает, что операторы вставки или обновления могут быть заблокированы на долгое время. Есть ли способ сделать «горячее изменение», например, добавить столбец таким образом, чтобы таблицу можно было обновлять на протяжении всего процесса?

В основном меня интересует решение для MySQL, но я бы заинтересовался другими СУБД, если MySQL не может этого сделать.

Чтобы уточнить, моя цель - просто избежать простоя, когда новая функция, которая требует дополнительного столбца таблицы, запускается в производство. Любая схема базы данных будет изменяться со временем, это просто факт жизни. Я не понимаю, почему мы должны признать, что эти изменения неизбежно приведут к простоям; это просто слабо.

Answer 1

Как уже упоминал SeanDowney, pt-online-schema-change - один из лучших инструментов для выполнения того, что вы описали в этом вопросе здесь. Недавно я сделал много изменений схемы на живой БД, и все прошло довольно хорошо. Вы можете прочитать больше об этом в моем блоге здесь: http://mrafayaleem.com/2016/02/08/live-mysql-schema-changes-with-percona/.

Answer 2

Разница между Postgres и MySQL в этом отношении заключается в том, что в Postgres он не воссоздает таблицу, а модифицирует словарь данных, который похож на Oracle. Следовательно, операция выполняется быстро, хотя все еще требуется выделить исключительную блокировку таблицы DDL на очень короткое время, как указано выше другими.

В MySQL операция копирует данные в новую таблицу, блокируя транзакции, что было основной проблемой для администраторов баз данных MySQL до версии 5.6.

Хорошая новость заключается в том, что с момента выпуска MySQL 5.6 ограничение было в основном снято , и теперь вы можете наслаждаться настоящей мощью БД MYSQL.

Answer 3

Используя плагин Innodb, операторы ALTER TABLE, которые только добавляют или отбрасывают вторичные индексы, могут выполняться "быстро", т. Е. Без перестройки таблицы.

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

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

Answer 4

Если кто-то все еще читает это или собирается сюда приехать, это большое преимущество использования системы баз данных NoSQL, такой как mongodb. У меня была та же проблема, связанная с изменением таблицы для добавления столбцов для дополнительных функций или индексов для большой таблицы с миллионами строк и высокой записью. Это приведет к блокировке в течение очень долгого времени, поэтому выполнение этой операции с базой данных LIVE приведет к разочарованию наших пользователей. На маленьких столиках это может сойти с рук.

Я ненавижу тот факт, что мы должны "проектировать наши таблицы, чтобы избежать их изменения". Я просто не думаю, что это работает в современном мире веб-сайтов. Вы не можете предсказать, как люди будут использовать ваше программное обеспечение, поэтому вы быстро меняете ситуацию, основываясь на отзывах пользователей. С mongodb вы можете добавлять «столбцы» по своему усмотрению без простоев. Вы даже не добавляете их, вы просто вставляете данные с новыми столбцами, и это происходит автоматически.

Стоит проверить: www.mongodb.com

Answer 5

В общем случае ответ будет «Нет». Вы изменяете структуру таблицы, которая потенциально потребует много обновлений ", и я определенно с этим согласен. Если вы собираетесь делать это часто, то я предложу альтернативу" фиктивным "столбцам - используйте VIEW s вместо таблиц для * 1002. * данных. IIRC, изменение определения представления является относительно легким, а перенаправление через представление выполняется при компиляции плана запроса. Расход состоит в том, что вам придется добавить столбец в новую таблицу и сделайте представление JOIN в столбце.

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

Просто мысль.

Answer 6

Я бы рекомендовал один из двух подходов:

1. Создайте таблицы базы данных с учетом возможных изменений. Например, я работал с системами управления контентом, которые регулярно меняют поля данных в контенте. Вместо построения физической структуры базы данных, соответствующей исходным требованиям к полям CMS, гораздо лучше создать гибкую структуру. В этом случае используется текстовое поле большого двоичного объекта (например, varchar (max)) для хранения гибких данных XML. Это делает структурные изменения очень реже. Структурные изменения могут быть дорогостоящими, поэтому и здесь есть преимущество.

2. Имейте время обслуживания системы. Либо система переходит в автономный режим во время изменений (ежемесячно и т. Д.), А изменения планируются в течение дня с наименьшей интенсивностью трафика (например, 3-5 утра). Изменения производятся до запуска производства, поэтому у вас будет хорошая фиксированная оценка времени простоя.

2a. Имейте резервные серверы, чтобы при простое системы весь сайт не отключался. Это позволит вам «выкатывать» свои обновления в шахматном порядке, не разрушая весь сайт.

Варианты 2 и 2a могут быть неосуществимы; они имеют тенденцию быть только для более крупных сайтов / операций. Однако они являются действительными, и я лично использовал все варианты, представленные здесь.

Answer 7

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

MyISAM заблокирует все, если вы случайно упомянете имя таблицы, по телефону, в аэропорту. Это просто делает это ...

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

Answer 8

TokuDB может добавлять / удалять столбцы и добавлять индексы «горячими», таблица полностью доступна на протяжении всего процесса. Это доступно через www.tokutek.com

Answer 9

Не совсем.

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

Если вы планируете делать это много, вам лучше просто заполнить таблицу «фиктивными» столбцами, доступными для будущего использования.