Одноранговая репликация транзакцийPeer-to-Peer - Transactional Replication

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL AzureнетХранилище данных SQL AzureнетParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

Одноранговая репликация поддерживает масштабируемые и отказоустойчивые решения, сохраняя копии данных на нескольких экземплярах сервера, которые также называются узлами.Peer-to-peer replication provides a scale-out and high-availability solution by maintaining copies of data across multiple server instances, also referred to as nodes. Одноранговая репликация, основанная на репликации транзакций, распространяет согласованные на уровне транзакций изменения почти в реальном времени.Built on the foundation of transactional replication, peer-to-peer replication propagates transactionally consistent changes in near real-time. Это позволяет приложениям, для которых требуется масштабируемость операций чтения, распределять клиентские операции чтения на несколько узлов.This enables applications that require scale-out of read operations to distribute the reads from clients across multiple nodes. Поскольку данные сохраняются на узлах почти в режиме реального времени, одноранговая репликация обеспечивает избыточность данных, что повышает доступность данных.Because data is maintained across the nodes in near real-time, peer-to-peer replication provides data redundancy, which increases the availability of data.

Рассмотрим веб-приложение.Consider a Web application. В этом случае извлечь выгоду из одноранговой репликации можно следующими способами.This can benefit from peer-to-peer replication in the following ways:

  • Запросы к каталогам и другие операции чтения распределяются на нескольких узлах.Catalog queries and other reads are spread across multiple nodes. Тем самым повышается производительность и сохраняется согласованность.This enables performance to remain consistent as reads increase.

  • Если один из узлов в системе выходит из строя, уровень приложения может перенаправить операции записи на другой узел.If one of the nodes in the system fails, an application layer can redirect the writes for that node to another node. Это позволяет сохранить доступность данных.This maintains availability.

  • Если узлу требуется обслуживание или вся система нуждается в обновлении, каждый узел можно перевести в режим «вне сети», а затем опять добавить к системе, не затрагивая доступность приложения.If a node requires maintenance or the whole system requires an upgrade, each node can be taken offline and added back to the system without affecting the availability of the application.

    Хотя одноранговая репликация позволяет масштабировать операции чтения, производительность операций записи для топологии такая же, как для одного узла.Although peer-to-peer replication enables scaling out of read operations, write performance for the topology is like that for a single node. Это объясняется тем, что в конце концов все операции вставки, обновления и удаления распространяются на все узлы.This is because ultimately all inserts, updates, and deletes are propagated to all nodes. Примененное к данному узлу изменение распознается репликацией, что предотвращает выполнение изменений на узлах более одного раза.Replication recognizes when a change has been applied to a given node and prevents changes from cycling through the nodes more than one time. Настоятельно рекомендуется выполнять операции записи для каждой строки только на одном узле по следующим причинам.We strongly recommend that write operations for each row be performed at only node, for the following reasons:

  • Если строка изменяется на нескольких узлах, это может вызвать конфликт или даже потерю обновления, когда эта строка передается на другие узлы.If a row is modified at more than one node, it can cause a conflict or even a lost update when the row is propagated to other nodes.

  • При репликации изменений всегда существует некоторая задержка.There is always some latency involved when changes are replicated. Для приложений, которым требуется немедленно отслеживать последние изменения, равномерное распределение динамической загрузки может оказаться проблематичным.For applications that require the latest change to be seen immediately, dynamically load balancing the application across multiple nodes can be problematic.

    Одноранговая репликация содержит возможность включить обнаружение конфликтов во всей одноранговой топологии.Peer-to-peer replication includes the option to enable conflict detection across a peer-to-peer topology. Эта возможность помогает избежать проблем, которые вызываются необнаруженными конфликтами, в том числе недопустимым поведением приложения и потерянными обновлениями.This option helps prevent the issues that are caused from undetected conflicts, including inconsistent application behavior and lost updates. При включенном обнаружении конфликтов конфликтующее изменение по умолчанию рассматривается как критическая ошибка, вызывающая сбой агента распространителя.By enabling this option, by default a conflicting change is treated as a critical error that causes the failure of the Distribution Agent. В случае конфликта топология остается в несогласованном состоянии, пока конфликт не будет разрешен вручную, а данные согласованы во всей топологии.In the event of a conflict, the topology remains in an inconsistent state until the conflict is resolved manually and the data is made consistent across the topology. Дополнительные сведения см. в разделе Conflict Detection in Peer-to-Peer Replication.For more information, see Conflict Detection in Peer-to-Peer Replication.

Примечание

Чтобы избежать возможной несогласованности данных, убедитесь, что в одноранговой топологии отсутствуют конфликты, даже при включенном обнаружении конфликтов.To avoid potential data inconsistency, make sure that you avoid conflicts in a peer-to-peer topology, even with conflict detection enabled. Чтобы операции записи выполнялись только на одном узле, приложения, получающие доступ к данным и изменяющие их, должны секционировать операции вставки, обновления и удаления.To ensure that write operations for a particular row are performed at only one node, applications that access and change data must partition insert, update, and delete operations. Такое секционирование обеспечивает тот факт, что изменения конкретной строки на одном узле синхронизируются с остальными узлами в топологии, прежде чем эта строка будет изменена другим узлом.This partitioning ensures that modifications to a given row originating at one node are synchronized with all other nodes in the topology before the row is modified by a different node. Если приложению требуется усложненное обнаружение конфликтов, используйте репликацию слиянием.If an application requires sophisticated conflict detection and resolution capabilities, use merge replication. Дополнительные сведения см. в статьях Merge Replication (Репликация слиянием) и Detect and Resolve Merge Replication Conflicts (Обнаружение и разрешение конфликтов репликации слиянием).For more information, see Merge Replication and Detect and Resolve Merge Replication Conflicts.

Одноранговые топологииPeer-to-Peer Topologies

Типичные способы использования одноранговой репликации проиллюстрированы следующими сценариями.The following scenarios illustrate typical uses for peer-to-peer replication.

Топология с двумя участвующими базами данныхTopology That Has Two Participating Databases

Одноранговая репликация с двумя узламиPeer-to-peer replication, two nodes

На обоих приведенных выше рисунках показаны две участвующие базы данных и пользовательский трафик, направленный к базам данных через сервер приложений.Both of the preceding illustrations show two participating databases, with user traffic directed to the databases through an application server. Такую конфигурацию можно использовать для различных приложений — от веб-сайтов до приложений рабочих групп. Это позволяет получить следующие преимущества.This configuration can be used for a variety of applications, from Web sites to workgroup applications, and provides the following benefits:

  • Улучшенная производительность операции чтения, так как чтение распределено на два сервера.Improved read performance, because reads are spread out over two servers.

  • Более высокая доступность при необходимости обслуживания или в случае сбоя одного из узлов.Higher availability if maintenance is required or in case of failure at one node.

    На обеих иллюстрациях операция чтения между участвующими базами данных сбалансирована, но обновления обрабатываются разными способами:In both illustrations, read activity is load-balanced between the participating databases, but updates are handled differently:

  • Слева операции обновления секционируются между двумя серверами.On the left, updates are partitioned between the two servers. Если база данных содержит каталог продукции, можно, например, создать пользовательское приложение, направляющее обновления продуктов, начинающихся символами с «А» до «М», на узел A , а обновления продуктов с «Н» до «Я» — на узел B .If the database contained a product catalog, you could, for example, have a custom application direct updates to node A for product names that start with A through M, and direct updates to node B for product names that start with N through Z. Updates are then replicated to the other node.

  • Справа все обновления направляются на узел В. С узла В обновления реплицируются на узел A. Если узел B находится в режиме "вне сети" (например, на обслуживании), сервер приложений может направлять все операции на узел A. Когда узел B переходит в режим "в сети", на него можно направлять обновления, и сервер приложений может переместить все обновления обратно на узел B или сохранить их передачу на узел A.On the right, all updates are directed to node B. From there, updates are replicated to node A. If B is offline (for example, for maintenance), the application server can direct all activity to A. When B is back online, updates can flow to it, and the application server can move all updates back to B or keep directing them to A.

    Одноранговая репликация поддерживает любой из этих подходов, но основной пример обновления, показанный справа, также часто используется для стандартной репликации транзакций.Peer-to-peer replication can support either approach, but the central update example on the right is also often used with standard transactional replication.

Топологии с тремя или более участвующими базами данныхTopologies That Have Three or More Participating Databases

Одноранговая репликация в распределенные места назначенияPeer-to-peer replication to dispersed locations

На предыдущем рисунке показаны три участвующие базы данных, предоставляющие данные для глобальной организации по поддержке программного обеспечения с офисами в Лос-Анджелесе, Лондоне и Тайбэе.The preceding illustration shows three participating databases that provide data for a worldwide software support organization, with offices in Los Angeles, London, and Taipei. Инженеры службы поддержки во всех офисах принимают звонки клиентов, вводят и обновляют сведения о каждом звонке.The support engineers at each office take customer calls and enter and update information about each customer call. Часовые пояса трех офисов отличаются на восемь часов, поэтому рабочие часы не перекрываются.The time zones for the three offices are eight hours apart, so there is no overlap in the workday. Когда закрывается офис в Тайбэе, открывается офис в Лондоне.As the Taipei office closes, the London office is opening for the day. Если звонок находится в стадии обработки во время закрытия одного офиса, он передается представителю в другой открытый офис.If a call is still in progress as one office is closing, the call is transferred to a representative at the next office to open.

В каждом офисе имеется база данных и сервер приложений, которые используются инженерами службы поддержки для ввода и обновления сведений о звонках клиентов.Each location has a database and an application server, which are used by the support engineers as they enter and update information about customer calls. Топология секционируется по времени.The topology is partitioned by time. Поэтому обновления происходят на узле, открытом для бизнеса в текущее время, а затем передаются в другие участвующие базы данных.Therefore, updates occur only at the node that is currently open for business, and then the updates flow to the other participating databases. Данная топология обеспечивает следующие преимущества:This topology provides the following benefits:

  • Независимость без изоляции: в каждом офисе можно независимо добавлять, обновлять или удалять данные, при этом также можно использовать данные совместно, так как они реплицируются на все участвующие базы данных.Independence without isolation: Each office can insert, update, or delete data independently but can also share the data because it is replicated to all other participating databases.

  • Более высокая доступность в случае сбоя или во время обслуживания одной или нескольких участвующих баз данных.Higher availability in case of failure or to allow maintenance at one or more of the participating databases.

    Одноранговая репликация с тремя и четырьмя узламиPeer-to-peer replication, three and four nodes

    На предыдущем рисунке показано добавление узла в топологию с тремя узлами.The preceding illustration shows the addition of a node to the three-node topology. В этом сценарии узел можно добавить по следующим причинам.A node could be added in this scenario for the following reasons:

  • Так как другой офис открыт.Because another office is opened.

  • Чтобы обеспечить более высокую доступность в целях поддержки обслуживания или повышения отказоустойчивости при сбое диска или других серьезных неисправностях.To provide higher availability to support maintenance or increase fault tolerance if a disk failure or other major failure occurs.

    Обратите внимание, что в обеих трех- и четырехузловых топологиях все базы данных публикуют свои данные и подписываются на данные из остальных баз данных.Notice that in both the three- and four-node topologies, all databases publish and subscribe to all other databases. Этим обеспечивается максимальная доступность при проведении обслуживания или в случае сбоя на одном или нескольких узлах.This provides maximum availability in case of maintenance needs or failure of one or more nodes. По мере добавления узлов необходимо соблюдать баланс между доступностью и масштабируемостью с одной стороны и производительностью, сложностью развертывания и администрирования с другой стороны.As nodes are added, you must balance availability and scalability needs against performance and the complexity of deployment and administration.

Настройка одноранговой репликацииConfiguring Peer-to-Peer Replication

Настройка топологии одноранговой репликации очень похожа на настройку серии стандартных публикаций и подписок транзакций.Configuring a peer-to-peer replication topology is very similar to configuring a series of standard transactional publications and subscriptions. В следующих разделах показан процесс настройки системы из трех узлов, аналогичной конфигурации с одноранговой топологией, которая представлена выше на рисунке слева.The steps described in the following topics show the configuration of a three-node system, similar to the configuration shown on the left in the previous illustration that shows peer-to-peer topology.

Вопросы использования одноранговой репликацииConsiderations for Using Peer-to-Peer Replication

В этом разделе представлены сведения и рекомендации по использованию одноранговой репликации.This section provides information and guidelines to consider when you use peer-to-peer replication.

Общие рекомендацииGeneral Considerations

  • Одноранговая репликация доступна только в выпусках SQL ServerSQL ServerEnterprise.Peer-to-peer replication is available only in Enterprise versions of SQL ServerSQL Server.

  • Все базы данных, участвующие в одноранговой репликации, должны содержать идентичные схемы и данные.All databases that participate in peer-to-peer replication should contain identical schema and data:

    • Имена объектов, схемы объектов и публикаций должны быть идентичными.Object names, object schema, and publication names should be identical.

    • Публикации для реплицирования должны разрешать изменения схемы.Publications must allow schema changes to be replicated. (То есть свойство публикации replicate_ddl должно иметь значение 1, которое является значением по умолчанию.) Дополнительные сведения см. в статье Внесение изменений в схемы баз данных публикации.(This is a setting of 1 for the publication property replicate_ddl, which is the default setting.) For more information, see Make Schema Changes on Publication Databases.

    • Фильтрация строк и столбцов не поддерживается.Row and column filtering are not supported.

  • Рекомендуется на каждом узле использовать собственную базу данных распространителя.We recommend that each node use its own distribution database. Это исключит возможность образования одной точки сбоя.This eliminates the potential of having a single point of failure.

  • Таблицы и другие объекты нельзя включать в несколько одноранговых публикаций в отдельной базе данных публикации.Tables and other objects cannot be included in multiple peer-to-peer publications in a single publication database.

  • Публикация должна быть доступна для одноранговой репликации до создания подписок.A publication must be enabled for peer-to-peer replication before any subscriptions are created.

  • Подписки должны быть инициализированы с помощью резервного копирования или параметра только поддержка репликации .Subscriptions must be initialized by using a backup or with the 'replication support only' option. Дополнительные сведения см. в статье Инициализация подписки на публикацию транзакций без моментального снимка.For more information, see Initialize a Transactional Subscription Without a Snapshot.

  • Не рекомендуется использовать столбцы идентификаторов.We do not recommend the use of identity columns. При использовании идентификаторов необходимо вручную управлять диапазонами, назначенными таблицам, в каждой участвующей базе данных.When using identities, you must manually manage the ranges assigned to the tables at each participating database. Дополнительные сведения см. в разделе "Назначение диапазонов для управления диапазонами идентификаторов вручную" статьи Replicate Identity Columns (Репликация столбцов идентификаторов).For more information, see the section "Assigning Ranges for Manual Identity Range Management" in Replicate Identity Columns.

Функциональные ограниченияFeature Restrictions

Одноранговая репликация поддерживает ключевые свойства репликации транзакций, но не поддерживает следующие параметры.Peer-to-peer replication supports the core features of transactional replication, but does not support the following options:

  • Инициация и повторная инициация с помощью моментальных снимков.Initialization and reinitialization with a snapshot.

  • Фильтрация строк и столбцов.Row and column filters.

  • Столбцы отметок времени.Timestamp columns.

  • Издатели и подписчики, отличные от SQL ServerSQL Server .Non- SQL ServerSQL Server Publishers and Subscribers.

  • Немедленно обновляемые подписки и подписки, обновляемые посредством очередей.Immediate updating and queued updating subscriptions.

  • Анонимные подписки.Anonymous subscriptions.

  • Частичные подписки.Partial subscriptions.

  • Присоединяемые подписки и трансформируемые подписки.Attachable subscriptions and transformable subscriptions. (Оба параметра устарели, начиная с версии SQL Server 2005SQL Server 2005).(Both of these options were deprecated in SQL Server 2005SQL Server 2005.)

  • Общие агенты распространителя.Shared Distribution Agents.

  • Параметр агента распространителя -SubscriptionStreams и параметр агента чтения журнала -MaxCmdsInTran.The Distribution Agent parameter -SubscriptionStreams and the Log Reader Agent parameter -MaxCmdsInTran.

  • Свойства статьи @destination_owner и @destination_table.The article properties @destination_owner and @destination_table.

  • Одноранговая репликация транзакций не поддерживает создание односторонней транзакционной подписки на одноранговые публикации.Peer-to-Peer transactional replication does not support creating a one-way transactional subscription to a Peer-to-Peer publication

    Следующие свойства имеют особые соглашения.The following properties have special considerations:

  • Свойство публикации @allow_initialize_from_backup должно иметь значение true.The publication property @allow_initialize_from_backup requires a value of true.

  • Свойство статьи @replicate_ddl должно иметь значение true, свойство @identityrangemanagementoption должно иметь значение manual, а свойство @status — значение 24 .The article property @replicate_ddl requires a value of true; @identityrangemanagementoption requires a value of manual; and @status requires that option 24 is set.

  • Свойствам статьи @ins_cmd, @del_cmdи @upd_cmd не может быть присвоено значение SQL.The value for article properties @ins_cmd, @del_cmd, and @upd_cmd cannot be set to SQL.

  • Свойству подписки @sync_type должно иметь значение none или automatic.The subscription property @sync_type requires a value of none or automatic.

Вопросы обслуживанияMaintenance Considerations

Некоторые действия требуют замораживания системы.Some actions require the system to be quiescent. Это подразумевает остановку действий в опубликованных таблицах на всех узлах и проверку получения изменений на каждом узле.This means stopping activity on published tables at all nodes and making sure that each node has received all changes from all other nodes.

Только одноранговые узлы SQL Server 2005 или сочетание узлов SQL Server 2005 с узлами SQL Server 2008 или более поздней версии.SQL Server 2005 peers only or mix of SQL Server 2005 peers with SQL Server 2008 peers and higher Только одноранговые узлы SQL Server 2005 или сочетание узлов SQL Server 2005 с узлами SQL Server 2008 или более поздней версии.SQL Server 2005 peers only or mix of SQL Server 2005 peers with SQL Server 2008 peers and higher Одноранговые узлы SQL 2008 и более поздние версииSQL2008 peers and higher Одноранговые узлы SQL 2008 и более поздние версииSQL2008 peers and higher
Добавление узла к топологииAdding a node to the topology 2 узла в полной топологии: замораживание не требуется.2 nodes in complete topology: No quiescing required. Используйте sync_type = 'initialize with backup'.Use sync_type = 'initialize with backup'. Более 2 узлов: требуется замораживание.More than 2 nodes: Quiescing required. sync_type = 'replication support only': требуется замораживание.sync_type = 'replication support only': Quiescing required. sync_type = 'initialize with backup' и 'initialize from lsn': замораживание не требуется.sync_type = 'initialize with backup' and 'initialize from lsn': No quiescing required.

Для изменения схемы топологии (добавление или удаление статьи) требуется замораживание.Topology schema changes (adding or dropping an article) requires quiescing. Дополнительные сведения см. в статье Администрирование одноранговой топологии (программирование репликации на языке Transact-SQL).For more information, see Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).

Для удаления узла из топологии никогда не требуется замораживание.Removing a node from the topology never requires quiescing.

Для изменения свойств статьи с помощью sp_changearticle никогда не требуется замораживание.Changing the article properties by using sp_changearticle never requires quiescing. Допустимыми изменениями (для P2P) являются свойства description, ins_cmd, upd_cmdи del_cmd .Allowable changes (for P2P) are the description, ins_cmd, upd_cmd, and del_cmd properties.

Для изменения схемы статьи (добавление или удаление столбца) никогда не требуется замораживание.Article Schema changes (adding/dropping column) never requires quiescing.

  • Добавление статьи: для добавления статьи в существующую конфигурацию необходимо заморозить систему, выполнить инструкцию CREATE TABLE и загрузить исходные данные на каждом узле в топологии, а также добавить новую статью на каждом узле в топологии.Adding article: For adding an article to an existing configuration- we need to quiesce the system, execute CREATE TABLE statement & load initial data at each node in the topology and add the new article at each node in the topology.

  • Удаление статьи: если мы хотим добиться согласованного состояния на всех узлах, необходимо заморозить топологию.Dropping article: If we want a consistent state on all nodes, we need to quiesce the topology

    Дополнительные сведения см. в статье Заморозка топологии репликации (программирование репликации на языке Transact-SQL) и Администрирование одноранговой топологии (программирование репликации на языке Transact-SQL).For more information, see Quiesce a Replication Topology (Replication Transact-SQL Programming) and Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).

  • Если к одноранговой топологии добавлен новый узел, восстановление необходимо выполнять только из резервных копий, созданных после добавления нового узла.If you add a new node to a peer-to-peer topology, you should restore only from backups that were created after the new node was added.

  • Повторно инициализировать подписки в одноранговой топологии нельзя.You cannot reinitialize subscriptions in a peer-to-peer topology. Если нужно убедиться в том, что узел имеет новую копию данных, восстановите резервную копию на этом узле.If you have to ensure that a node has a new copy of the data, restore a backup at the node.

См. также:See Also

Администрирование одноранговой топологии (программирование репликации на языке Transact-SQL) Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)
Стратегии архивации и восстановления из копии репликации моментальных снимков и репликации транзакций Strategies for Backing Up and Restoring Snapshot and Transactional Replication
Publication Types for Transactional Replication (Типы публикации для репликации транзакций)Publication Types for Transactional Replication