Представим себе проект, который должен работать 24/7, проект, использующий базу данных mysql и типичную ситуацию, приходит разработчик и говорит:
В табличке, в которой сейчас 300 млн строк, я забыл добавить поле и индекс по нему, а остановка работы прода с базой недопустима, придумай что-нибудь.
Если попробовать погуглить на тему, то в основном встречаются советы по созданию второй таблички, постепенному копирования туда данных («insert into T select * from S limit OFFSET») и затем переименовыванию таблиц, но подобный механизм имеет существенные недостатки, например данные в исходной таблице могут измениться, сразу после копирования, а т.к. залочить таблицу на запись нельзя, то целостность данных будет под вопросом.
Можно копировать данные внешним кодом с учетом всех изменений синхронно в 2 таблицы, в читать только непрочитанное из старой в новую, но это требует изменения в коде приложения, что не всегда возможно.
А существуют ли условия, когда подобный альтер можно сделать на ходу? Безусловно да, их несколько, но я расскажу только один вариант для моего сферического коня в вакууме.
Дано — база mysql на 2 серверах с мастер-мастер репликацией и внешний механизм (haproxy, конфиг приложения и т.п.), который показывает какой из инстансов mysql активен в коде. Т.е. мы имеем возможность переключать запросы с одного сервера на другой.
Реплика двухсторонняя:
сервер1<==>сервер2
сервер1 — логический мастер, т.е. он получает запросы с кода приложения.
1. Отключаем слейва на сервере1 (mysql> stop slave;). Т.к. запросы на сервера2 не идет, то отключение реплики в этом направлении не вызовет негативных последствий для целостности данных на обоих серверах.
2. На сервер2 выполняем alter, данный запрос залочит таблицу только на сервер2, но к нему сейчас прод не обращается, это не вызывает проблем, а значит это безопасно.
3. Следим за отставанием от мастера на сервер2, команда show slave status; обращаем внимание на Seconds_Behind_Master. Отставание вызвано тем, что запросы к залоченной таблице во время alter не проигрываются на слейве сервер2, они накапливаются в replay-log и после выполнения alter они проигрываются.
4. Далее мы получает на сервер1 устаревшую таблицу, а на сервер2 таблицу с новым, требуемым нам, форматом, нам надо переключить логического мастера на сервер2, переключаем.
5. выключаем на сервер1 лейва, например через mysqladmin start. что приводит к тому, что alter приходит с сервер2 на сервер1 и модифицирует там таблицу.
6. На всякий случай дожидаемся что сервер1 догнал реплику. Если требуется, опять переключаем логического мастера (например бывает хардкод снятия бэкапов с сервера2 и чтобы логического мастера бэкапы не тормозили надо его переключить).
А как подобные задачи решаете вы?
Автор: ibKpoxa
