Поделиться через


Стратегии резервного копирования и восстановления из копии репликации моментальных снимков и репликации транзакций

При разработке стратегии резервного копирования и восстановления для репликации моментальных снимков и репликации транзакций необходимо учитывать три аспекта.

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

  • Настройки резервного копирования для репликации транзакций.

  • Шаги, необходимые для восстановления базы данных. Они зависят от типа репликации и выбранных параметров.

Эта тема охватывает данные группы вопросов в следующих трех разделах. Сведения о резервном копировании и восстановлении для публикации Oracle см. в статье Резервное копирование и восстановление для издателей Oracle.

Резервное копирование баз данных

Для репликации моментальных снимков и репликации транзакций необходимо регулярно выполнять резервное копирование следующих баз данных:

  • База данных публикации на издателе.

  • База данных распространителя на распространителе.

  • База данных подписки на подписчике.

  • Системные базы данных master и msdb на издателе, распространителе и на всех подписчиках. Резервные копии этих баз данных и копия соответствующей базы данных репликации должны быть сделаны одновременно. Например, создайте резервную копию баз данных master и msdb на издателе одновременно с резервной копией базы данных публикации. Если база данных публикации восстановлена, убедитесь, что базы данных master и msdb согласованы с базой данных публикации по параметрам и конфигурации репликации.

Если резервное копирование журналов выполняется регулярно, любые изменения, касающиеся репликации, будут заноситься в резервные копии журнала. Если не выполняется резервное копирование журналов, то необходимо выполнить это резервное копирование при каждом изменении настройки, относящейся к репликации. Дополнительные сведения см. в статье Common Actions Requiring an Updated Backup.

Настройки резервного копирования для репликации транзакций

Репликация транзакций включает параметр sync with backup , который может быть установлен для базы данных распространителя и для базы данных публикации.

  • Рекомендуется устанавливать этот параметр в базе данных распространителя.

    Установка этого параметра для базы данных распространителя гарантирует, что транзакции в журнале базы данных публикации не будут усечены до тех пор, пока не будет создана их резервная копия в базе данных распространителя. Базу данных распространителя можно восстановить до последней резервной копии, а все потерянные транзакции будут доставлены из базы данных публикации в базу данных распространителя. Репликация не затрагивается.

    Установка этого параметра для базы данных распространителя не влияет на задержку репликации. Тем не менее этот параметр откладывает усечение журнала в базе данных публикации до того момента, пока не завершится резервное копирование соответствующих транзакций в базе данных распространителя. (Это может привести к увеличению размера журнала транзакций в базе данных публикации.)

  • Рекомендуется установить этот параметр для базы данных публикации, если приложение допускает дополнительную задержку.

    Установка этого параметра для базы данных публикации гарантирует, что транзакции не будут доставлены в базу данных распространителя до тех пор, пока не будет создана их резервная копия в базе данных публикации. Последняя резервная копия базы данных публикации может быть затем восстановлена на издателе, при этом в базе данных распространителя не будет транзакций, которых нет в восстановленной базе данных публикации.

    Задержка и пропускная способность изменяются, так как транзакции не могут быть доставлены в базу данных распространителя до тех пор, пока не будут созданы их резервные копии на издателе. Например, если резервная копия журнала транзакций создается каждые пять минут, потребуются дополнительные пять минут задержки между фиксацией транзакции на издателе и доставкой транзакции сначала в базу данных распространителя, а затем подписчику.

    Примечание

    Параметр sync with backup обеспечивает согласованность базы данных публикации и базы данных распространителя, но он не гарантирует отсутствия потерь данных. Например, если журнал транзакций потерян, транзакции, зафиксированные после последнего резервного копирования журнала транзакций, не будут доступны в базе данных публикации или базе данных распространителя. Точно так же ведет себя нереплицируемая база данных.

Установка параметра «sync with backup»

Восстановление баз данных, участвующих в репликации

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

Служба репликации поддерживает восстановление реплицированной базы данных на том же сервере и в той же базе данных, где была создана ее резервная копия. Если восстановить резервную копию реплицированной базы данных на другом сервере или в другой базе данных, то станет невозможным сохранение настроек репликации. В этом случае после восстановления из резервной копии потребуется повторно создать все публикации и подписки.

Издатель

Последовательность шагов по восстановлению предлагается для следующих типов репликации:

  • репликация моментальных снимков;

  • репликация транзакций, доступная только для чтения;

  • репликация транзакций с обновляемыми подписками;

  • одноранговая репликация транзакций.

Восстановление баз данных msdb и master , о котором также рассказывается в этом разделе, одинаково для всех четырех типов репликации.

База данных публикации: Репликация моментальных снимков

  1. Восстановите последнюю резервную копию базы данных публикации. Перейдите к шагу 2.

  2. Содержит ли резервная копия базы данных публикации последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. Восстановление завершено.

    Дополнительные сведения об удалении репликации см. в разделе sp_removedbreplication (Transact-SQL).

База данных публикации: репликация транзакций, доступная только для чтения

  1. Восстановите последнюю резервную копию базы данных публикации. Перейдите к шагу 2.

  2. Был ли перед сбоем включен параметр sync with backup для базы данных публикации? Если да, перейдите к шагу 3, если нет — к шагу 5.

    Если параметр включен, запрос SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup') возвращает '1'.

  3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 4.

  4. Сведения о конфигурации восстановленной базы данных публикации устарели. Необходимо убедиться, что у подписчиков имеются все команды, ожидающие выполнения в базе данных распространителя, а затем удалить и повторно создать конфигурацию репликации.

    1. Запускайте агент распространителя до полной синхронизации подписчиков с ожидающими выполнения командами в базе данных распространителя. Убедитесь в том, что все команды доставлены подписчикам. Для этого используйте вкладку Нераспространенные команды в мониторе репликации либо запросите представление MSdistribution_status в базе данных распространителя. Перейдите к шагу b.

      Дополнительные сведения о запуске агент распространения см. в разделах Запуск и остановка агента репликации (SQL Server Management Studio) и Основные понятия исполняемых файлов агента репликации.

      Дополнительные сведения о проверке команд см. в разделах Просмотр реплицированных команд и других сведений в базе данных распространителя (программирование репликации на языке Transact-SQL) и Просмотр сведений и выполнение задач с помощью монитора репликации.

    2. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

      Дополнительные сведения об удалении репликации см. в разделе sp_removedbreplication (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

  5. Параметр sync with backup не установлен в базе данных публикации. Следовательно, транзакции, не включенные в восстановленную резервную копию, могли быть переданы распространителю и подписчикам. Необходимо убедиться, что в базе данных распространителя у подписчиков есть все команды, ожидающие обработки, затем вручную применить к базе данных публикации все транзакции, отсутствующие в восстановленной резервной копии.

    Важно!

    В результате этих действий опубликованные таблицы могут быть восстановлены до более современных версий, чем версии неопубликованных таблиц, восстановленных из резервной копии.

    1. Запускайте агент распространителя до полной синхронизации подписчиков с ожидающими выполнения командами в базе данных распространителя. Убедитесь в том, что все команды доставлены подписчикам. Для этого используйте вкладку Нераспространенные команды в мониторе репликации либо запросите представление MSdistribution_status в базе данных распространителя. Перейдите к шагу b.

      Дополнительные сведения о запуске агент распространения см. в разделах Запуск и остановка агента репликации (SQL Server Management Studio) и Основные понятия исполняемых файлов агента репликации.

      Дополнительные сведения о проверке команд см. в разделах Просмотр реплицированных команд и других сведений в базе данных распространителя (программирование репликации на языке Transact-SQL) и Просмотр сведений и выполнение задач с помощью монитора репликации.

    2. Для ручной синхронизации издателя с подписчиками используется программа tablediff или другое средство. Это позволяет восстанавливать данные из базы данных подписчика, которая не содержалась в резервной копии базы данных публикации. Перейдите к шагу c.

      Дополнительные сведения о программе tablediff см. в статье Сравнение реплицированных таблиц для различий (программирование репликации).

    3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, синхронизируйте повторно метаданные издателя и распространителя с помощью хранимой процедуры sp_replrestart . Восстановление завершено. Если нет, перейдите к шагу d.

    4. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

      Дополнительные сведения об удалении репликации см. в разделе sp_removedbreplication (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

База данных публикации: репликация транзакций с обновляемыми подписками

  1. Восстановите последнюю резервную копию базы данных публикации. Перейдите к шагу 2.

  2. Запускайте агент распространителя до полной синхронизации подписчиков с ожидающими выполнения командами в базе данных распространителя. Убедитесь в том, что все команды доставлены подписчикам. Для этого используйте вкладку Нераспространенные команды в мониторе репликации либо запросите представление MSdistribution_status в базе данных распространителя. Перейдите к шагу 3.

    Дополнительные сведения о запуске агент распространения см. в разделах Запуск и остановка агента репликации (SQL Server Management Studio) и Основные понятия исполняемых файлов агента репликации.

    Дополнительные сведения о проверке команд см. в разделах Просмотр реплицированных команд и других сведений в базе данных распространителя (программирование репликации на языке Transact-SQL) и Просмотр сведений и выполнение задач с помощью монитора репликации.

  3. Если вы используете обновляемые в очереди подписки, подключитесь к каждому подписчику и удалите все строки из таблицы MSreplication_queue (Transact-SQL) в базе данных подписки. Перейдите к шагу 4.

    Примечание

    Если используются обновляемые посредством очередей подписки и какие-либо таблицы содержат столбцы идентификаторов, следует убедиться, что после восстановления назначены правильные диапазоны идентификаторов. Дополнительные сведения см. в статье Репликация столбцов идентификаторов.

  4. Необходимо убедиться, что в базе данных распространителя у подписчиков есть все команды, ожидающие обработки, затем вручную применить к базе данных публикации все транзакции, отсутствующие в восстановленной резервной копии.

    Важно!

    В результате этих действий опубликованные таблицы могут быть восстановлены до более современных версий, чем версии неопубликованных таблиц, восстановленных из резервной копии.

    1. Запускайте агент распространителя до полной синхронизации подписчиков с ожидающими выполнения командами в базе данных распространителя. Используя монитор репликации или запросив представление MSdistribution_status в базе данных распространителя, убедитесь, что все команды доставлены подписчикам. Перейдите к шагу b.

    2. Для ручной синхронизации издателя с подписчиками используется tablediff Utility или другое средство. Это позволяет восстанавливать данные из базы данных подписчика, которая не содержалась в резервной копии базы данных публикации. Перейдите к шагу c.

      Дополнительные сведения о программе tablediff см. в разделе Сравнение реплицированных таблиц для различий (программирование репликации).

    3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, синхронизируйте повторно метаданные издателя и распространителя с помощью хранимой процедуры sp_replrestart . Восстановление завершено. Если нет, перейдите к шагу d.

    4. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

      Дополнительные сведения об удалении репликации см. в разделе и sp_removedbreplication (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

База данных публикации: Peer-to-Peer Transactional Replication

В следующих шагах базы данных публикаций A, Bи C находятся в топологии одноранговой репликации транзакций. Базы данных A и C находятся в режиме «в сети» и функционируют правильно; база данных B — восстанавливаемая база данных. Описанные здесь действия, особенно шаги 7, 10 и 11, очень похожи на процесс добавления узла к одноранговой топологии. Самый простой путь выполнения этих шагов — использование мастера настройки одноранговой топологии, однако можно использовать и хранимые процедуры.

  1. Запустите агент распространителя для синхронизации подписок в базах данных A и C. Перейдите к шагу 2.

    Дополнительные сведения о запуске агент распространения см. в разделах Запуск и остановка агента репликации (SQL Server Management Studio) и Основные понятия исполняемых файлов агента репликации.

  2. Если база данных распространителя, которую использует база данных B, все еще доступна, запустите агенты распространителя для синхронизации подписок между базами данных B и A, а также между базами данных B и C. Перейдите к шагу 3.

  3. Удалите метаданные из базы данных распространителя, которую использует база данных B, выполнив хранимую процедуру sp_removedistpublisherdbreplication в базе данных распространителя для базы данных B. Перейдите к шагу 4.

  4. В базах данных A и C удалите подписки на публикации из базы данных B. Перейдите к шагу 5.

    Дополнительные сведения об удалении подписок см. в разделе Subscribe to Publications.

  5. Выполните резервное копирование журналов или полное резервное копирование базы данных A. Перейдите к шагу 6.

  6. Восстановите резервную копию базы данных A в базе данных B. Теперь в базе данных B имеются данные из базы данных A, но отсутствует конфигурация репликации. При восстановлении резервной копии на другом сервере репликация удаляется, поэтому репликация была удалена из базы данных B. Перейдите к шагу 7.

  7. Вновь создайте публикацию в базе данных B и подписки между базами данных A и B. (Подписки, затрагивающие базу данных C, будут обработаны позже.)

    1. Заново создайте публикацию в базе данных B. Перейдите к шагу b.

    2. Создайте заново подписку в базе данных B на публикацию в базе данных A, указав, что подписка должна быть инициализирована с резервной копией (значение initialize with backup для параметра @sync_type хранимой процедуры sp_addsubscription). Перейдите к шагу c.

    3. Создайте заново подписку в базе данных A на публикацию в базе данных B, указав, что подписчик уже содержит данные (значение replication support only для параметра @sync_type хранимой процедуры sp_addsubscription). Перейдите к шагу 8.

  8. Запустите агент распространителя для синхронизации подписок в базах данных A и B. Если в публикуемых таблицах имеются столбцы идентификаторов, перейдите к шагу 9. Если нет, перейдите к шагу 10.

  9. После восстановления диапазон идентификаторов, присвоенный каждой таблице в базе данных A, будет также использоваться в базе данных B. Убедитесь, что восстановленная база данных B получила все изменения из поврежденной базы данных B, которые были переданы в базы данных A и C, затем обновите начальные значения диапазона идентификаторов для каждой таблицы.

    1. Выполните процедуру sp_requestpeerresponse в базе данных B и получите выходной параметр @request_id. Перейдите к шагу b.

    2. По умолчанию агент распространителя работает непрерывно, поэтому токены отправляются на все узлы автоматически. Если агент распространителя не выполняется в непрерывном режиме, запустите его. Дополнительные сведения см. в разделах Основные понятия исполняемых файлов агента репликации или Запуск и остановка агента репликации (SQL Server Management Studio). Перейдите к шагу c.

    3. Выполните хранимую процедуру sp_helppeerresponses, указав значение @request_id , полученное на шаге b. Подождите, пока все узлы сообщат о получении однорангового запроса. Перейдите к шагу d.

    4. Выполните инструкцию DBCC CHECKIDENT для обновления начальных значений каждой таблицы в базе данных B , чтобы убедиться, что используется соответствующий диапазон. Перейдите к шагу 10.

    Дополнительные сведения об управлении диапазонами идентификаторов см. в подразделе "Назначение диапазонов для ручного управления диапазонами идентификаторов" статьи Репликация столбцов идентификаторов.

  10. На этом этапе база данных B и база данных C не подключены напрямую, но они будут получать изменения через базу данных A. Если топология содержит узлы, работающие SQL Server 2005, перейдите к шагу 11; в противном случае перейдите к шагу 12.

  11. Приостановите систему и заново создайте подписки между базами данных B и C. Приостановка системы подразумевает остановку действий в опубликованных таблицах на всех узлах и проверку получения изменений на каждом узле.

    1. Остановите все действия в опубликованных таблицах в одноранговой топологии. Перейдите к шагу b.

    2. Выполните процедуру sp_requestpeerresponse в базе данных B и получите выходной параметр @request_id. Перейдите к шагу c.

    3. По умолчанию агент распространителя работает непрерывно, поэтому токены отправляются на все узлы автоматически. Если агент распространителя не выполняется в непрерывном режиме, запустите его. Перейдите к шагу d.

    4. Выполните хранимую процедуру sp_helppeerresponses, указав значение @request_id , полученное на шаге b. Подождите, пока все узлы сообщат о получении однорангового запроса. Перейдите к шагу e.

    5. Создайте заново подписку в базе данных B на публикацию в базе данных C, указав, что подписчик уже содержит данные. Перейдите к шагу b.

    6. Создайте заново подписку в базе данных C на публикацию в базе данных B, указав, что подписчик уже содержит данные. Перейдите к шагу 13.

  12. Создайте заново подписку между базами данных B и C.

    1. В базе данных Bвыполните запрос к таблице MSpeer_lsns , чтобы получить номер LSN последней транзакции, которая была передана в базу данных B из базы данных C.

    2. Создайте заново подписку в базе данных B на публикацию в базе данных C, указав, что подписка должна быть инициализирована на основе номера LSN (значение initialize from lsn для параметра @sync_type хранимой процедуры sp_addsubscription). Перейдите к шагу b.

    3. Создайте заново подписку в базе данных C на публикацию в базе данных B, указав, что подписчик уже содержит данные. Перейдите к шагу 13.

  13. Запустите агент распространителя для синхронизации подписок в базах данных B и C. Восстановление завершено.

База данных msdb (Издатель)

  1. Восстановите последнюю резервную копию базы данных msdb .

  2. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Создайте заново задание очистки подписки из скриптов репликации. Восстановление завершено.

База данных master (Издатель)

  1. Восстановите последнюю резервную копию базы данных master .

  2. Убедитесь, что база данных согласована с базой данных публикации по конфигурации и параметрам репликации.

Базы данных на распространителе

База данных распространителя

  1. Восстановите последнюю резервную копию базы данных распространителя.

  2. Был ли перед сбоем включен параметр sync with backup для базы данных распространителя? Если да, перейдите к шагу 3, если нет — к шагу 4.

    Если параметр включен, запрос SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup') возвращает '1'.

  3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 4.

  4. Либо сведения о конфигурации в восстановленной базе данных распространителя устарели, либо в базе данных распространителя не был установлен параметр sync with backup . (После восстановления в базе данных распространителя могут иметься потерянные транзакции, зафиксированные на издателе, но не переданные подписчикам.) Удалите и создайте заново репликацию, а затем выполните проверку.

    1. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Перейдите к шагу b.

      Дополнительные сведения об удалении репликации см. в разделе sp_removedbreplication (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

    2. Отметьте все публикации для проверки. Повторно инициализируйте все подписки, не прошедшие проверку. Восстановление завершено.

      Дополнительные сведения о проверке см. в разделе Validate Replicated Data. Дополнительные сведения о повторной инициализации см. в статье Повторная инициализация подписок.

База данных msdb (Распространитель)

  1. Восстановите последнюю резервную копию базы данных msdb .

  2. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Перейдите к шагу 4.

    Дополнительные сведения об удалении репликации см. в разделе sp_removedbreplication (Transact-SQL).

    Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

  4. Отметьте все публикации для проверки. Повторно инициализируйте все подписки, не прошедшие проверку. Восстановление завершено.

    Дополнительные сведения о проверке см. в разделе Validate Replicated Data. Дополнительные сведения о повторной инициализации см. в статье Повторная инициализация подписок.

База данных master (Распространитель)

  1. Восстановите последнюю резервную копию базы данных master .

  2. Убедитесь, что база данных согласована с базой данных публикации по конфигурации и параметрам репликации.

Базы данных на подписчике

База данных подписки

  1. Является ли последняя резервная копия базы данных подписки более поздней, чем значение параметра минимального срока хранения распространения в базе данных распространителя? (Этим определяется, имеются ли у распространителя все команды, необходимые для обновления подписчика.) Если да, перейдите к шагу 2. Если нет, выполните повторную инициализацию подписки. Восстановление завершено.

    Чтобы определить значение параметра срока хранения распространителя, выполните хранимую процедуру sp_helpdistributiondb и получите значение из столбца max_distretention (значение в часах).

    Дополнительные сведения о повторной инициализации подписки см. в разделе Reinitialize a Subscription.

  2. Восстановите последнюю резервную копию базы данных подписки. Перейдите к шагу 3.

  3. Если база данных подписки содержит только принудительные подписки, перейдите к шагу 4. Если база данных подписки содержит любые подписки по запросу, задайте указанные ниже вопросы. Являются ли сведения о подписке актуальными? Включает ли база данных все таблицы и параметры, которые были установлены на момент сбоя. Если да, перейдите к шагу 4. Если нет, выполните повторную инициализацию подписки. Восстановление завершено.

  4. Для синхронизации подписчика запустите агент распространителя. Восстановление завершено.

    Дополнительные сведения о запуске агент распространения см. в разделах Запуск и остановка агента репликации (SQL Server Management Studio) и Основные понятия исполняемых файлов агента репликации.

База данных msdb (Подписчик)

  1. Восстановите последнюю резервную копию базы данных msdb . Используются ли на этом подписчике подписки по запросу? Если нет, восстановление завершено. Если да, перейдите к шагу 2.

  2. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех подписок по запросу? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Удалите и создайте заново подписки по запросу. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

    Дополнительные сведения об удалении подписок см. в разделе Subscribe to Publications.

    Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

База данных master (Подписчик)

  1. Восстановите последнюю резервную копию базы данных master .

  2. Убедитесь, что база данных согласована с базой данных публикации по конфигурации и параметрам репликации.

См. также:

Резервное копирование и восстановление баз данных SQL Server
Создание резервных копий реплицируемых баз данных и восстановление из них
Настройка распространения
Публикация данных и объектов базы данных
Подписка на публикации
Инициализация подписки
Синхронизация данных