Существует онлайн-приложение книжного магазина колледжа, где многие студенты могут покупать книги. Каждый раз, когда студент входит в систему, он смотрит список предложений, основанный на его предыдущей истории покупок. SQL Server, на котором хранятся данные о клиентах, находится в Сиэтле, но эти студенты входят в систему со всего мира. Следовательно, производительность может пострадать, а те, кто находится дальше по глобальной сети, могут столкнуться с задержкой во времени для запросов.
Вместо того, чтобы студенты, находящиеся подальше, страдали от медленной загрузки страниц, можно использовать репликацию для копирования и поддержки объектов базы данных на нескольких сайтах и последующей синхронизации, чтобы поддерживать согласованность. На каждом сайте хранится та часть базы данных, которая содержит наиболее актуальные и наиболее часто используемые данные. Теперь каждый студент может покупать книги на сайте, и данные будут синхронизированы позже.
Как работает репликация данных
Есть несколько серверных компонентов, и они берут на себя разные роли для реализации репликации. Роль издателя - это экземпляр базы данных, в котором находится источник данных, и он содержит объекты, разработанные как статьи репликации. Эти статьи группируются и публикуются в публикации, поэтому данные реплицируются как единое целое. У издателя может быть несколько публикаций.
Роль распространителя - это экземпляр базы данных, содержащий базы данных распространителя. Каждый издатель сопоставляется с единой базой данных распространителя, в которой хранятся реплицированные данные от издателя, которые должны быть переданы подписчику. Распространитель может быть настроен как местный распространитель, то есть один экземпляр сервера может выполнять роли как издателя, так и распространителя. Если дистрибьютор настроен на отдельных серверах, он называется удаленным дистрибьютором.
Роль подписчика - это экземпляры, которые получают реплицированные данные, подписываясь на публикации. Подписчик не ограничен и имеет право получать данные от нескольких издателей, а объекты могут обновляться в зависимости от типа репликации. Если возможно, издатель получит эти изменения от подписчика и повторно опубликует данные.
Как правило, подписчик получает изменения данных двумя способами: через принудительную подписку или подписку по запросу. Разница в том, какой компонент сервера выполняет обновления. С помощью push дистрибьютор подталкивает или напрямую обновляет базу данных подписчиков. С помощью pull подписчик связывается с распространителем, чтобы узнать, были ли какие-либо изменения, и он сам выполняет обновление.
Три типа репликации данных
Для реализации репликации используются несколько агентов, выполняющих задания, связанные с копированием изменений, отслеживанием изменений и распространением данных. Какие агенты необходимы, зависит от типа используемой репликации. Есть три основных типа репликации .
1. Репликация снимков
Репликация моментальных снимков - это самый простой тип репликации данных, который используется, если данные меняются не так часто или если требуется репликация небольших объемов данных. Например, если есть таблицы, которые нечасто обновляются, то можно использовать агенты моментальных снимков для однократного или многократного копирования всей базы данных по расписанию. Затем агент распространения отвечает за передачу этих файлов подписчику.
Этот метод не требует особого обслуживания, поскольку распределяется только моментальный снимок данных в определенный момент времени. Кроме того, нет необходимости отслеживать изменения, потому что каждый раз, когда подписчик получает обновление, оно перезаписывает всю копию данных.
К сожалению, копирование всей базы данных может привести к большим задержкам или увеличению времени ожидания, чем хотелось бы. Для создания снимков требуется удерживать блокировку объектов. Это не удобно, если данные меняются часто и могут повлиять на производительность - например, если у издателя много операций вставки, обновления и удаления.
Помимо использования агентов моментальных снимков для создания моментальных снимков, репликация транзакций также использует преимущества агентов чтения журналов, которые выполняются на распределителе. Агент чтения журнала считывает журналы транзакций базы данных издателя и доставляет только отмеченные изменения, а не ожидает обработки всей базы данных. Это обеспечивает гибкость, поскольку дает вам возможность решить, какую часть базы данных публиковать (например, столбец). Затем агент распространителя перемещает транзакции к подписчикам, и там, где он выполняется, будут реализованы стратегии подписки push и pull соответственно.
2. Репликация транзакций
Стандартная репликация транзакций подразумевает, что данные на подписчике доступны только для чтения. Однако существуют различные типы публикаций, которые позволяют вносить изменения на подписчике. Если эти изменения внесены, они могут быть возвращены издателю для повторной публикации. Агент чтения очереди используется для двунаправленной репликации транзакций, он считывает изменения из очереди и применяет их к издателю.
Репликация транзакций очень выгодна в среде «сервер-сервер», где изменения могут быть внесены на издателе и подписчике в режиме реального времени - например, данные в реальном времени, касающиеся того, какие рейсы в настоящее время доступны для авиакомпании. В этом случае нет смысла использовать репликацию моментальных снимков, поскольку обновления обычно синхронизируются один раз в день или по расписанию.
3. Репликация слиянием
Репликация слиянием похожа на репликацию транзакций, но позволяет объединять обновления как у подписчика, так и у издателя. Многие подписчики могут отключаться, обновлять данные в разное время, а затем снова подключаться к сети и синхронизировать эти изменения позже.
Этот тип репликации, вероятно, будет использоваться в средах от сервера к клиенту, например в мобильных клиентах. Подобно репликации моментальных снимков и транзакций, первоначальный моментальный снимок создается агентом моментальных снимков, но затем агент слияния отслеживает изменения и разрешает конфликты с триггерами. Если несколько подписчиков обновляют одни и те же строки, это может вызвать проблему. Следовательно, необходимо учитывать разрешение конфликтов.