SQLSERVER mirroring VS Log shipping

Question

Мне нужна помощь в понимании зеркального отображения для последующего примера.

первичный сервер в FL сервере Зеркало в германии

Мое приложение делает вставку в таблицу для системы FL

ПРИМЕР 1: Сервер зеркало вниз - выпуск сети - I предположим, что вставка будет записана в журнал транзакций по основному - он не будет записан на диск Что произойдет, если кто-то попытается запросить базу данных FL.Когда они видят последнюю транзакцию [insert]? Когда SQL-сервер выполняет запрос, он смотрит как на БД, так и на tlog ?.

CASE 2: Если зеркальный сервер отключен на 2 дня. Тогда я предполагаю, что журнал трансакций будет продолжать расти. Можете ли вы объяснить, как это повлияет на время отклика приложения

CASE 3: Если зеркало не работает пока (неделя). Лучше ли нарушить зеркалирование. Кроме того, будет это означает, что у меня есть взять полную резервную копию БД снова, чтобы перенастроить зеркального

Answer 1

Вы не указали, какой зеркалирования, так что я буду считать, high safety with automatic failover

Случай 1: Принципал будет находиться в состоянии «отключен». Транзакции будут привязаны к диску на главном, но не в зеркале (очевидно). Транзакции останутся в «активной» части журнала и не будут скопированы. т. е. вы увидите, что ваш журнал транзакций будет расти, а столбец log_reuse_wait_desc в sys.databases будет MIRRORING. База данных FL останется в автономном режиме и находится в отключенном состоянии. Вы не сможете запросить его, если вы не используете что-то вроде FORCE_SERVICE_ALLOW_DATA_LOSS, чтобы принести его в Интернете в какой момент вы сломали зеркало (хотя поручитель не знает еще & будет продолжать проводить журналы)

СЛУЧАЙ 2: Журнал транзакций будет продолжать расти в соответствии с вашими настройками автозагрузки. Это обычный случай с журналами автозагрузки, у вас будут некоторые накладные расходы каждый раз, когда вы получаете автостраду и, возможно, получаете множество виртуальных файлов журналов. Наверное, лучше всего настроить автошоу на что-то разумное, чтобы оно не увеличивалось с шагом в 50 МБ.

CASE 3: Это зависит от того, сколько изменений данных вы изменили по сравнению с размером полной резервной копии базы данных, которые необходимо скопировать между сайтами для повторного инициализации зеркалирования. В SQL Server 2008 у вас есть такие параметры, как сжатие журналов, что означает, что вы можете наложить больше транзакций на провод с меньшей пропускной способностью (если вы его используете)