logo Фёдор Самородов

Как восстановить согласованную резервную копию нескольких баз данных

Для ‎администратора‏ ‎баз ‎данных ‎резервное ‎копирование ‎—‏ ‎вещь ‎обязательная.‏ ‎Не‏ ‎важно ‎какими ‎базами‏ ‎вы ‎управляете,‏ ‎большими ‎или ‎маленькими, ‎делать‏ ‎бэкапы‏ ‎необходимо. ‎Разработчики‏ ‎СУБД ‎это‏ ‎понимают ‎и ‎стараются ‎сделать ‎процедуру‏ ‎резервного‏ ‎копирования ‎максимально‏ ‎простой ‎и‏ ‎понятной ‎для ‎администратора. ‎Но ‎есть‏ ‎в‏ ‎резервном‏ ‎копировании ‎баз‏ ‎данных ‎один‏ ‎момент, ‎в‏ ‎котором‏ ‎СУБД ‎вам‏ ‎помочь ‎не ‎сможет…

Современные ‎приложения ‎всё‏ ‎чаще ‎проектируются‏ ‎так,‏ ‎чтобы ‎работать ‎с‏ ‎данными ‎не‏ ‎в ‎одной ‎базе ‎данных,‏ ‎а‏ ‎в ‎нескольких.‏ ‎Это ‎действительно‏ ‎полезно ‎— ‎таким ‎образом ‎можно‏ ‎повысить‏ ‎масштабируемость, ‎производительность,‏ ‎надёжность ‎и‏ ‎управляемость ‎приложения. ‎Но, ‎как ‎всегда‏ ‎бывает‏ ‎в‏ ‎инженерном ‎деле,‏ ‎это ‎не‏ ‎обходится ‎без‏ ‎сопутствующих‏ ‎недостатков. ‎Главный‏ ‎из ‎которых ‎— ‎усложнение ‎системы.‏ ‎Возможности ‎системы‏ ‎растут‏ ‎вместе ‎с ‎её‏ ‎сложностью, ‎что‏ ‎повышает ‎требования ‎к ‎обслуживанию‏ ‎многобазовых‏ ‎приложений. ‎Одна‏ ‎из ‎проблем,‏ ‎которую ‎придётся ‎решать ‎при ‎эксплуатации‏ ‎таких‏ ‎приложений ‎—‏ ‎создание ‎(и‏ ‎последующее ‎восстановление) ‎согласованных ‎резервных ‎копий‏ ‎нескольких‏ ‎баз‏ ‎данных.

Перед ‎вами‏ ‎аналог ‎приложения,‏ ‎работающего ‎с‏ ‎несколькими‏ ‎БД. ‎Оно‏ ‎постоянно ‎обрабатывает ‎данные ‎в ‎базах,‏ ‎согласовывая ‎изменения‏ ‎при‏ ‎помощи ‎транзакций.

Если ‎вы‏ ‎будете ‎восстанавливать‏ ‎из ‎резервных ‎копий ‎каждую‏ ‎из‏ ‎баз ‎независимо‏ ‎друг ‎от‏ ‎друга, ‎то ‎базы ‎восстановятся ‎в‏ ‎состояниях‏ ‎на ‎разные‏ ‎моменты ‎времени,‏ ‎что ‎означает ‎нарушение ‎целостности. ‎Каждая‏ ‎база‏ ‎данных‏ ‎вроде ‎бы‏ ‎восстановлена ‎и‏ ‎сама ‎по‏ ‎себе‏ ‎находится ‎в‏ ‎согласованном ‎состоянии, ‎но ‎приложению ‎необходимо,‏ ‎что ‎ещё‏ ‎и‏ ‎все ‎базы ‎были‏ ‎согласованы ‎между‏ ‎собой.

SQL ‎Server ‎позволяет ‎восстанавливать‏ ‎базу‏ ‎в ‎состоянии‏ ‎не ‎только‏ ‎на ‎момент ‎создания ‎резервной ‎копии,‏ ‎но‏ ‎и ‎на‏ ‎любой ‎произвольный‏ ‎момент ‎времени. ‎Чтобы ‎добиться ‎максимальной‏ ‎точности,‏ ‎следует‏ ‎восстанавливать ‎состояние‏ ‎базы ‎на‏ ‎момент ‎фиксации‏ ‎определённой‏ ‎транзакции, ‎а‏ ‎саму ‎транзакцию ‎провести ‎так, ‎чтобы‏ ‎она ‎внесла‏ ‎изменения‏ ‎сразу ‎во ‎все‏ ‎базы.

Можно, ‎к‏ ‎примеру, ‎создать ‎в ‎каждой‏ ‎базе‏ ‎табличку ‎и‏ ‎в ‎транзакции‏ ‎добавлять ‎в ‎неё ‎строку. ‎А‏ ‎чтобы‏ ‎эту ‎транзакцию‏ ‎при ‎восстановлении‏ ‎можно ‎было ‎отличить ‎от ‎остальных,‏ ‎снабдим‏ ‎её‏ ‎меткой.

Теперь, ‎когда‏ ‎эта ‎метка‏ ‎сохранена ‎в‏ ‎журнале‏ ‎транзакций, ‎можно‏ ‎создать ‎резервную ‎копию ‎журнала. ‎А‏ ‎при ‎восстановлении‏ ‎не‏ ‎забудьте ‎указать ‎параметр‏ ‎STOPATMARK ‎(или‏ ‎STOPBEFOREMARK), ‎чтобы ‎все ‎базы‏ ‎восстановились‏ ‎на ‎момент‏ ‎фиксации ‎нашей‏ ‎контрольной ‎транзакции.

Проверяем ‎базы ‎после ‎восстановления‏ ‎из‏ ‎резервной ‎копии:

Аналогично‏ ‎можно ‎восстанавливать‏ ‎согласованные ‎резервные ‎копии ‎баз ‎данных,‏ ‎работающих‏ ‎на‏ ‎разных ‎серверах.‏ ‎Только ‎не‏ ‎забудьте ‎при‏ ‎этом‏ ‎модифицировать ‎код‏ ‎контрольной ‎транзакции ‎так, ‎чтобы ‎транзакционная‏ ‎метка ‎распространялась‏ ‎на‏ ‎все ‎серверы.

Предыдущий Следующий
Все посты проекта
0 комментариев

Подарить подписку

Будет создан код, который позволит адресату получить бесплатный для него доступ на определённый уровень подписки.

Оплата за этого пользователя будет списываться с вашей карты вплоть до отмены подписки. Код может быть показан на экране или отправлен по почте вместе с инструкцией.

Будет создан код, который позволит адресату получить сумму на баланс.

Разово будет списана указанная сумма и зачислена на баланс пользователя, воспользовавшегося данным промокодом.

Добавить карту
0/2048