그렇다면 MySQL 복제 란 무엇입니까?
복제는 소스 환경의 트랜잭션을 기반으로 한 위치에만 저장되는 대신 정보가 다른 환경에 복사되고 의도적으로 채워지는 것을 보장합니다.
이를 위해서는 인프라에서 보조 서버를 사용하여 읽기 또는 다른 관리 솔루션을 사용하는 것이 좋습니다. 아래 다이어그램은 MySQL 복제 환경의 예를 보여줍니다.
좋습니다, 그러나 MySQL에서 어떤 선택을해야합니까?
실제로 몇 가지 다른 선택이 있습니다.
표준 비동기 복제
비동기 복제는 트랜잭션이 로컬 환경에서 완전히 완료되고 복제 슬레이브 자체의 영향을받지 않음을 의미합니다.
변경이 완료되면 마스터는 이진 로그를 데이터 수정 또는 실제 명령문 (행 기반 복제 또는 명령문 기반 복제의 차이 – 나중에 자세히 설명)으로 채 웁니다. 이 덤프 스레드는 이진 로그를 읽고 슬레이브 IO 스레드로 보냅니다. 슬레이브는 IO 스레드를 사용하여 자체 전처리 큐 (릴레이 로그라고 함)에 배치합니다.
슬레이브는 SQL 스레드를 사용하여 슬레이브 데이터베이스에서 각 변경 사항을 실행합니다.
반 동기식 복제
반 동기식 복제는 슬레이브와 마스터가 서로 통신하여 트랜잭션의 올바른 전송을 보장 함을 의미합니다. 마스터는 binlog 중 하나만 채우고 슬레이브 중 하나가 트랜잭션이 슬레이브의 릴레이 로그 중 하나에 올바르게 배치되었다는 확인을 제공하면 세션을 계속합니다.
반 동기식 복제는 트랜잭션이 올바르게 복사되도록 보장하지만 슬레이브에서 커밋이 실제로 수행되는 것은 아닙니다.
세미 싱크 복제는 슬레이브 중 하나 이상이 트랜잭션 수신을 ACK (또는 시간 초과)에 도달 할 때까지 마스터가 특정 세션에서 트랜잭션 처리를 계속 대기하도록합니다. 반 동기화는 추가 데이터 무결성을 허용하므로 비동기 복제와 다릅니다.
세미 동기식 복제는 슬레이브에서 실제 ACK의 왕복을 기다려야하므로 성능에 영향을 미칩니다.
그룹 복제
이것은 MySQL Community Edition 5.7에 도입 된 새로운 개념이며, MySQL 5.7.17에서 GA되었습니다. 가상 동기식 복제를위한 다소 새로운 플러그인 빌드입니다.
트랜잭션이 노드에서 실행될 때마다 플러그인은 클라이언트에게 다시 완료되기 전에 다른 노드와 합의를 시도합니다. 솔루션은 표준 MySQL 복제와는 완전히 다른 개념이지만 binlog를 사용한 로그 이벤트 생성 및 처리를 기반으로합니다.
아래는 그룹 복제의 아키텍처 예입니다.
그룹 복제에 관심이있는 경우 다음 블로그 게시물을 읽으십시오.
- http://mysqlhighavailability.com/mysql-group-replication-its-in-5-7-17-ga/
- http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/
2017 년 4 월 산타 클라라에서 열리는 퍼 코나 라이브 오픈 소스 데이터베이스 컨퍼런스 에서 튜토리얼이 진행됩니다 .
Percona XtraDB 클러스터 / Galera 클러스터
다른 노드에 정보를 복제 할 수있는 또 다른 솔루션은 Percona XtraDB Cluster 입니다. 이 솔루션은 일관성 제공에 중점을 두며 인증 프로세스를 사용하여 트랜잭션이 충돌을 피하고 올바르게 수행되도록합니다.
이 경우 클러스터 솔루션에 대해 이야기하고 있습니다. 각 환경에는 동일한 데이터가 적용되며 일관성을 보장하기 위해 노드간에 통신이 있습니다.
Percona XtraDB 클러스터에는 여러 구성 요소가 있습니다.
- MySQL 용 Percona 서버
- 실행중인 클러스터의 스냅 샷을 수행하기위한 Percona XtraBackup (노드를 복구 또는 추가하는 경우).
- wsrep 패치 / Galera 라이브러리
이 솔루션은 사실상 동기식이며 그룹 복제와 비슷합니다. 그러나 다중 마스터 복제를 사용할 수도 있습니다. Percona XtraDB Cluster와 같은 솔루션은 데이터베이스 인프라의 가용성을 향상시키는 구성 요소입니다.
Percona XtraDB 클러스터에 대한 자습서는 2017 년 4 월 산타 클라라 (Santa Clara) 의 Percona Live 오픈 소스 데이터베이스 컨퍼런스 에서 제공됩니다.
행 기반 복제 대. 명령문 기반 복제
함께 문 기반 복제 , SQL 쿼리 자체는 바이너리 로그에 기록됩니다. 예를 들어, 정확히 동일한 INSERT / UPDATE / DELETE 문이 슬레이브에 의해 실행됩니다.
이 시스템에는 많은 장점과 단점이 있습니다.
- 실제 명령문이 이진 로그에 기록되므로 데이터베이스 감사가 훨씬 쉽습니다.
- 유선으로 전송되는 데이터가 적습니다.
- 비 결정적 쿼리는 슬레이브 환경에서 실제 혼란을 야기 할 수 있습니다
- 명령문 기반 복제를 사용하는 일부 쿼리 (SELECT 기반 INSERT)와 함께 성능이 저하 될 수 있습니다.
- SQL 최적화 및 실행으로 인해 명령문 기반 복제 속도가 느려짐
행 기반 복제 는 MySQL 5.7.7부터 기본적으로 선택되며 많은 장점이 있습니다. 행 변경 사항은 이진 로그에 기록되며 컨텍스트 정보가 필요하지 않습니다. 이는 비 결정적 쿼리의 영향을 제거합니다.
몇 가지 추가 장점은 다음과 같습니다.
- 행 변경이 거의없는 높은 동시성 쿼리로 성능 향상
- 중요한 데이터 일관성 개선
물론 몇 가지 단점이 있습니다.
- 많은 수의 행을 수정하는 쿼리가있는 경우 네트워크 트래픽이 훨씬 커질 수 있습니다.
- 데이터베이스의 변경 사항을 감사하기가 더 어렵습니다.
- 경우에 따라 행 기반 복제가 명령문 기반 복제보다 느릴 수 있습니다.
복제에 대한 오해
복제는 클러스터입니다.
표준 비동기식 복제는 동기식 클러스터가 아닙니다. 표준 및 반 동기식 복제는 환경이 동일한 데이터 세트를 제공한다고 보장하지 않습니다. 이는 모든 서버가 실제로 각 변경 사항을 처리해야하는 Percona XtraDB 클러스터를 사용할 때 다릅니다. 그렇지 않은 경우 영향을받는 노드가 클러스터에서 제거됩니다. 비동기식 복제에는이 오류 방지 기능이 없습니다. 일관성이없는 상태에서 읽기를 계속 받아들입니다.
복제가 완벽하게 들리므로 수동 장애 조치 솔루션으로 사용할 수 있습니다.
이론적으로 환경은 비슷해야합니다. 그러나 데이터 전송의 효율성과 일관성에 영향을주는 많은 매개 변수가 있습니다. 비동기 복제를 사용하는 한 트랜잭션이 올바르게 수행되었다는 보장은 없습니다. 구성의 내구성을 향상시켜이를 피할 수 있지만 성능 비용이 발생합니다. pt - table - checksum 도구를 사용하여 마스터 및 슬레이브의 일관성을 확인할 수 있습니다 .
복제가 있으므로 실제로 백업이 필요하지 않습니다.
복제는 데이터 세트의 액세스 가능한 사본 (예 :보고 문제, 읽기 쿼리, 백업 생성)을 보유 할 수있는 훌륭한 솔루션입니다. 그러나 이것은 백업 솔루션이 아닙니다. 오프 사이트 백업을 사용하면 중대한 재난, 사용자 오류 또는 기타 이유로 인해 환경을 재 구축 할 수있는 확실성이 제공됩니다 ( Bobby Tables comic을 기억하십시오 ). 어떤 사람들은 지연된 노예를 사용합니다. 그러나 지연된 슬레이브라도 적절한 재해 복구 절차를 대체하지는 않습니다.
복제가 있으므로 환경에서 트랜잭션의로드 균형을 조정합니다.
동일한 데이터 세트로 실행되는 보조 인스턴스를 사용하여 환경의 가용성을 잠재적으로 개선했지만 읽기 쿼리를 슬레이브로 향하고 쓰기 쿼리를 마스터로 향하게해야 할 수도 있습니다. 프록시 도구를 사용하거나 자신의 응용 프로그램에서이 기능을 정의 할 수 있습니다.
복제하면 마스터 속도가 크게 느려집니다.
복제는 마스터에 약간의 성능 영향 만 미칩니다. Peter Zaitsev는 여기에 흥미로운 게시물이 있습니다. 여기 에는 노예가 주인에게 미칠 잠재적 영향에 대해 설명합니다. 바이너리 로그에 쓰면 성능이 저하 될 수 있습니다. 특히 여러 개의 작은 트랜잭션이 여러 슬레이브에 의해 덤프되고 수신되는 경우 특히 그렇습니다.
물론 실제 마스터 및 슬레이브 설정의 성능에 영향을 줄 수있는 많은 다른 매개 변수가 있습니다.