Изменения нулевой простоя (или около нуля)

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

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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