Модифікація стовпців дуже великих таблиць mysql з невеликим простоєм або взагалі

Мені періодично потрібно вносити зміни до таблиць у mysql 5.1, в основному додаючи стовпці. Дуже просто з командою alter table. Але в моїх таблицях зараз до 40 мільйонів рядків, і вони швидко зростають ... Тож ці команди змінних таблиць займають кілька годин. Через пару місяців вони займуть дні, я здогадуюсь.

Оскільки я використовую amazon RDS, я не можу мати невільників-серверів, щоб грати, а потім просувати їх до майстерності. Тож моє запитання, чи є спосіб зробити це з мінімальним простоєм? Я не заперечую за тим, щоб операція займала години чи навіть дні, якщо користувачі все-таки можуть використовувати db, звичайно ... Чи можуть вони хоча б читати під час додавання стовпців? Що станеться, якщо мій додаток намагається записати? Вставити чи оновити? Якщо це не вдається відразу, це насправді не так вже й погано, якщо він просто зависає і створює проблеми для db-сервера, це велика проблема ..

Це має бути досить поширеним питанням масштабування, кожен повинен додати стовпці. Що зазвичай робиться для виробничого db? Раб -> майстер міграції?

Оновлення - я забув згадати, що я використовую механізм зберігання innodb

Мені періодично потрібно вносити зміни до таблиць у mysql 5.1, в основному додаючи стовпці.

Не варто. Насправді ні. Просто ні. Це має бути дуже рідкісним випадком, коли це коли-небудь необхідно.

Якщо припустити, що ваші дані дійсно нормалізуються для початку, правильним способом вирішення проблеми є додавання нової таблиці зі співвідношенням 1: 1 до базової таблиці (необов'язково для нової таблиці).

Необхідно регулярно додавати стовпці, як правило, є індикатором бази даних, яка не нормалізується - якщо ваша схема не нормалізована, то це проблема, яку потрібно виправити.

Нарешті, якщо ваша схема дійсно, справді нормалізується, і ви дійсно, дійсно повинні продовжувати додавати стовпці:

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

Мені довелося це зробити недавно. Що рекомендував Amazon, це використання інструментарію Percona. Я завантажив його і зміг запустити щось на кшталт:

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

і це чудово працює. Він говорить вам, скільки часу залишилось у процесі.

Він фактично створює нову таблицю з новим стовпцем, а потім копіює наявні дані. Крім того, він створює тригер, щоб нові дані також були перенесені на нову таблицю. Потім він автоматично перейменовує таблиці, скидає стару таблицю, і ви працюєте з новим стовпцем і без простоїв, поки ви чекали оновлень.

symcbean дає деякі ґрунтовні рекомендації .

Щоб відповісти на ваше запитання, найпростіший і найкращий спосіб пом'якшити вплив - це реплікація декількох баз даних. Подвійний майстер із відповідною процедурою відмови, зупиняючи реплікацію на активний, що дозволяє змінювати неактивний, не впливаючи на активний.

Ви потенційно можете це зробити в одній прямій базі даних і мінімізувати вплив, використовуючи процедуру, аналогічну тій, яку я детально описав у цій відповіді . Справді, це схоже на описаний у символічній формі, але включає технічні деталі. Ви можете також використовувати поле auto_increment, а не лише часову позначку.

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

З посібника: http://dev.mysql.com/doc/refman/5.1/uk/alter-table.html

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

Отже, читання буде добре працювати. Записи будуть зупинені, але виконані згодом. Якщо ви хочете запобігти цьому, вам доведеться змінити програмне забезпечення.

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

1. Скористайтеся прямим НАЗАДАМИ та нехай він працює (X кількість годин або день)
2. Переконайтеся, що у вас є стовпець часової позначки в базі даних або що вона генерує журнали реплікації
   • Створіть копію (B) таблиці (A)
   • додайте нові стовпці до B (це все одно блокуватиметься з myisam)
   • відключення транзакцій
   • перейменуйте оригінальну таблицю (A) як щось інше (резервне копіювання)
   • перейменуйте нову таблицю (B) з назвою вихідної таблиці (A)