Вы когда-нибудь сталкивались с ситуацией, когда ваш план журнальной доставки был прерван? Если да, то вы, возможно, столкнулись с проблемой восстановления нарушенного плана журнальной доставки. В таких случаях рекомендуется полностью повторно инициализировать журнальную доставку из полных и журнальных резервных копий. Однако есть альтернативный подход, который включает использование дифференциальной резервной копии с первичной базы данных для возобновления плана журнальной доставки. В этой статье мы рассмотрим, почему этот подход работает и как он может минимизировать усилия и время простоя.
Представьте себе такой сценарий: младший администратор баз данных случайно создал резервную копию журнала вне плана журнальной доставки, и эта резервная копия не была восстановлена на вторичной базе данных. Вместо этого она была удалена с ее дискового местоположения и потеряна. Внезапно ваш пейджер начинает пищать, и ваш начальник хочет знать, почему на вторичную отчетную базу данных не отправляются новые данные. Мысль о полной повторной инициализации всего плана журнальной доставки, особенно для большой базы данных, пугает. Но потом вы вспоминаете, что читали о возможности использования дифференциальной резервной копии для заполнения разрыва в LSN (Log Sequence Number). И вы правы! Вот почему это работает.
Ключ к пониманию того, почему дифференциальное восстановление работает, заключается в трех заданиях агента SQL Server плана журнальной доставки, которые создают резервные копии, копируют и восстанавливают резервные копии журнала транзакций. Эти задания постоянно реплицируют данные с первичной на вторичную базу данных. Внутри этого процесса репликации находится дифференциальный базовый LSN (Log Sequence Number), который увеличивается в соответствии с первичной базой данных.
Давайте рассмотрим шаги, вовлеченные в типичный процесс журнальной доставки и созданные дифференциальные базовые LSN:
| № шага | Название шага | Дифференциальный базовый LSN первичной базы данных | Дифференциальный базовый LSN вторичной базы данных |
|---|---|---|---|
| 1 | Реализована журнальная доставка | 62000000061100036 | 62000000061100036 |
| 2 | Запущена первая резервная копия журнала, скопирована и восстановлена | 62000000061100036 | 62000000061100036 |
| 3 | Последующие резервные копии журнала скопированы и восстановлены | 62000000061100036 | 62000000061100036 |
| 4 | Полная резервная копия выполняется на первичной базе данных | 62000000064400043 | 62000000061100036 |
| 5 | Выполняется резервная копия журнала, копируется и восстанавливается | 62000000064400043 | 62000000064400043 |
Пока резервные копии журнала восстанавливаются на вторичной базе данных, дифференциальный базовый LSN остается в синхронизации, что позволяет вам заполнить разрывы LSN между первичной и вторичной базами данных с помощью дифференциальной резервной копии.
Учитывая типичную конфигурацию резервного копирования на вашей базе данных, которая использует журнальную доставку, у вас может быть следующее:
- Полная резервная копия: каждое воскресенье в 20:00
- Дифференциальная резервная копия: каждую ночь с понедельника по субботу в 20:00
- Резервная копия журнала транзакций: через план журнальной доставки каждые 15 минут в течение дня
В указанном выше сценарии регулярное восстановление журнала будет поддерживать вторичную базу данных в синхронизации с первичной. Однако любое нарушение плана журнальной доставки может быть исправлено путем восстановления дифференциальной резервной копии. Существует одно предостережение: если полная резервная копия выполняется после нарушения журнальной доставки, но перед тем, как вы сделаете дифференциальную резервную копию, дальнейшее восстановление журналов не выполняется, и дифференциальные базовые LSN больше не синхронизированы. В таких случаях вам потребуется повторно инициализировать журнальную доставку.
Поэтому важно иметь подходящий мониторинг и уведомления, чтобы немедленно предупреждать вас о нарушении плана журнальной доставки. С правильным мониторингом администраторы баз данных поддержки производства могут быстро реагировать на предупреждение и немедленно восстановить работу. Также важно обучить команду процессу, который будет использоваться. Как всегда, тщательно протестируйте процесс в своей песочнице или тестовой среде, прежде чем внедрять его в производство.
Понимая концепцию использования дифференциальной резервной копии