Zero downtime (или около нуля) изменения схемы db

Question

Мне было интересно, как/если люди работали над изменениями схемы db, которые в противном случае могли бы привести к тому, что производственная система была бы отключена. Кажется, что с добавлением изменений, которые каким-то образом ограничены (например, уникальное ограничение), было бы трудно выполнить b/c приложение, и db должно измениться одновременно, иначе ошибки будут происходить либо в данных, либо в приложении.

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

Какие методы используются людьми для решения этих проблем?

Спасибо, Маниш

Answer 1

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

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

Answer 2

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

Answer 3

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

Затем вы переключаете роли ведущего/подчиненного устройства и обновляете другую схему базы данных. Синхронизируйте их и верните обновленного раба в онлайн.

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