Существуют определенные задачи обслуживания базы данных, такие как реорганизация индексов, перемещение файлов, изменение схемы и т. Д., Которые требуют отключения любых приложений, использующих базу данных.
Какие есть хорошие стратегии для решения этой проблемы, кроме простой публикации на вашем сайте сообщения типа «мы будем работать с полуночи до 4 утра по восточному стандартному времени для обслуживания сервера»?
Если у вас есть решение для репликации / высокой доступности, то его использование во избежание простоев - очевидный выбор: обновите один сервер, пока другой работает, а затем переключитесь и обновите следующий.
Если у вас нет такой структуры, вы можете выполнить настройку мини-репликации на том же сервере, где у вас есть две копии каждой базы данных, и обновить одну, пока другая работает, а затем синхронизировать старую. Это все равно потребует некоторого времени простоя, но менее 4 часов.
Третий вариант, позволяющий избежать синхронизации обоих БД, - это взять копию базы данных, и пока поддерживается одна БД, копия и использующие ее приложения находятся в режиме только для чтения. После того, как вы закончите, вы просто переключите приложения на обновленную БД и снова начнете писать в базу данных.
Этот последний вариант, конечно, требует поддержки приложений и имеет смысл (есть приложения, в которых режим только для чтения не имеет смысла.)
Если вы используете SQL Server, вы всегда можете удалить фрагментацию индекса в режиме онлайн, начиная с SQL Server 2000. Команда DBCC INDEXDEFRAG всегда выполняет оперативную реорганизацию. Я написал его специально как онлайн-альтернативу DBCC DBREINDEX.
Начиная с SQL Server 2005, команда ALTER INDEX ... REORGANIZE заменяет DBCC INDEXDEFRAG и также всегда находится в оперативном режиме. Начиная с 2005 года, с Enterprise Edition вы можете выполнять перестроение индекса в режиме онлайн с помощью ALTER INDEX ... REBUILD ... WITH (ONLINE = ON). В начале и в конце операции требуется пара очень кратковременных блокировок таблиц, так что это не так оперативно, как РЕОРГАНИЗАЦИЯ (а перестройка индекса в основном онлайн - не такой уж хороший маркетинговый термин :-). Вы даже можете перемещать индексы в новые файловые группы, используя CREATE INDEX ... WITH DROP_EXISTING и указав ONLINE = ON.
Спасибо
Большинство задач обслуживания можно выполнить без перевод веб-сайта или приложения в автономный режим, если у вас есть репликация базы данных. Вы удалите одну БД из набора реплик, примените то, что вам нужно, и снова подключите ее к своему набору реплик. Пока он выключен, другие БД продолжат работу решения.
Когда вам нужно обновить схема базы данных, вы будете вынуждены перевести решение на несколько минут (или в состояние только для чтения) ЕСЛИ изменение ломает старую версию. Если ваша новая схема просто создает таблицы или поля, это не повлияет на старую версию.1, поэтому такое изменение схемы можно выполнить в Интернете2 и используя Сине-зеленое развертывание для вашего приложения, чтобы добиться высокой доступности.
Если ваша новая схема переименовывает существующее поле или удаляет его, для достижения 100% времени безотказной работы вам необходимо выполнить следующие действия:
Примечание 1: некоторые инструменты ORM, такие как .NET Entity Framework, связывают каждое изменение схемы с идентификатором миграции. Итак, когда вы развертываете новую версию схемы, старые приложения мгновенно ломаются. Этого также можно избежать если вы отключите эту проверку.
Заметка 2: если ваша новая схема добавляет уникальное ограничение, проверку или внешний ключ, команде alter table может потребоваться некоторое время, если у вас есть тысячи строк. Во время обработки таблицы изменений таблица будет заблокирована даже для выборок, и это может привести к некоторым тайм-аутам запроса в зависимости от размера ваших данных.
Доступные вам параметры во многом зависят от того, какой механизм базы данных вы используете. Вы захотите начать с выполнения любых действий, необходимых для включения резервного копирования вашей базы данных в режиме онлайн, предпочтительно с разрешения операций записи во время выполнения резервного копирования. Обычно для этого требуется линейное ведение журнала транзакций, что также должно дать вам возможность восстановить базу данных до определенного момента времени путем повторения транзакций по журналам транзакций.
Реорганизация таблиц и индексов может быть немного сложнее, но, надеюсь, ваш механизм базы данных позволяет по крайней мере доступ только для чтения к объектам во время их реорганизации. В противном случае вам может потребоваться найти способ для ваших приложений временно использовать клон таблицы, доступный только для чтения. Если ваша СУБД мало предлагает возможности онлайн-обслуживания, вам придется пойти на компромисс на уровне приложения, чтобы перенаправить его на частичную или полную копию данных.
Независимо от стоимости, репликация базы данных почти всегда является сложной функцией для управления. Еще хуже двунаправленная репликация, которая теоретически позволит вашим приложениям изменять данные во вторичной базе данных, даже когда первичная база данных не работает на обслуживание. Репликация возможна, но требует изрядного объема планирования и тестирования, чтобы обеспечить надежную работу в производственной среде.