SQL Server Воспроизведение: Полное руководство для администраторов баз данных [2026]

SQL Server Репликация — это набор технологий для копирования и распространения данных и объектов базы данных из одной базы данных в другую, а затем синхронизации между базами данных для поддержания согласованности. Эта функция позволяет создавать и поддерживать несколько копий ваших данных на разных серверах и в разных местах, обеспечивая доступность и надежность данных.

1.2 Цель и преимущества воспроизведения

SQL Server Репликация удовлетворяет множество критически важных бизнес-задач и предоставляет значительные преимущества для управления базами данных и распространения данных:

Распределение данных по местоположениям: Репликация позволяет обмениваться данными между региональными офисами или локациями по всему миру, повышая операционную эффективность за счет обеспечения локального доступа к необходимым данным. Это снижает задержку в сети и обеспечивает более высокую производительность для географически распределенных пользователей.
Высокая доступность и восстановление после стихийных бедствий: Поддерживая реплики критически важных данных на нескольких серверах, репликация обеспечивает избыточность, защищающую от аппаратных сбоев и катастроф. В случае отказа основного сервера реплицированные копии могут служить резервными источниками, минимизируя время простоя и потерю данных.
Балансировка нагрузки и масштабируемость: Репликация распределяет операции чтения между несколькими серверами, предотвращая превращение какого-либо одного сервера в узкое место. Такой подход повышает производительность системы и позволяет масштабировать инфраструктуру горизонтально по мере роста объёма данных и потребностей пользователей.
Отчетность и аналитика в реальном времени: Перенос запросов на формирование отчетов и аналитику на реплицированные серверы снижает нагрузку на производственные базы данных. Пользователи могут выполнять сложные аналитические запросы к данным практически в режиме реального времени, не влияя на операционные системы, что обеспечивает как производительность, так и актуальность данных.
Интеграция и консолидация данных: Репликация облегчает объединение данных из различных источников в единое консолидированное представление. Это особенно ценно для организаций с множеством филиалов, которым необходимо агрегировать данные в головном офисе, или для создания централизованных хранилищ данных из распределенных операционных систем.

2. SQL Server Архитектура и компоненты репликации

SQL Server Архитектура репликации состоит из нескольких взаимосвязанных компонентов, которые работают вместе для распределения и синхронизации данных в рамках вашей инфраструктуры баз данных. В этом разделе рассматриваются основные компоненты, включая издателей, дистрибьюторов, подписчиков, публикации, статьи, подписки и агентов, которые координируют поток данных между ними:

Издатель: Издатель — это SQL Server например, что hostЭто одна или несколько баз данных, содержащих данные, подлежащие репликации. Она служит авторитетным источником в топологии репликации.
Дистрибьютор: Дистрибьютор — это SQL Server Экземпляр, управляющий потоком данных между издателями и подписчиками. Экземпляр дистрибьютора hostЭто база данных распространения, в которой хранятся метаданные репликации и транзакции.
Абонент: Подписчик — это SQL Server Экземпляр, который получает и хранит реплицированные данные от издателей. Один экземпляр подписчика может...ost несколько баз данных подписчиков, каждая из которых получает данные из разных изданий.
Публикация: В публикации определяется, какие данные будут воспроизводиться и как они будут распространяться среди подписчиков. В ней группируются связанные статьи и устанавливается методология воспроизведения, применимая ко всем содержащимся в ней объектам.
Статья: Статья — это основной строительный блок репликации, представляющий собой отдельный объект базы данных, который будет распространяться среди подписчиков.
Подписка: Подписка устанавливает взаимоотношения между изданием и подписчиком, определяя, как и когда данные доставляются в целевую базу данных.
Агенты: Агенты — это специализированные процессы, которые выполняют фактическую работу по перемещению и синхронизации данных между компонентами репликации.

3. Типы SQL Server копирование

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

3.1 Репликация моментальных снимков

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

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

Главные преимущества репликации моментальных снимков — простота, низкие требования к обслуживанию и возможность репликации данных без первичных ключей. Однако у неё есть существенные недостатки, включая значительное влияние блокировок таблиц при создании моментальных снимков, высокую задержку между обновлениями и неэффективность для больших наборов данных или часто изменяющихся данных. Любые изменения, внесённые у подписчиков, будут заблокированы.ost при применении следующего снимка.

3.2 Транзакционная репликация

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

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

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

3.3 Слияние репликаций

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

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

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

3.4 Репликация данных в одноранговых сетях

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

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

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

3.5 Двунаправленная репликация

Двунаправленная репликация — это специфическая топология транзакционной репликации, разработанная специально для двухсерверных сред, где оба сервера должны обмениваться изменениями друг с другом. Каждый сервер публикует данные и подписывается на те же данные от другого сервера, создавая простой двусторонний поток синхронизации. Хотя одноранговая репликация также может поддерживать два узла, двунаправленная репликация обеспечивает улучшенную производительность в этом конкретном сценарии.

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

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

3.6 Обновляемые подписки

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

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

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

3.7 Сравнение различных типов повторений

Тип репликации	Время обновления	Количество издателей	Руководство	Используйте сценарии
Снимок	Момент времени	1	One Direction (Издатель → Подписчики)	Редко изменяющиеся справочные данные (прайс-листы, обменные курсы)
Транзакционные	Почти в реальном времени	1	One Direction (Издатель → Подписчики)	Сценарии с высокой пропускной способностью (управление запасами в электронной коммерции, хранение данных, отчетность)
идти	Периодический (при подключении)	1	Двустороннее взаимодействие (Издатель ↔ Подписчики)	Мобильные приложения, работающие в офлайн-режиме сотрудники (автоматизация продаж, выездное обслуживание)
Peer-на-Peer	Почти в реальном времени	Несколько (3 или более)	Двунаправленный (все узлы)	Глобальные развертывания с использованием нескольких центров обработки данных (офисы по всему миру с локальным доступом для чтения и записи)
двунаправленная	Почти в реальном времени	2	Двунаправленное соединение (оба сервера)	Двухцентровые конфигурации активного режима (высокая доступность на двух площадках)
Подписки с возможностью обновления	Почти в реальном времени	1	В основном однонаправленное обновление (иногда обратное).	Филиалы, которые в основном читают, но иногда обновляют информацию (вносят локальные исправления).

4. Настройка SQL Server копирование

4.1 Предварительные условия и требования

4.1.1 Требования к программному обеспечению

SQL Server Для репликации требуется совместимость. SQL Server версии у всех участников топологии. Версия дистрибьютора должна быть равна или выше версии издателя, а версия подписчика может отличаться от версии издателя не более чем на два варианта. Например, SQL Server Издатель 2016 года может воспроизвести это. SQL Server Подписчики 2012, 2014, 2016, 2017 или 2019 года.

4.1.2 Требования к разрешению

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

4.2 Шаг 1: Настройка распространения

Настройка дистрибутива — это первый шаг в процессе настройки. SQL Server репликация.

Для настройки распространения с помощью SQL Server Студия управления:

Подключиться к SQL Server экземпляр в SQL Server Студия управления.
В обозревателе объектов щелкните правой кнопкой мыши по... копирование папку и выберите Настроить распространение.
В мастере настройки распространения нажмите Следующая на странице приветствия.
На Распределитель На этой странице выберите один из следующих вариантов в зависимости от требований к топологии:
- Местный дистрибьюторВыберите «ServerName будет выступать в качестве собственного дистрибьютора;» SQL Server Если вы хотите, чтобы издатель и распространитель работали на одном экземпляре (текущем экземпляре), будет создана база данных и журнал распространения. Эта конфигурация проще в настройке и подходит для небольших сред или в случаях, когда задержка сети между издателем и распространителем может вызвать проблемы.
- Удаленный дистрибьюторВыберите «Использовать следующий сервер в качестве распространителя» и нажмите Добавить Укажите удаленный сервер распространения, если хотите перенести обработку распространения на отдельный экземпляр. Такая конфигурация повышает производительность при больших объемах репликации, распределяя рабочую нагрузку между несколькими серверами. Вам потребуется указать имя удаленного сервера распространения и пароль, который издатель будет использовать для подключения к серверу распространения.
Нажмите Следующая Чтобы указать расположение папки для моментальных снимков, используйте UNC-путь (например, \\servername\share\folder), а не локальный путь, чтобы обеспечить доступность по всей сети.
На База данных дистрибутивов На странице примите имя базы данных дистрибутива по умолчанию (обычно «distribution») или укажите собственное имя, затем настройте расположение файлов данных и журналов.
На Издатели На этой странице убедитесь, что текущий сервер включен в качестве издателя. Если вы настроите текущий сервер в качестве распространителя, вы сможете добавить дополнительных издателей, которые будут использовать этого распространителя.
Просмотрите действия мастера и нажмите кнопку. Завершить для настройки распространения.

4.3 Шаг 2: Создание публикации

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

Для создания публикации с использованием SQL Server Студия управления:

В обозревателе объектов разверните копирование папку.
Щелкните правой кнопкой мыши Местные публикации и Новая публикация.
Новый мастер создания публикацийtarтс; клик Следующая на странице приветствия.
Выберите базу данных, которую хотите опубликовать, из списка. База данных публикаций Эта страница автоматически включает публикацию в выбранной базе данных.
На Тип публикации На странице выберите тип репликации: Публикация снимка, Транзакционная публикация, Одноранговая публикация или Объединить публикацию.
На Cтатьи страницу, разверните Столы Выберите узлы и таблицы для включения в качестве статей.
При желании можно расширить Хранимые процедуры, Видыили другие типы объектов для включения дополнительных статей.
Нажмите Свойства статьи для настройки фильтрации или других параметров, специфичных для каждой статьи.
На Фильтрация строк таблицы На странице добавьте фильтры по строкам при необходимости.
На Агент моментального снимка На странице выберите, когда создавать снимок: немедленно, в определенное время или по расписанию.
На Агент безопасности На этой странице укажите контекст безопасности для агента моментальных снимков.
На Действия мастера страницы, выберите Создать публикацию.
Укажите название публикации и нажмите Завершить.

4.4 Шаг 3: Создание подписки

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

Подписки могут быть как подписками с принудительной отправкой (управляемыми дистрибьютором), так и подписками с запросом (управляемыми подписчиком). Ключевые различия заключаются в месте создания подписки и в выборе местоположения агента, что определяет тип действия подписки (принудительная или запрос).

Для подписки на push-уведомления (Управляется дистрибьютором):

На издатель сервер, развернуть копирование -> Местные публикации.
Щелкните правой кнопкой мыши по публикации и выберите Новые подписки.

Для подписки Pull (Управляется Подписчиком):

На абонент сервер, развернуть копирование, щелкните правой кнопкой мыши Локальные подпискиИ выберите Новые подписки.
На Публикация страница, нажмите Найти SQL Server Издатель и подключиться к серверу издателя.

Общие шаги мастера для обоих типов подписки:

В мастере создания новой подписки нажмите Следующая на странице приветствия.
Выберите публикацию и нажмите Следующая.
На Местонахождение агента по дистрибуции На странице выберите местоположение агента:
- Push-подпискаВыберите «Запустить всех агентов у дистрибьютора» — дистрибьютор будет передавать изменения подписчикам.
- Подписка на PullВыберите «Запускать каждый агент на его подписчике» — каждый подписчик будет получать изменения от распространителя.
На Подписчики на странице выберите существующие серверы подписчиков или нажмите Добавить подписчик добавить новые.
Для каждого подписчика выберите целевую базу данных или создайте новую базу данных. Примечание: База данных подписчиков должна отличаться от базы данных издателя, даже если используются одни и те же данные. SQL Server пример.
На Безопасность агентов по дистрибуции На странице нажмите кнопку «Свойства» для каждой подписки, чтобы настроить контекст безопасности.
На Расписание синхронизации На странице выберите непрерывную синхронизацию или синхронизацию по расписанию.
На Инициализация подписок страницы, выберите Немедленно для инициализации во время завершения работы мастера или При первой синхронизации.
Просмотрите действия мастера и нажмите кнопку. Завершить.

5. Мониторинг и управление SQL Server копирование

5.1 Мониторинг репликации с помощью монитора репликации

Чтобы запустить Монитор репликации:

In SQL Server Студия управления, развернуть копирование в обозревателе объектов.
Щелкните правой кнопкой мыши копирование и Запустить монитор репликации.
Если ни один издатель не зарегистрирован, нажмите здесь. Добавить издателя в левой панели.
Выбирайте Добавить SQL Server Издатель и подключиться к серверу издателя.
В левой панели отображается информация об издателе, а также разворачиваемые элементы для отображения публикаций и подписок.

5.2 Мониторинг производительности

5.2.1 Задержка монитора

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

Для просмотра показателей задержки используйте Монитор репликации на вкладке «Все подписки». В столбце «Задержка» отображается средняя задержка в секундах. Для транзакционной репликации токены трассировки обеспечивают точные измерения задержки путем вставки транзакций-маркеров, которые отслеживаются на протяжении всего конвейера репликации.

Для использования токенов трассировки:

В мониторе репликации выберите транзакционную публикацию.
Нажмите Токены трассировки меню.
Нажмите Вставить трассировщик для внедрения транзакции-маркера.
Отслеживайте перемещение токена от издателя к дистрибьютору и далее к подписчику.
Просмотрите время, затраченное на каждый сегмент, чтобы выявить узкие места.

5.2.2 Пропускная способность монитора

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

Хотя Replication Monitor предоставляет базовую информацию о состоянии синхронизации, показатели скорости доставки и подробные метрики пропускной способности не отображаются в графическом интерфейсе пользователя. Для мониторинга пропускной способности используйте T-SQL запросы к базе данных распределения:

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

Коды состояния: 1 = Start, 2 = В процессе, 3 = Успешно, 4 = Бездействует, 5 = Повторная попытка, 6 = Сбой. Сравните скорость доставки с частотой транзакций издателя, чтобы выявить ситуации, когда репликация отстает. Счетчики производительности в Монитор производительности Windows предоставить дополнительные показатели пропускной способности для каждого агента репликации.

5.2.3 Выявление узких мест

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

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

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

5.3 Управление агентами репликации

5.3.1 Starагенты т и стоп-агентства

К starостановить или активировать агент репликации:

In SQL Server Студия управления, развернуть SQL Server Агент -> Вакансии.
Найдите задание агента репликации (в его названии обычно содержится информация о публикации и подписчике).
Щелкните правой кнопкой мыши по заданию и выберите StarТ Работа or Остановить работу.

5.3.2 Настройка профилей агентов

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

Для изменения профилей агентов:

В обозревателе объектов разверните копирование.
Щелкните правой кнопкой мыши копирование и Свойства дистрибьютора.
Нажмите Настройки профиля по умолчанию .
Выберите тип агента (Снимок, Считыватель журналов, Распространение или Слияние) из выпадающего списка.
Выберите профиль и нажмите Основные свойства для просмотра значений параметров.
Нажмите Новый профиль создать пользовательский профиль на основе существующего.
При необходимости измените параметры и нажмите кнопку. OK.

Для добавления профиля к агенту отредактируйте свойства подписки и выберите нужный профиль из раскрывающегося списка «Профиль агента».

5.3.3 Параметры и настройки агента

Параметры агента позволяют точно настроить производительность и поведение. Ключевые параметры для агента распространения включают CommitBatchSize (количество транзакций, применяемых за одно подтверждение), CommitBatchThreshold (количество команд до подтверждения), SubscriptionStreams (параллельные соединения для более быстрой доставки) и QueryTimeout (тайм-аут для команд).

Для агента чтения журналов важными параметрами являются ReadBatchSize (количество транзакций, прочитанных за одно сканирование), ReadBatchThreshold (количество команд до доставки) и PollingInterval (задержка между сканированиями журналов). Настройте эти параметры в зависимости от объема транзакций и требований к задержке.

5.4 Вопросы резервного копирования и восстановления

Резервное копирование баз данных, участвующих в репликации, требует особого подхода. Для базы данных издателя необходимы регулярные полные резервные копии и резервные копии журналов транзакций. При резервном копировании баз данных в транзакционной репликации пометьте резервную копию базы данных для поддержки репликации, используя параметр WITH REPLICATION. Регулярно создавайте резервные копии базы данных распределения, чтобы защитить конфигурацию репликации.

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

В сценариях аварийного восстановления, когда резервные копии недоступны, повреждены или файлы базы данных испорчены, могут потребоваться специализированные инструменты восстановления. DataNumen SQL Recovery может извлекать данные из поврежденных или недоступных файлов MDF и NDF, предоставляя возможность в крайнем случае, когда стандартные процедуры восстановления не срабатывают.

Для более подробной информации о SQL Server резервная копия, см. наш полное руководство.

6. Часто задаваемые вопросы (FAQ)

В: В чем разница между моментальной и транзакционной репликацией?

A: Репликация моментальных снимков создает полную копию данных в определенный момент времени и применяет ее к подписчику, что подходит для данных, изменяющихся нечасто. Транзакционная репликация...tarСистема создает первоначальный снимок, а затем непрерывно реплицирует отдельные транзакции по мере их возникновения, обеспечивая синхронизацию данных, часто изменяющихся, практически в реальном времени.

В: Могу ли я выполнить дублирование между различными устройствами? SQL Server версии?

A: Да, SQL Server Репликация поддерживает совместимость версий в ограниченном диапазоне. Версия дистрибьютора должна быть равна или выше версии издателя, а версия подписчика может отличаться от версии издателя не более чем на две версии. Например, если версия издателя — SQL Server В 2016 году подписчиком может быть SQL Server 2012, 2014, 2016, 2017 или 2019.

В: Как обрабатывать конфликты при репликации путем слияния?

A: Репликация слияния предоставляет встроенные механизмы обнаружения и разрешения конфликтов. Вы можете настроить механизмы разрешения конфликтов на уровне статьи, выбрав из встроенных или реализовав собственные механизмы. Конфликты обычно разрешаются с использованием методов, основанных на приоритете или временной метке, с возможностью регистрации конфликтов для ручного анализа.

В: Каково влияние воспроизведения результатов на производительность?

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

В: Как обеспечить безопасность топологии репликации?

A: Обеспечьте безопасность топологии репликации, внедрив несколько передовых методов: используйте аутентификацию Windows или надежную аутентификацию. SQL Server аутентификация, шифрование соединений с использованием TLS, защита папки со снимками с помощью соответствующих средств. NTFS настроить разрешения, сконфигурировать список доступа к публикациям (PAL) для управления доступом, использовать отдельные учетные записи служб с минимально необходимыми разрешениями для каждого агента репликации и регулярно проверять параметры безопасности репликации.

В: Можно ли выполнить репликацию в Azure SQL Database?

A: Да, вы можете реплицировать данные в Azure SQL Database, используя транзакционную репликацию с локальной инфраструктурой. SQL Server или Azure SQL Managed Instance в качестве издателя и распространителя. Azure SQL Database может выступать в качестве подписчика, но не в качестве издателя или распространителя. Репликация слиянием и одноранговая репликация не поддерживаются в Azure SQL Database.

В: Как отслеживать задержку репликации?

A: Отслеживайте задержку репликации с помощью монитора репликации в SQL Server В Management Studio отображаются метрики задержки для каждой подписки. Вы также можете запрашивать таблицы базы данных дистрибутивов, такие как MSdistribution_history и MSrepl_commands, использовать счетчики производительности, специфичные для агентов репликации, или настраивать оповещения на основе пороговых значений задержки для упреждающего обнаружения и устранения задержек синхронизации.

В: Что происходит, когда абонент находится вне сети?

A: Когда абонент находится в автономном режиме, поведение зависит от типа репликации. При транзакционной репликации транзакции накапливаются в базе данных распределения до тех пор, пока абонент не вернется в онлайн-режим, после чего синхронизация возобновляется. При репликации слияния изменения отслеживаются с обеих сторон и объединяются при восстановлении связи. Параметр «Период хранения» определяет, как долго данные хранятся до необходимости их повторной инициализации.

В: Как добавить новые статьи в уже существующую публикацию?

А: Чтобы добавить новые статьи в существующую публикацию, используйте SQL Server Для изменения свойств публикации и выбора дополнительных объектов используйте Management Studio или хранимую процедуру sp_addarticle. После добавления статей создайте новый снимок и повторно инициализируйте все подписки, чтобы гарантировать получение новых статей подписчиками. В зависимости от настроек публикации, некоторые изменения могут потребовать повторной инициализации подписки.

В: Как отключить репликацию в базе данных?

A: Чтобы удалить репликацию из базы данных, сначала удалите все подписки с помощью sp_dropsubscription, затем удалите публикацию с помощью sp_droppublication и, наконец, отключите публикацию в базе данных с помощью sp_replicationdboption. Если сервер является дистрибьютором, отключите распространение с помощью sp_dropdistributor. Всегда создавайте резервные копии баз данных перед удалением конфигурации репликации.

В: В чем разница между SQL Server Репликация и группы доступности AlwaysOn?

А: Репликация — это решение для распределения и интеграции данных, работающее на уровне объектов, в то время как Группы доступности Always On Это решение для обеспечения высокой доступности и аварийного восстановления, работающее на уровне базы данных.

7. Заключение

SQL Server Репликация обеспечивает надежную основу для распределения и синхронизации данных между несколькими базами данных и местоположениями. Технология поддерживает различные сценарии благодаря разным типам репликации.

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

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

Референсы

Об авторе

Юань Шэн старший администратор баз данных (DBA) с более чем 10-летним опытом работы в SQL Server сред и управления корпоративными базами данных. Он успешно реализовал сотни сценариев восстановления баз данных в финансовых, медицинских и производственных организациях.

Юань специализируется на SQL Server Восстановление баз данных, решения для обеспечения высокой доступности и оптимизация производительности. Его обширный практический опыт включает управление многотерабайтными базами данных, внедрение групп Always On Availability Groups и разработку автоматизированных стратегий резервного копирования и восстановления для критически важных бизнес-систем.

Благодаря своим техническим знаниям и практическому подходу Юань фокусируется на создании всеобъемлющих руководств, которые помогают администраторам баз данных и ИТ-специалистам решать сложные задачи. SQL Server Он эффективно решает задачи. Он всегда в курсе последних новостей. SQL Server выпускает новые версии и развивает технологии баз данных Microsoft, регулярно тестируя сценарии восстановления, чтобы убедиться, что его рекомендации соответствуют реальным передовым практикам.

Есть вопросы о SQL Server Восстановление или требуется дополнительное руководство по устранению неполадок в базе данных? Юань приветствует отзывы и предложения для улучшения этих технических ресурсов.