Как вы обновляете свою производственную базу кодов / схему базы данных, не вызывая простоев?

Каковы некоторые методы обновления базы кода / схемы базы данных производственного сервера без каких-либо простоев?

Как правило, веб-сайты, над которыми я работал, предъявляли такие требования за балансировщиками нагрузки или имели отдельные места отработки отказа. В этом примере я предполагаю, что у вас есть один балансировщик нагрузки, 2 веб-сервера (A & B) и 2 сервера баз данных (M & N) - обычно серверы БД связаны через протоколирование журналов - по крайней мере, в мире SQL Server ).

1. Веб-сервер A должен быть отключен от балансировщика нагрузки (поэтому весь входящий трафик поступает на B).
2. Доставка журналов остановлена ​​(DB Server M будет обновляться первым).
3. Обновите веб-сервер A. Направьте конфигурацию на сервер БД M.
4. Протестируйте и убедитесь, что обновление сработало (обычно пользователи напрямую обращаются к IP-адресу).
5. Установите балансировщик нагрузки так, чтобы существующие сеансы продолжали идти в B. Новые сеансы переходят в A.
6. Дождитесь окончания всех сеансов на B (может быть полчаса или больше, обычно мы наблюдаем за трафиком и у нас запланирован 1-часовой перерыв).
7. Обновите B и N.
8. Проверьте и убедитесь, что обновление работает.
9. Снова настройте доставку журналов и проверьте, работает ли она.
10. Установите балансировщик нагрузки на обычную работу.

В очень сложных веб-приложениях этапы 1-5, описанные как шаги 1-5, могут занимать всю ночь и представлять собой электронную таблицу Excel на 50 страниц с указанием времени и номеров экстренных служб. В таких ситуациях обновление половины системы запланировано на 6 вечера до 6 утра, оставляя систему доступной для пользователей. Обработка обновлений для сайта DR обычно запланирована на следующую ночь - просто надеюсь, что ничего не сломается в первый день.

Там, где требуется время безотказной работы, исправления сначала тестируются в среде QA, которая в идеале соответствует оборудованию. Если они не показывают сбоев, они могут быть применены на регулярном графике, который обычно в выходные дни.

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

Вот некоторые ограничения для внесения изменений:

• он должен работать с существующим кодом, что означает, что код должен работать как со старой, так и с новой версиями схемы.
• это не должно вызывать такую ​​нагрузку на БД, что транзакции были бы остановлены (я смотрю на вас CREATE INDEX)
• это не должно приводить к потере данных (вы не можете удалить и заново создать таблицу)

Для того, чтобы схема была обратно совместимой, вы обычно можете ДОБАВИТЬ или ИЗМЕНИТЬ столбец, вы можете УДАЛИТЬ что-то, только если существующий код больше не использует его.

Если ваш код не может обработать изменение прозрачно, измените код перед изменением базы данных.

Простой совет по перспективному планированию: всегда указывайте имена столбцов в запросах БД (не используйте SELECT * FROM). Таким образом, у вас не будет новых столбцов, отображаемых в старых запросах.

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

Например, одна из наших основных систем, которую я помог обновить несколько лет назад, должна быть доступна 24/7. Он состоял из нескольких уровней, включая чистый уровень связи между уровнем пользовательского интерфейса за пределами площадки и бизнес-уровнем. Благодаря тому, что коммуникационный уровень был закодирован, любые будущие изменения в бизнес-уровне или схеме БД могут быть реализованы без реального сбоя. В худшем случае пользователь вступит в паузу в 10-30 секунд, когда изменения вступят в силу.

Если бы изменения были просто изменениями кода на бизнес-уровне, их можно было поставить в очередь и «включить» с задержкой всего в миллисекунды.

Это может быть сделано, потому что:

• Уровень связи может содержать сообщения. Это позволило нам иметь фактическое отключение на любом из уровней, кроме уровня пользовательского интерфейса, без необходимости выключать пользовательский интерфейс.
• Бизнес-уровень, обрабатываемый MVDB, называется UniData . Это держит весь код в памяти. После компиляции кода вы можете использовать команду, чтобы принудительно ввести новый объектный код в память, заменив старый.

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

Здесь другая точка зрения из мира встроенных систем баз данных и встроенных систем. Встраиваемые системы включают различное оборудование сетевой / телекоммуникационной инфраструктуры, и в этой области они часто говорят о 99,999% (пять 9) времени безотказной работы.

Мы (McObject) являемся поставщиком семейства встроенных систем баз данных eXtremeDB, в том числе eXtremeDB High Availability.

Во-первых, поймите, что «встроенная база данных» означает, что система баз данных - это библиотека, которая компилируется и связана с кодом вашего приложения; в этом смысле он «встроен» в ваше приложение.

В eXtremeDB High Availability имеется экземпляр MASTER вашего приложения (это может быть один или несколько процессов) и один или несколько экземпляров REPLICA вашего приложения. Когда реплика устанавливает соединение с мастером, она получает копию базы данных мастера через процесс, называемый «первоначальная синхронизация». Это можно сделать, пока мастер-приложение продолжает свою работу. После синхронизации он получает транзакции мастера через репликацию. Следовательно, реплика всегда содержит текущие данные и может вступить во владение (через процесс, называемый аварийным переключением) в случае отказа мастера.

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

На практике это означает, что вы можете создать более новую версию своего приложения (с новыми / удаленными таблицами, новыми / удаленными / измененными полями, новыми / удаленными индексами), присоединить эту новую версию своего приложения к мастеру, а затем вызвать это более новая реплика, чтобы стать новым мастером (т. е. принудительно переключиться на новую реплику, чтобы она стала мастером, а старый мастер отключился). Вуаля, вы перенесли свое приложение из версии N в N + 1, не прерывая доступность вашей системы. Теперь вы можете приступить к обновлению старого мастера и любых других реплик до версии N + 1.