BDR 1.0.7 Documentation - 1.4. BDR: Weakly coupled multi-master replication

1.4. BDR: Weakly coupled multi-master replication

1.4. BDR : 약한 결합의 멀티 마스터 복제

When considering multi-master clustering or replication (with BDR or another technology) it is important to understand what's involved, and that not all multi-master systems are equal.

다중 마스터 클러스터링 또는 복제 (BDR 또는 다른 기술로)를 고려 할 때, 관련된 내용을 이해하는 것이 중요하며 모든 다중 마스터 시스템이 동일 하지는 않습니다.

Note: You don't have to use BDR for multi-master. It's quite reasonable to write to only one node, using BDR like an improved read-replica system. It's also possible to make sure that any given table/schema is only written to on one particular node, so no conflicts can arise. You still have to consider replication lag, but no more or less than with normal hot standbys. It only gets complicated when your application writes to the same tables on multiple nodes at once. If you need to do that, keep reading.

참고 : 다중 마스터에 BDR 을 사용 할 필요는 없습니다. 향상된 읽기 복제 시스템 처럼 BDR 을 사용하여 하나의 노드에만 쓰기가 가능합니다. 주어진 테이블 / 스키마가 하나의 특정 노드에만 쓰여지므로 충돌이 발생 할 수 없습니다. 복제 지연을 고려해야 하지만 정상적인 핫 스텐드바이 보다 더 강력하거나 수준이 낮지는 않습니다. 응용 프로그램이 한 번에 여러 노드의 동일한 테이블에 쓰는 경우에만 복잡해 집니다. 그렇게 해야 한다면, 계속 읽으십시오.

Some multi-master systems are tightly-coupled; these tend to make all nodes appear to be part of the same virtual database to outside clients, complete with cross-node locking, transaction isolation, etc. They also often - but not always - use shared storage, where each node connects to the same underlying database files over a SAN or similar. This makes life easier for application developers who're used to working with stand-alone or single-master databases because they can do everything just like they did before. Like with anything there's a price, though: a tightly coupled multi-master system does not scale out very well, especially for writes, and isn't very tolerant of latency, node outages, or network partitions.

일부 멀티 마스터 시스템은 단단히 결합되어 있습니다. 이들은 모든 노드를 외부 클라이언트와 동일한 가상 데이터베이스의 일부로 보이게 하고, 교차 노드 잠금, 트랜잭션 격리 등을 완료하는 경향이 있습니다. 또한 항상 그렇지는 않지만 항상 각 노드가 동일한 저장소에 연결하는 공유 저장소를 사용합니다. SAN 또는 유사 장치를 통해 기본 데이터베이스 파일. 따라서 독립 실행형 또는 단일 마스터 데이터베이스로 작업하는 데 익숙한 응용 프로그램 개발자는 전에 했던 것처럼 모든 작업을 수행 할 수 있기 때문에 작업이 더 쉬워집니다. 무엇보다 가격이 저렴합니다. 강하게 결합된 다중 마스터 시스템은 특히 쓰기의 경우 잘 확장되지 않으며 대기시간, 노드 작동 중단 또는 네트워크 파티션에 매우 관대하지 않습니다.

Other systems are loosely-coupled. They don't attempt to appear like a single seamless virtual database, and applications can see some differences depending on which node they are connected to. Most loosely coupled systems don't share storage; instead each node has a copy of the whole database or a subset of it locally. If they store only a subset of the data they may support routing queries to the correct node, or they may expect the application to determine which node to find data on. There is generally no global lock manager or transaction manager, so transactions on one node aren't affected by locks taken on other nodes. Many loosely coupled systems are asynchronous and eventually consistent (see: Concepts) so changes on one node aren't immediately visible on all other nodes at the same time. This can make application development more difficult, but in exchange makes the system very tolerant of latency between nodes, temporary network partitions or node outages, etc, and makes scale-out more efficient.

다른 시스템은 느슨하게 결합되어 있습니다. 그들은 하나의 완벽한 가상 데이터베이스 처럼 보이려고 시도하지 않으며 응용 프로그램은 연결된 노드에 따라 약간의 차이점을 볼 수 있습니다. 느슨하게 결합된 시스템의 대부분은 스토리지를 공유하지 않습니다. 대신에 각 노드는 데이터베이스 전체 또는 그 서브 세트의 사본을 로컬에 가지고 있습니다. 데이터의 하위 집합만 저장하는 경우 올바른 노드에 대한 쿼리 라우팅을 지원 할 수도 있고, 응용 프로그램에서 어떤 노드에서 데이터를 찾을지를 결정할 수도 있습니다. 일반적으로 전역 잠금 관리자 또는 트랜잭션 관리자가 없으므로 한 노드의 트랜잭션은 다른 노드에서 수행한 잠금의 영향을받지 않습니다. 많은 느슨하게 결합된 시스템은 비동기적 이고 결국 일관성이 있습니다 (개념 참조). 그래서 한 노드의 변경 사항이 동시에 다른 모든 노드에서 변경되지 않습니다. 이로 인해 애플리케이션 개발이 더욱 어려워 질 수는 있지만 교환으로 인해 시스템은 노드, 임시 네트워크 파티션 또는 노드 중단 등의 대기 시간에 매우 관대하며 스케일 아웃을보다 효율적으로 만듭니다.

BDR is a loosely coupled shared-nothing multi-master design.
BDR 은 느슨하게 연결된 비공유 멀티 마스터 설계입니다.

This is a broad and overly simplified characterisation of replication, but it's enough to explain why applications that use BDR for multi-master writes need to be aware of the anomalies that can be introduced by asynchronous multi-master replication. It should also help illustrate that applications get some significant benefits in exchange:

이것은 광범위하고 간략화 된 복제 특성화 이지만, 다중 마스터 쓰기에 BDR 을 사용하는 응용 프로그램이 비동기 다중 마스터 복제로 인해 발생 할 수 있는 예외를 인식해야하는 이유를 설명하기에 충분합니다. 또한 응용 프로그램이 몇 가지 중요한 이점을 얻을 수 있음을 보여 줍니다.

• Applications using BDR are free to write to any node so long as they are careful to prevent or cope with conflicts.
  BDR 을 사용하는 응용 프로그램은 충돌을 예방하거나 대처 할 때 조심스럽게 모든 노드에 자유롭게 작성할 수 있습니다.

• There is no complex election of a new master if a node goes down or network problems arise. There is no wait for failover. Each node is always a master and always directly writeable.
  노드가 다운 되거나 네트워크 문제가 발생하면 새로운 마스터의 복잡한 선거는 없습니다. 장애 조치 대기가 없습니다. 각 노드는 항상 마스터 이며 항상 직접 쓰기가 가능합니다.

• The application can be geographically distributed so that the app and is close to the data and the user for better performance and availability. Reads can be satisfied locally.
  응용 프로그램은 지리적으로 분산되어 더 나은 성능과 가용성을 위해 응용 프로그램과 데이터 및 사용자와 가깝게 배치 할 수 있습니다. 읽기는 로컬에서 충족 될 수 있습니다.

• Applications can be partition-tolerant: the application can keep keep working even if it loses communication with some or all other nodes, then re-sync automatically when connectivity is restored. Loss of a critical VPN tunnel or WAN won't bring the entire store or satellite office to a halt.
  응용 프로그램은 파티션을 허용 할 수 있습니다. 응용 프로그램은 일부 또는 다른 모든 노드와의 통신이 끊긴 경우에도 계속 작동 할 수 있으며 연결이 복원되면 자동으로 다시 동기화 됩니다. 중요한 VPN 터널 또는 WAN 의 손실로 인해 상점 또는 위성 사무실 전체가 중단되지 않습니다.

With the advantages come challenges.
장점으로 인해 제한 사항이 따릅니다.

Because BDR replicates asynchronously, not all nodes have the same view of the data at any given instant. On a single node it is guaranteed that committed transactions' changes become visible immediately to newly started transactions (or in READ COMMITTED mode, statements). This isn't true in BDR - if you COMMIT a transaction that changes a row on one node, then SELECT that row on another node, you may well still get the old value. Applications must therefore be designed to be tolerant of stale data or to be "sticky" to a node, where they prefer read data from the same node they write it to. This is also true of applications using PostgreSQL's physical replication feature unless it is used in synchronous mode with only one replica, so it's a challenge that's far from unique to BDR.
BDR 은 비동기로 복제하기 때문에 모든 노드가 주어진 순간에 동일한 데이터 보기를 갖는 것은 아닙니다. 단일 노드에서 새로 커밋 된 트랜잭션 (또는 READ COMMITTED 모드, 내용)에서 커밋 된 트랜잭션의 변경 내용을 즉시 볼 수 있습니다. 이것은 BDR 에서 사실이 아닙니다. 한 노드에서 행을 변경하는 트랜잭션을 COMMIT 한 다음 다른 노드에서 해당 행을 SELECT하면 여전히 이전 값을 얻을 수 있습니다. 그러므로 응용 프로그램은 오래된 노드에 대해 연동되거나 노드에 연동되도록 설계되어야합니다. 노드에서 쓰기 작업을 수행하는 동일한 노드에서 데이터를 읽는 것을 선호합니다. 이는 PostgreSQL의 물리적 복제 기능이 단 하나의 복제본으로 동기 모드에서 사용 되지 않는 한 응용 프로그램에서도 마찬가지 이므로 BDR 만의 고유한 문제는 아닙니다.

Locking operations are not replicated to other nodes. If you lock a row or table in one node the other nodes have no idea it is locked elsewhere. Applications that rely on row or table locking for correctness will only work correctly if all their writes and locked reads occur on a single node. Applications might rely on locking explicitly via LOCK TABLE or SELECT ... FOR UPDATE / SHARE, but most applications rely on it implicitly via UPDATEand DELETE row-locking, so the absence of explicit locking does not mean an app is automatically multi-master safe.
잠금 조작은 다른 노드로 복제되지 않습니다. 한 노드에서 행이나 표를 잠그면 다른 노드는 다른 곳에 잠겨 있다는 것을 모릅니다. 정확성을 위해 행 또는 테이블 잠금에 의존하는 응용 프로그램은 모든 쓰기 및 잠긴 읽기가 단일 노드에서 발생하는 경우에만 올바르게 작동합니다. 응용 프로그램은 LOCK TABLE 또는 SELECT ... FOR UPDATE / SHARE 를 통해 명시 적으로 잠그는 것에 의존 할 수 있지만 대부분의 응용 프로그램은 UPDATE 및 DELETE 행 잠금을 통해 암시적으로 의존 하므로 명시적 잠금이 없어도 응용 프로그램이 자동으로 다중 마스터를 안전하게 한다는 것을 의미 하지는 않습니다 .

Because of asynchronous replication and the lack of global locking, it is possible for transactions on different nodes to perform actions that could not happen if both transactions ran on a single node. These are called conflicts and are discussed in detail separately; see Multi-master conflicts. BDR can resolve conflicts using a simple last-update-wins strategy or using user-defined conflict handlers. Either way the application design needs to consider that conflicts may occur, and where possible minimise them. Naïive applications that ignore the the possibility of conflicts when writing to multiple masters may suffer from lost-updates and other undesirable data anomalies.
비동기 복제와 전역 잠금이 없기 때문에 서로 다른 노드의 트랜잭션이 두 트랜잭션이 단일 노드에서 실행 될 때 발생 할 수 없는 작업을 수행 할 수 있습니다. 이들은 충돌이라고 불리며 별도로 자세하게 논의됩니다. 이에 대하여 다중 마스터 충돌을 참조하십시오. BDR 은 간단한 last-update-wins 전략을 사용하거나 사용자 정의 충돌 핸들러를 사용하여 충돌을 해결 할 수 있습니다. 어쨌든 응용 프로그램 설계에서 충돌이 발생할 수 있음을 고려해야하며 가능한 경우 충돌을 최소화 해야합니다. 여러 주인에게 글을 쓸 때 충돌 가능성을 무시하는 순수한 응용 프로그램은 업데이트 손실 및 기타 바람직하지 않은 데이터 이상으로 어려움을 겪을 수 있습니다.

BDR provides some tools to help make application design easier. The most important is Global sequences, which provide a BDR-group-wide generator of unique values for use in synthetic keys. Others are discussed in the Multi-master conflicts section.
BDR 은 응용 프로그램을 보다 쉽게 디자인 할 수 있는 몇 가지 도구를 제공합니다. 가장 중요한 것은 범용키에 사용할 고유 값의 BDR 그룹 전체 생성기를 제공하는 전역 시퀀스입니다. 다른 것들은 다중 마스터 충돌 섹션에서 논의됩니다.