Мы планируем сервер, который представляет собой кластерный 64-битный SQL2005 Enterprise с базой данных, подмножество таблиц которого реплицируется в одну сторону посредством репликации транзакций на одного подписчика, расположенного в другом центре обработки данных, для целей отчетности. Дистрибьютор находится вместе с издателем в кластере. SAN используется для хранения.
Помимо кластеризации, клиенту требуется устойчивость базы данных издателя в случае сбоя SAN. У них есть второй меньший SAN (с точки зрения производительности), доступный (к сожалению, с точки зрения аварийного восстановления) в том же центре обработки данных. Это будет один 32-битный сервер с подключенным 32-битным SQL2005 Enterprise. Клиенты знают, что в случае инцидента SAN у них больше не будет кластеризации или репликации и меньшего уровня производительности.
Я обсуждаю, использовать ли доставку журналов или зеркальное отображение базы данных для аварийного восстановления базы данных. Мы используем Quest LiteSpeed для резервного копирования и можем использовать его для доставки сжатых резервных копий журнала транзакций.
Имеет ли какая-либо из двух технологий (зеркальное отображение или доставка журналов) меньшее влияние на базу данных издателя с точки зрения производительности и задержки репликации?
Это зависит. ха-ха.
Вам также нужно подумать о том, какие требования к потере данных заказчик ставит перед издателем, и делаете ли вы уже резервные копии журналов (я предполагаю, что да).
Зеркальное отображение базы данных может быть настроено на нулевую потерю данных (пока зеркало остается синхронизированным), но в зависимости от скорости создания журнала транзакций и доступной пропускной способности сети, ожидание, пока записи журнала будут усилены на зеркале, прежде чем транзакции смогут фиксация принципала может замедлить рабочую нагрузку. Зависит от того, какие транзакции вы выполняете (длинные или короткие), окажет ли это заметное влияние на общее время отклика.
При доставке журналов это просто резервное копирование-восстановление, повторить. Так что, если вы уже делаете резервные копии журналов, вы вообще не повлияете на производительность. Если вы не привыкли делать резервные копии журналов, у вас могут возникнуть проблемы с управлением размером журнала транзакций.
Имейте в виду, что зеркальное отображение требует ПОЛНОЙ модели восстановления, поэтому это может повлиять на обслуживание вашей базы данных, особенно если вы привыкли использовать модель восстановления BULK_LOGGED. В зависимости от доступной пропускной способности сети это также может привести к проблемам с управлением размером журнала.
Оба требуют пропускной способности сети, но по-разному. Доставка журналов - это всплеск каждый раз, когда копируется резервная копия журнала, зеркальное отображение базы данных становится более устойчивым, очевидно, снова в зависимости от скорости создания журнала. Мне не нужно было знать намного больше, чтобы определить, повлияет ли дополнительная пропускная способность, необходимая для любого из них, на перемещение данных в потоке репликации и, следовательно, на задержку.
При использовании доставки журналов вам придется вручную переключаться на вторичную службу доставки журналов в случае сбоя, и существует возможность потери данных (все данные с момента последней резервной копии журнала, скопированные с первичной). И тогда вам нужно будет снова запустить ответ.
При зеркальном отображении базы данных вы можете настроить автоматическое переключение при отказе, и вы можете специально настроить партнера по отработке отказа в заданиях агента repl для автоматического запуска на новом участнике (который также является новым издателем). Уловка состоит в том, чтобы убедиться, что аварийное переключение зеркального отображения базы данных не произойдет до того, как произойдет аварийное переключение локального кластера. Это можно сделать, изменив значение тайм-аута партнера по зеркалированию. Я писал об этом в блоге http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-3-Database-mirroring-failover-types-and-partner-timeouts.aspx.
Я написал технический документ для Microsoft, в котором описывается, как использовать зеркальное отображение и транзакционную репликацию вместе: см. http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server2008-New-whitepaper-on-combining-transactional-replication-and-database-mirroring.aspx.
При прочих равных условиях я бы порекомендовал зеркальное отображение базы данных из-за простоты управления с возможностью уменьшения потерь данных. У вас могут быть некоторые другие требования, о которых я не знаю, которые могли бы предотвратить это.
Надеюсь это поможет.