BDR 1.0.7 Documentation - 1.2. Differences between logical (row level) and physical (block level) replication

1.2. Differences between logical (row level) and physical (block level) replication

1.2. 논리적 (행 수준) 복제와 물리적 (블록 수준) 복제 간의 차이점

BDR uses PostgreSQL's logical decoding feature to implement a low overhead logical replication solution. It has significant advantages - and some disadvantages - when compared to PostgreSQL's older physical (block-based) streaming or archive-based replication with warm or hot standby

BDR 은 PostgreSQL 의 논리적 디코딩 기능을 사용하여 낮은 오버 헤드 논리 복제 솔루션을 구현합니다. warm 또는 hot standby 를 사용하는 PostgreSQL 의 오래된 물리적 (블록 기반) 스트리밍 또는 아카이브 기반 복제와 비교 할 때 상당한 이점과 몇 가지 단점이 있습니다

Logical replication has a different set of trade-offs to physical block-based replication. It isn't clearly better or worse. Physical replication is a lot simpler, has less lag for big transactions, is supported by older versions and may require less disk I/O, but generally consumes more network bandwidth, can't replicate a subset of databases or tables, and can't support multi-master or cross-version/cross-arch replication. Which solution you should use depends on what you need to do.

논리적 복제에는 물리적 블록 기반 복제와 다른 트레이드 오프가 있습니다. 그것은 분명히 좋거나 나쁘지 않습니다. 물리적 복제는 훨씬 간단하고 대규모 트랜잭션의 지연이 적고 이전 버전에서 지원 되며 디스크 I/O 가 덜 필요하지만 일반적으로 더 많은 네트워크 대역폭을 사용하거나 데이터베이스 또는 테이블의 하위 집합을 복제 할 수 없으며 다중 마스터 또는 교차 버전 / 교차 아치 복제 를 지원합니다. 어떤 솔루션을 사용해야 하는지는 사용자가 해야 할 일에 달려 있습니다.

The major differences between physical replication and logical replication as implemented by BDR are:

BDR 에서 구현 한 실제 복제와 논리적 복제 간의 주요 차이점은 다음과 같습니다.

• Multi-master replication is possible. All members are writable nodes that replicate changes.
  다중 마스터 복제가 가능합니다. 모든 구성원은 변경 사항을 복제하는 쓰기 가능한 노드 입니다.

• Data from index writes, VACUUM, hint bits, etc are not sent over the network, so bandwidth requirements may be reduced - especially when compared to physical replication with full_page_writes.
  
  인덱스 쓰기, VACUUM, 힌트 비트 등의 데이터는 네트워크를 통해 전송되지 않으므로 특히 full_page_writes 를 사용한 물리적 복제와 비교 할 때 대역폭 요구 사항이 줄어들 수 있습니다.

• There is no need to use hot_standby_feedback or to cancel long running queries on hot standbys, so there aren't any "cancelling statement due to conflict with recovery" errors.
  
  hot_standby_feedback 을 사용하거나 핫 스탠바이 (hot standby) 에서 장기 실행 쿼리를 취소 할 필요가 없으므로 "복구 충돌로 인한 명령문 취소" 오류가 발생하지 않습니다. <= 지대로 번역이 된건가? ㅎㅎ

• Temporary tables may be used on replicas.
  임시 테이블을 복제본에서 사용할 수 있습니다.

• Tables that aren't being replicated from elsewhere may be written to BDR.
  다른 곳에서 복제되지 않는 테이블은 BDR 에 기록 될 수 있습니다.

• Replication across major versions (e.g. 9.4 to 9.5) is supported.
  주요 버전 (예 : 9.4 ~ 9.5) 간의 복제가 지원됩니다.

• Replication across architectures and OSes (e.g. PPC64 Linux to x86_64 OS X) is supported.
  아키텍처 및 OS 간 복제 (예 : PPC64 Linux 에서 x86_64 OS X 로) 가 지원됩니다.

• Replication is per-database (or finer grained), whereas physical replication can and must replicate all databases.
  
  복제는 데이터베이스 마다 (또는 세분화 된) 반면, 물리적 복제는 모든 데이터베이스를 복제 할 수 있고 그렇게 복제해야 합니다.

• BDR's logical replication implementation imposes some restrictions on supported DDL (see: DDL replication) that do not apply for physical replication.
  
  BDR 의 논리적 복제 구현은 물리적 복제에 적용되지 않는 지원되는 DDL (DDL 복제 참조) 에 몇 가지 제한을 부과합니다.

• Commands that affect all databases, like ALTER SYSTEM or CREATE ROLE are not replicated by BDR and must be managed by the administrator.
  
  ALTER SYSTEM 또는 CREATE ROLE 과 같은 모든 데이터베이스에 영향을 주는 명령은 BDR 에 의해 복제되지 않으며 관리자가 관리해야합니다.

• Disk random I/O requirements and flush frequency may be higher than for physical replication.
  디스크 랜덤 I/O 요구사항 및 flush 빈도는 실제 복제보다 높을 수 있습니다.

• Only completed transactions are replicated. Big transactions may have longer replication delays because replication doesn't start until the transaction completes. Aborted transactions' writes are never replicated at all.
  
  완료된 트랜잭션 만 복제됩니다. 큰 트랜잭션은 트랜잭션이 완료 될 때까지 복제가 시작되지 않기 때문에 더 긴 복제 지연을 가질 수 있습니다. 중단된 트랜잭션의 쓰기는 전혀 복제되지 않습니다.

• Logical replication requires at least PostgreSQL 9.4.
  논리적 복제에는 최소한 PostgreSQL 9.4 이상이 필요합니다.

• Logical replication cannot be used for point-in-time recovery (though it can support a replication delay).
  
  논리적 복제는 특정 시점 복구에 사용할 수 없습니다. (복제 지연을 지원할 수는 있음)

• Logical replication only works via streaming, not WAL file archiving, and requires the use of a replication slot.
  
  논리적 복제는 WAL 파일 아카이브가 아닌 스트리밍을 통해서만 작동하며 복제 슬롯을 사용해야 합니다.

• Cascading replication is not (yet) supported by logical replication.
  계단식 복제는 아직 논리적 복제에서 지원되지 않습니다.

Most users will want to use physical replication and/or WAL archiving for redundancy, high availability, backup and PITR. Logical replication is well suited to data integration, data movement and data aggregation (often as an alternative to or combined with ETL), for scale-out and for distributed multi-master deployments.

대부분의 사용자는 중복, 고가용성, 백업 및 PITR 을 위해 물리적 복제 및 / 또는 WAL 아카이빙을 사용하고자 합니다. 논리적 복제는 데이터 통합, 데이터 이동 및 데이터 집계 (ETL의 대체 또는 조합으로 사용됨), 수평 확장 및 분산 멀티 마스터 배포에 적합 합니다.

It's possible to replicate between different PostgreSQL versions, operating systems and/or processor architectures using logical replication because it can fall back to sending data in text form - just like SQL. Where the servers are compatible it can use the faster-to-process binary representation or an intermediate form. Logical replication cannot prevent all possible incompatibilities though - for example, it isn't possible to replicate a type added in PostgreSQL 9.5 to PostgreSQL 9.4 because 9.4 has no way to store and represent it.

논리적 복제를 사용하여 다른 PostgreSQL 버전, 운영 체제 및 프로세서 아키텍처간에 복제 할 수 있습니다. SQL 과 마찬가지로 텍스트 형식으로 데이터를 전송 할 수 있기 때문입니다. 서버가 호환되는 곳에서는 더 빠른 프로세스 바이너리 표현이나 중간 형식을 사용 할 수 있습니다. 예를 들어, PostgreSQL 9.5 에 추가 된 유형을 PostgreSQL 9.4 에 복제 할 수 없는 경우가 있습니다. 9.4 에는 이를 저장하고 표현 할 수 있는 방법이 없으므로 복제가 가능한 모든 비 호환성을 막을 수는 없습니다.

Unlike physical replication, which replicates all databases on a PostgreSQL install, logical decoding permits (and requires) separate replication of each database. It can also replicate a subset of tables within a database. It is not possible to configure wildcard replication of all databases on a server in logical replication. You can replicate multiple databases, but each database must be configured separately.

PostgreSQL 설치에서 모든 데이터베이스를 복제하는 물리적 복제와 달리 논리적 디코딩은 각 데이터베이스의 별도 복제를 허용합니다. 또한 데이터베이스 내의 테이블 서브 세트를 복제 할 수도 있습니다. 논리적 복제에서 서버의 모든 데이터베이스에 대해 와일드 카드 복제를 구성 할 수는 없습니다. 여러 데이터베이스를 복제 할 수 있지만 각 데이터베이스는 별도로 구성해야합니다.

Temporary tables may always be created on all nodes, even if they are also receiving replicated data. There's no prohibition against doing so like it exists for PostgreSQL's block-level replication features.

임시 테이블은 복제 된 데이터를 받는 경우에도 모든 노드에서 항상 만들어 질 수 있습니다. PostgreSQL 의 블록 레벨 복제 기능과 마찬가지로 그렇게 하는 것에 대한 금지는 없습니다.

Local writes are not limited to temporary tables. UNLOGGED tables may be created even on nodes that are receiving changes from upstream/peer nodes. Additionally, replication sets allow changes to only a subset of tables to be replicated if desired, so some normal tables may be excluded from replication. This makes BDR very useful for use cases where significant work is done on nodes that also receive replicated data from elsewhere.

로컬 쓰기는 임시 테이블로 제한되지 않습니다. 업스트림 / 피어 노드에서 변경 사항을 수신하는 노드에서도 UNLOGGED 테이블이 생성 될 수 있습니다. 또한 복제 집합을 사용하면 원할 경우 테이블의 하위 집합만 변경하여 복제 할 수 있으므로 일부 일반 테이블은 복제에서 제외 될 수 있습니다. 따라서 BDR 은 다른 곳에서도 복제된 데이터를 수신하는 노드에서 중요한 작업이 수행되는 사용 사례에 매우 유용합니다.

Logical replication doesn't start replicating a transaction until it commits. This can cause longer replication delays for big transactions than physical replication, where the transaction's changes get replicated as soon as they're written. It also lets logical replication entirely skip replication of writes by aborted transactions. Future enhancements to logical decoding may permit streaming of transactions before they're committed.

논리적 복제는 트랜잭션이 커밋 될 때 까지 복제를 시작하지 않습니다. 이로 인해 물리적 복제보다 큰 트랜잭션에 대한 복제 지연이 길어질 수 있습니다. 물리적 복제는 트랜잭션의 변경 사항이 기록되는 즉시 복제됩니다. 또한 논리적 복제는 중단된 트랜잭션에 의한 쓰기 복제를 완전히 건너 뛸 수 있습니다. 논리 디코딩의 향후 개선 사항은 커밋되기 전에 트랜잭션 스트리밍을 허용 할 수 있습니다.

Because logical replication is only supported in streaming mode (rather than WAL archiving) it isn't suitable for point-in-time recovery. Logical replication may be used in conjunction with streaming physical replication and/or PITR, though; it is not necessary to choose one or the other.

논리적 복제는 WAL 아카이브가 아닌 스트리밍 모드에서만 지원되기 때문에 특정 시점 복구에는 적합하지 않습니다. 논리 복제는 스트리밍 물리적 복제 및 PITR 과 함께 사용 될 수 있습니다. 둘 중 하나를 선택할 필요가 없습니다.