A.14 MySQL 9.5 FAQ: Replication

A.14 MySQL 9.5 FAQ: Replication

다음 섹션에서는 MySQL Replication에 대해 가장 자주 묻는 질문에 대한 답변을 제공합니다.

A.14.1. replica는 항상 source에 연결되어 있어야 합니까?
A.14.2. replication을 활성화하려면 source와 replica에서 네트워킹을 반드시 활성화해야 합니까?
A.14.3. replica가 source에 비해 얼마나 늦었는지 어떻게 알 수 있습니까? 다시 말해 replica가 복제한 마지막 statement의 날짜는 어떻게 알 수 있습니까?
A.14.4. replica가 따라잡을 때까지 source의 update를 차단하려면 어떻게 해야 합니까?
A.14.5. two-way replication을 설정할 때 어떤 이슈들을 알고 있어야 합니까?
A.14.6. 시스템 성능을 향상하기 위해 replication을 어떻게 사용할 수 있습니까?
A.14.7. 성능 향상을 위한 replication을 사용하기 위해 내 애플리케이션의 client code를 어떻게 준비해야 합니까?
A.14.8. 언제, 어느 정도까지 MySQL replication이 시스템 성능을 향상시킬 수 있습니까?
A.14.9. redundancy 또는 고가용성을 제공하기 위해 replication을 어떻게 사용할 수 있습니까?
A.14.10. replication source server가 statement-based 또는 row-based binary logging format 중 무엇을 사용하는지 어떻게 알 수 있습니까?
A.14.11. replica에 row-based replication을 사용하도록 어떻게 지시합니까?
A.14.12. GRANT 및 REVOKE statement가 replica 머신으로 복제되지 않도록 하려면 어떻게 해야 합니까?](https://dev.mysql.com/doc/refman/9.5/en/faqs-replication.html#faq-replication-how-prevent-grant-revoke)
A.14.13. 혼합 운영체제(예: source는 Linux에서 실행되고 replica는 macOS와 Windows에서 실행됨)에서 replication이 동작합니까?
A.14.14. 혼합 하드웨어 아키텍처(예: source는 64-bit 머신에서 실행되고 replica는 32-bit 머신에서 실행됨)에서 replication이 동작합니까?

A.14.1.	replica는 항상 source에 연결되어 있어야 합니까?
	아닙니다, 그렇지 않습니다. replica는 수 시간 또는 수 일 동안 down되거나 연결이 끊긴 상태로 있을 수 있으며, 이후 다시 연결하여 update를 따라잡을 수 있습니다. 예를 들어, dial-up 링크를 통해 source/replica 관계를 설정할 수 있으며, 이 링크는 가끔씩 짧은 시간 동안만 up 상태가 됩니다. 이로 인해, 특별한 조치를 취하지 않는 한, 임의의 시점에서 replica가 source와 동기화되어 있다고 보장할 수는 없습니다.<br><br>연결이 끊긴 replica가 catchup을 할 수 있도록 보장하려면, 아직 replica로 복제되지 않은 정보를 포함하는 binary log 파일을 source에서 삭제하지 않아야 합니다. 비동기식 replication은 replica가 마지막으로 event를 읽은 지점부터 계속 binary log를 읽을 수 있는 경우에만 동작할 수 있습니다.
A.14.2.	replication을 활성화하려면 source와 replica에서 네트워킹을 반드시 활성화해야 합니까?
	예, source와 replica에서 네트워킹이 활성화되어 있어야 합니다. 네트워킹이 활성화되어 있지 않으면, replica는 source에 연결하여 binary log를 전송받을 수 없습니다. 각 server의 설정 파일에서 skip_networking 시스템 변수가 활성화되어 있지 않은지 확인하십시오.
A.14.3.	replica가 source에 비해 얼마나 늦었는지 어떻게 알 수 있습니까? 다시 말해 replica가 복제한 마지막 statement의 날짜는 어떻게 알 수 있습니까?
	[`SHOW REPLICA
A.14.4.	replica가 따라잡을 때까지 source의 update를 차단하려면 어떻게 해야 합니까?
	다음 절차를 사용하십시오:<br>1. source에서 다음 statement를 실행합니다:<br><br>```sql
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
<br><br>[`SHOW`](https://dev.mysql.com/doc/refman/9.5/en/show.html "15.7.7 SHOW Statements") statement의 output에서 replication 좌표(현재 binary log 파일 이름과 위치)를 기록합니다.<br><br>2. replica에서, 이전 단계에서 얻은 replication 좌표 값을 [`SOURCE_POS_WAIT()`](https://dev.mysql.com/doc/refman/9.5/en/replication-functions-synchronization.html#function_source-pos-wait) 또는 [`MASTER_POS_WAIT()`](https://dev.mysql.com/doc/refman/9.5/en/replication-functions-synchronization.html#function_master-pos-wait) 함수의 인수로 사용하여 다음 statement를 실행합니다:<br><br>sql
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);

Or from MySQL 8.0.26: mysql> SELECT SOURCE_POS_WAIT('log_name', log_pos); <br><br>[`SELECT`](https://dev.mysql.com/doc/refman/9.5/en/select.html "15.2.13 SELECT Statement") statement는 replica가 지정된 log 파일과 위치에 도달할 때까지 블록됩니다. 이 시점에서 replica는 source와 동기화되며, statement가 반환됩니다.<br><br>3. source에서 다음 statement를 실행하여 source가 다시 update를 처리할 수 있도록 합니다:<br><br>sql mysql> UNLOCK TABLES;

| **A.14.5.** | two-way replication을 설정할 때 어떤 이슈들을 알고 있어야 합니까? |
|  | 현재 MySQL replication은 분산(서버 간) update의 원자성을 보장하기 위한 source와 replica 사이의 어떤 locking 프로토콜도 지원하지 않습니다. 다시 말해, client A가 co-source 1에 update를 수행하고, 그 update가 co-source 2로 전파되기 전에 client B가 co-source 2에 update를 수행하여 client A의 update가 co-source 1에서와는 다르게 동작하게 될 수 있습니다. 따라서, client A의 update가 co-source 2에 도달하면, co-source 2의 테이블은 co-source 1에 있는 것과는 다른 결과를 낳게 되며, co-source 2에서 온 모든 update가 전파된 이후에도 마찬가지입니다. 이는 update가 어떤 순서로 수행되어도 안전하다는 확신이 있거나, client 코드에서 잘못된 순서의 update를 처리하는 방법을 사용하지 않는 한, 두 서버를 two-way replication 관계로 서로 연결해서는 안 된다는 것을 의미합니다.<br><br>또한 two-way replication은 update 측면에서 실제로 성능을 크게 향상시키지 못한다는 점(혹은 전혀 향상시키지 못할 수 있음)을 이해해야 합니다. 각 server는 단일 server가 수행하는 것과 동일한 수의 update를 수행해야 합니다. 유일한 차이점은, 다른 server에서 기원한 update가 하나의 replication 스레드에서 직렬화되기 때문에 lock 경합이 약간 줄어든다는 것입니다. 이러한 이점조차도 네트워크 지연에 의해 상쇄될 수 있습니다. |
| **A.14.6.** | 시스템 성능을 향상하기 위해 replication을 어떻게 사용할 수 있습니까? |
|  | 한 server를 source로 설정하고 모든 write를 해당 server로 보내십시오.<br>그런 다음 예산과 랙 공간이 허용하는 만큼 replica를 구성하고, read를 source와 replica 사이에 분산하십시오. 또한 replica를 시작할 때 [`--skip-innodb`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#option_mysqld_innodb) 옵션을 사용하고, [`low_priority_updates`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_low_priority_updates) 시스템 변수를 활성화하며, [`delay_key_write`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_delay_key_write) 시스템 변수를 `ALL`로 설정하여 replica 측의 속도 향상을 얻을 수 있습니다. 이 경우 replica는 트랜잭션 오버헤드를 제거하여 더 높은 속도를 얻기 위해, `InnoDB` 테이블 대신 비트랜잭션 `MyISAM` 테이블을 사용합니다. |
| **A.14.7.** | 성능 향상을 위한 replication을 사용하기 위해 내 애플리케이션의 client code를 어떻게 준비해야 합니까? |
|  | replication을 스케일아웃 솔루션으로 사용하는 방법에 대한 가이드를 참조하십시오. [Section 19.4.5, “Using Replication for Scale-Out”](https://dev.mysql.com/doc/refman/9.5/en/replication-solutions-scaleout.html "19.4.5 Using Replication for Scale-Out"). |
| **A.14.8.** | 언제, 어느 정도까지 MySQL replication이 시스템 성능을 향상시킬 수 있습니까? |
|  | MySQL replication은 빈번한 read와 드문 write를 처리하는 시스템에서 가장 효과적입니다. 이론적으로, single-source/multiple-replica 구성을 사용하면, 네트워크 대역폭이 소진되거나 update 부하가 증가하여 source가 이를 처리할 수 없는 수준에 도달할 때까지 replica를 추가하여 시스템을 확장할 수 있습니다.<br><br>얼마나 많은 replica를 사용할 수 있는지, 그리고 사이트의 성능을 어느 정도까지 향상시킬 수 있는지를 결정하려면, 쿼리 패턴을 파악하고, 일반적인 source와 일반적인 replica에서 read 및 write 처리량 사이의 관계를 벤치마킹을 통해 경험적으로 결정해야 합니다. 여기의 예시는 가상의 시스템에 대해 replication을 사용했을 때 얻을 수 있는 결과에 대한 상당히 단순화된 계산을 보여 줍니다. `reads`와 `writes`는 각각 초당 read와 write의 수를 나타냅니다.<br><br>시스템 부하가 10% write와 90% read로 구성되어 있고, 벤치마킹을 통해 `reads`가 1200 - 2 \* `writes`라는 것을 알아냈다고 가정해 봅시다. 다시 말해, 시스템은 write가 전혀 없으면 초당 1,200개의 read를 수행할 수 있고, 평균 write는 평균 read보다 두 배 더 느리며, 관계는 선형입니다. source와 각 replica가 동일한 용량을 가지고 있고, source 1대와 replica _`N`_ 대가 있다고 가정합니다. 그러면 각 server(source 또는 replica)에 대해 다음과 같은 관계가 성립합니다:<br><br>`reads` = 1200 - 2 \* `writes`<br>`reads` = 9 \* `writes` / ( _`N`_ \+ 1) (read는 분산되지만, write는 모든 replica로 복제됨)<br><br>9 \* `writes` / ( _`N`_ + 1) + 2 \* `writes` = 1200<br><br>`writes` = 1200 / (2 + 9/( _`N`_ \+ 1))<br><br>마지막 식은 최대 read 속도가 초당 1,200이고, write당 read 비율이 9인 경우, replica가 _`N`_ 개 있을 때의 최대 write 수를 나타냅니다.<br><br>이 분석에서 다음과 같은 결론을 얻을 수 있습니다:<br>- _`N`_ = 0(즉, replication이 없는 경우), 시스템은 초당 약 1200/11 = 109개의 write를 처리할 수 있습니다.<br><br>- _`N`_ = 1이면, 초당 최대 184개의 write를 처리할 수 있습니다.<br><br>- _`N`_ = 8이면, 초당 최대 400개의 write를 처리할 수 있습니다.<br><br>- _`N`_ = 17이면, 초당 최대 480개의 write를 처리할 수 있습니다.<br><br>- 궁극적으로 _`N`_ 이 무한대로 접근함에 따라(그리고 예산은 음의 무한대로 접근함에 따라), 초당 600개의 write에 매우 근접할 수 있으며, 시스템 처리량은 약 5.5배 증가합니다. 그러나, server 8대만으로도 처리량을 거의 4배까지 증가시킬 수 있습니다.<br><br>이 계산은 무한한 네트워크 대역폭을 가정하며, 시스템에서 중요할 수 있는 여러 다른 요인들을 무시합니다. 많은 경우, replica _`N`_ 대를 추가했을 때 시스템에서 실제로 어떤 일이 발생하는지를 정확히 예측할 수 있는, 이와 유사한 계산을 수행하지 못할 수 있습니다. 그러나 다음 질문에 답하는 것은 replication이 시스템의 성능을 향상시킬 수 있는지, 그리고 어느 정도까지 향상시킬 수 있는지를 결정하는 데 도움이 될 것입니다:<br>- 시스템의 read/write 비율은 어떻게 됩니까?<br><br>- read를 줄였을 때 한 server가 얼마나 더 많은 write 부하를 처리할 수 있습니까?<br><br>- 네트워크 상에서 몇 개의 replica까지 수용할 수 있는 대역폭을 보유하고 있습니까? |
| **A.14.9.** | redundancy 또는 고가용성을 제공하기 위해 replication을 어떻게 사용할 수 있습니까? |
|  | redundancy를 구현하는 방식은 전적으로 애플리케이션과 환경에 따라 달라집니다. 고가용성 솔루션(자동 failover 포함)은 능동적인 모니터링과, 원래의 MySQL server에서 replica로 failover를 지원하는 커스텀 스크립트 또는 서드파티 도구가 필요합니다.<br><br>이 과정을 수동으로 처리하려면, 애플리케이션이 새 server와 통신하도록 변경하거나, MySQL server에 대한 DNS를 실패한 server에서 새 server로 조정하여, 실패한 source에서 미리 구성된 replica로 전환할 수 있어야 합니다.<br><br>추가 정보 및 예제 솔루션은 [Section 19.4.8, “Switching Sources During Failover”](https://dev.mysql.com/doc/refman/9.5/en/replication-solutions-switch.html "19.4.8 Switching Sources During Failover")를 참조하십시오. |
| **A.14.10.** | replication source server가 statement-based 또는 row-based binary logging format 중 무엇을 사용하는지 어떻게 알 수 있습니까? |
|  | [`binlog_format`](https://dev.mysql.com/doc/refman/9.5/en/replication-options-binary-log.html#sysvar_binlog_format) 시스템 변수의 값을 확인하십시오:<br><br>```sql
mysql> SHOW VARIABLES LIKE 'binlog_format';
```<br>표시되는 값은 항상 `STATEMENT`, `ROW`, `MIXED` 중 하나입니다. `MIXED` 모드의 경우, 기본적으로 statement-based 로깅이 사용되지만, unsafe statement와 같은 특정 조건에서 replication이 자동으로 row-based 로깅으로 전환됩니다. 이러한 상황이 언제 발생할 수 있는지에 대한 정보는 [Section 7.4.4.3, “Mixed Binary Logging Format”](https://dev.mysql.com/doc/refman/9.5/en/binary-log-mixed.html "7.4.4.3 Mixed Binary Logging Format")을 참조하십시오. |
| **A.14.11.** | replica에 row-based replication을 사용하도록 어떻게 지시합니까? |
|  | replica는 사용할 format을 자동으로 인식합니다. |
| **A.14.12.** | [`GRANT`](https://dev.mysql.com/doc/refman/9.5/en/grant.html "15.7.1.6 GRANT Statement") 및 [`REVOKE`](https://dev.mysql.com/doc/refman/9.5/en/revoke.html "15.7.1.8 REVOKE Statement") statement가 replica 머신으로 복제되지 않도록 하려면 어떻게 해야 합니까? |
|  | server를 시작할 때 [`--replicate-wild-ignore-table=mysql.%`](https://dev.mysql.com/doc/refman/9.5/en/replication-options-replica.html#option_mysqld_replicate-wild-ignore-table) 옵션을 사용하여 `mysql` 데이터베이스의 테이블에 대한 replication을 무시하도록 합니다. |
| **A.14.13.** | 혼합 운영체제(예: source는 Linux에서 실행되고 replica는 macOS와 Windows에서 실행됨)에서 replication이 동작합니까? |
|  | 예. |
| **A.14.14.** | 혼합 하드웨어 아키텍처(예: source는 64-bit 머신에서 실행되고 replica는 32-bit 머신에서 실행됨)에서 replication이 동작합니까? |
|  | 예. |