Простая репликация SQL Server 2005 - сервер "D-1" используется для тяжелых запросов / отчетов
У нас есть две машины SQL 2005. Один используется для производственных данных, а другой - для выполнения запросов / отчетов. Каждую ночь рабочая машина сбрасывает (создает резервные копии) свою базу данных на диск, а другая восстанавливает ее. Это называется процессом D-1.
Я думаю, что должен быть более эффективный способ сделать это, так как SQL 2005 имеет много форм репликации. Некоторые требования:
1) Нет необходимости в мгновенной репликации, возможна (некоторая) задержка
2) Все изменения (включая схемы, данные, ограничения, индексы) необходимо реплицировать без ручного вмешательства.
3) Используется только для одной базы данных.
4) При необходимости доступен третий сервер
5) Между серверами имеется высокая пропускная способность (гигабитный Ethernet).
6) Нет общего хранилища (SAN) доступно
Что может быть хорошей альтернативой этой ежедневной процедуре резервного копирования / восстановления? Спасибо!
1 ответ
Лучшая альтернатива - доставка бревен. Доставка журналов также основана на резервном копировании / восстановлении, но после первоначального заполнения полной резервной копии базы данных сайт отчетов поддерживается путем применения резервных копий журналов с основного сайта. Доставка журналов хороша потому что:
- не влияет на основной сайт
- имеет поддержку в наборе инструментов управления SQL для развертывания, мониторинга и администрирования
- Переданные данные минимальны, только резервная копия журнала базы данных, которая содержит только изменения, произошедшие с момента последней отправки.
- задержка данных относительно невелика: интервал между журналами + время на копирование файла журнала и его восстановление.
Недостатки в том, что сайт отчетов нарушается при каждом восстановлении журнала, все пользователи выгружаются во время восстановления.
Таким образом, если у вас типичный 30-минутный интервал резервного копирования журнала, то на сайте отчетов всегда до 30 + X минут (X - время, необходимое для копирования файла и его восстановления, обычно довольно маленькое), и пользователи отключаются каждые 30 минут для короткое время.
Другой альтернативой является зеркальное отображение базы данных. С помощью DBM сайт отчетов постоянно обновляется, но недостатком является то, что зеркальная база данных находится в автономном режиме. Отчеты должны запускаться из снимка базы данных, который периодически обновляется. В отличие от доставки журналов, DBM также влияет на основной сайт. Большим преимуществом решения DBM для удаленных отчетов является то, что после развертывания оно может служить также решением для обеспечения высокой доступности / восстановления после сбоев.
Некоторые тоже используют транзакционную репликацию, но я не большой поклонник этой технологии. Хотя он достаточно прост в развертывании, он медленный при высокой нагрузке и имеет тенденцию сталкиваться с проблемами, которые довольно сложно диагностировать и устранять. Кроме того, репликация не копирует точно базу данных, а вместо этого сохраняет копии опубликованных статей в базе данных распространителя (т. Е. Выбранные таблицы и индексы), а изменения схемы требуют тщательного планирования и развертывания. С доставкой журналов и зеркальным отображением изменений базы данных просто реплицируйтесь без каких-либо проблем.