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

42

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

deployment

1

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

— Дэн МакГрат

@Dan McGrath: если предположить, что у вас действительно может быть время простоя, я работаю на систему, которая (обычно) не работает всего 4 раза в год (отключение по кварталу) и максимум на 15 минут каждый раз (в течение которого трафик ставится в очередь). .. изменения в базе данных тщательно изучаются :)

— Матье М.

2

Это был бы отличный вопрос для dba.stackexchange.com , который выйдет в публичную бета-версию через несколько часов.

— Ларри Коулман

20

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

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

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

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

— Tangurena
источник

7

Как вы предлагаете объединить новые данные из БД М и БД N? У них обоих будут новые, обновленные и удаленные записи, которых нет у других.

— sixtyfootersdude

@Tangurena, вы можете ответить на комментарий выше?

— Китайско

9

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

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

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

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

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

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

— Матье М.
источник

1

На самом деле, для перспективного планирования и адаптивности, выбрать * из бесконечно лучше, чем перечислять столбцы вручную. Использование явных имен столбцов в большинстве случаев приводит к большим техническим ошибкам. Если ваш код ломается от новых столбцов, ваш код уже сломан.

— Морг.

@ Морг .: Не совсем. В целях безопасности вам необходимо использовать переменные связывания, которые в используемой мной среде (по крайней мере) требуют предоставления переменных для записи, и должно быть ровно столько же переменных, сколько имеется выходных столбцов, что select *означает, что код прерывается, если добавлен новый столбец (из-за отсутствия переменной для записи в него). Конечно, это может быть результатом использования строго типизированного языка.

— Матье М.

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

— Морг.

@ Морг .: Я не понимаю, как select *это более надежно и безопасно. Если раньше вы использовали, select one, two from ...то вы использовали только oneи two; Если thirdон добавлен в таблицу, то он вам не нужен (здесь), поэтому нет причин для его извлечения. И если вам нужно внезапно использовать его, то вы измените код, так что вы можете изменить запрос на этом этапе!

— Матье М.

@ Морг .: Ну, кажется, мы говорим мимо друг друга, вероятно, потому что наш опыт отличается. Я работаю с продуктами, в которых производительность является первостепенным свойством, и это означает, что они selectдолжны быть как можно более избирательными (и подпадающими под индекс), в противном случае я провозглашаю тост (даже до обязательных объединений). Мне жаль говорить, но подход, который вы описываете, был полным провалом в этих продуктах.

— Матье М.

5

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

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

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

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

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

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

— Дэн МакГрат
источник

1

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

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

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

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

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

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