Модификация столбцов очень больших таблиц mysql практически без простоев

Мне периодически нужно вносить изменения в таблицы в MySQL 5.1, в основном добавляя столбцы. Очень просто с помощью команды alter table. Но в моих таблицах сейчас до 40 миллионов строк, и они быстро растут ... Так что эти команды изменения таблицы занимают несколько часов. Я думаю, через пару месяцев они займут дни.

Поскольку я использую amazon RDS, у меня не может быть подчиненных серверов, с которыми можно поиграть, а затем повысить их до мастерства. Итак, мой вопрос: есть ли способ сделать это с минимальным временем простоя? Я не возражаю против операции, занимающей часы или даже дни, если пользователи все еще могут использовать БД, конечно ... Могут ли они хотя бы читать, когда добавляются столбцы? Что произойдет, если мое приложение попытается написать? Вставить или обновить? Если он сразу выходит из строя, это на самом деле не так уж плохо, если он просто зависает и вызывает проблемы для сервера БД, это большая проблема.

Это должно быть довольно распространенной проблемой масштабирования, все должны добавлять столбцы. Что обычно делается с производственной БД? Раб -> Мастер миграции?

Обновление - я забыл упомянуть, что я использую механизм хранения innodb

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

Не. Нет, правда. Просто не надо. Это должно быть очень редким случаем, когда это когда-либо необходимо.

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

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

Наконец, если ваша схема действительно нормализована и вы действительно должны продолжать добавлять столбцы, тогда:

1. Убедитесь, что у вас есть столбец отметки времени в базе данных или что она генерирует журналы репликации
2. Создайте копию (B) таблицы (A)
3. добавьте новые столбцы в B (это все еще будет блокироваться с помощью myisam)
4. отключить транзакции
5. переименовать исходную таблицу (A) как-то еще (резервная копия)
6. переименуйте новую таблицу (B) с именем исходной таблицы (A)
7. воспроизвести транзакции с начала операции из журнала репликации или из таблицы резервного копирования
8. включить транзакции.

Я просто должен был сделать это недавно. Amazon рекомендовал использовать Percona Toolkit. Я скачал его и смог запустить что-то вроде:

./pt-online-schema-change h=databasenameHostName,D=databasename,t=tablename --recursion-method=none --execute --user username --password password --alter "MODIFY someColumn newDataType"

и это прекрасно работает. Он говорит вам, сколько времени осталось в процессе.

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

Symcbean дает некоторые твердые рекомендации .

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

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

В конечном счете, если ваш набор данных становится настолько большим, вам также необходимо рассмотреть возможность архивирования между базами данных OLTP и OLAP . Ваш набор данных транзакций не должен быть таким большим, если вы разрабатываете соответствующим образом.

Из руководства: http://dev.mysql.com/doc/refman/5.1/en/alter-table.html

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

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

Я нахожусь в аналогичной ситуации, когда я должен изменить 1 из моей таблицы транзакций, которая составляет почти 65 ГБ. Я слышу 2 решения

1. Используйте прямой ALTER и дайте ему поработать (X числа часов или дня)
2. Убедитесь, что у вас есть столбец отметки времени в базе данных или что она генерирует журналы репликации
   • Создайте копию (B) таблицы (A)
   • добавьте новые столбцы в B (это все еще будет блокироваться с помощью myisam)
   • отключить транзакции
   • переименовать исходную таблицу (A) как-то еще (резервная копия)
   • переименуйте новую таблицу (B) с именем исходной таблицы (A)