주문이 이뤄지고,결제가 이뤄지는 서비스를 운용하면서 가장 중요한 것이 가맹점이 볼 수 있는 시각화된 데이터입니다.
이러한 통계 데이터를 실제 운용되는 Source DB 에서 바로 가져오는 것은 상당한 무리가 갈 수 있습니다.
특히, 한 테이블에서 바로 가져오는 것이 아니라 여러 테이블을 조인하여 조합 후 가져오는 형태라면 더더욱 부하가 발생합니다.
이러한 문제를 해결하기 위한 방법 중 하나가 바로 Replication
입니다.
Mysql 공홈에서는 Replication
에 대해서 다음과 같이 설명하고 있습니다.
Replication enables data from one MySQL database server (known as a source)
to be copied to one or more MySQL database servers (known as replicas).
Replication is asynchronous by default; replicas do not need to be connected
permanently to receive updates from a source. Depending on the configuration,
you can replicate all databases, selected databases, or even selected tables
within a database.
설명드리면 Replication
은 하나 또는 하나 이상의 MySQL database 서버에 특정 MySQL database 서버를 복사할 수 있는 기능입니다. 기본적으로는 asynchronous(비동기) 로 실행이 되며, 영구적으로 연결되어 수정되지 않아도 됩니다. 또한, 모든 databases 단위가 아닌 특정 database 나 심지어 table 단위로도 가능합니다.
이처럼 Source database
를 기점으로 똑같은 Replica database
를 가지고 싶은 경우 주로 사용하게 됩니다.
장점
Replication 의 장점은 다음과 같습니다.
Scale-out solucations
- 부하를 여러개의 replicas 에게 분산시켜줍니다. 모든 writes 와 update 는 source server 로 부터 발생시키고, reads 는 replicas 로부터 발생시킵니다. 이러한 모델은 wrtie 와 read 를 나눔으로 써 성능을 극대화 시켜줍니다.
Data security
- replica 는 replication process 를 중단 시킬 수 있기 때문에 원본의 손상없이 복제를 진행할 수 있습니다.
Analytics
- live data 는 server source 에서 생성되어지고, 통계를 위한 데이터는 live data 에 영향을 끼치지 않고 replica 에서 생성할 수 있습니다.
Long-distance data distribution
- 원격의 사이트에 사용하기 위한 데이터를 본 server 에 별다른 접속 없이 복사할 수 있습니다.
Replication method 종류
MySQL 은 Replication 을 위한 다른 방법들을 제공합니다.
전통적인 방법으로는 source`s binaly log 를 기반으로한 replicating event 입니다.
이 방법은 log files 와 source 와 replica 사이에 synchronize 한 순간을 필요로 합니다.
source 가 Data 가 create 나 modify 가 되는 순간 binary log 를 작성하게 되며, replica 는 이러한 binaly log 를 읽어 복제하는 방식입니다.
장점으로는 Source 는 create 나 modify 되었을 때 binary log 를 쓰기면 하면 되고, replica 는 이러한 binary log 를 읽어 가기만 하면 되기 때문에 replica 가 다량인 경우 부하가 적을 수 있습니다.
단점으로는 binary log 를 쓰는 시점과 읽는 시점에 텀이 생길 수 있기 때문에 consistency
를 보장할 수 없습니다.
또한, binary log 를 생성하기 때문에 binary log 를 위한 메모리가 필요하게 됩니다.
이러한 consitency
를 보장하기 위해서 새롭게 제공하는 방법은 Global Transcation Identifiers(GTIDs)
입니다.
GTIDs 는 trancsactional 을 기반으로 운용되며, log files 나 이러한 files 를 위한 읽어가는 기능을 필요로 하지 않습니다.
GTIDs
는 Source 를 적용하는 모든 transcations commited 을 기반으로 replica 에 적용되기 때문에 Consistency
를 보장할 수 있습니다.
GTIDs 에 대한 자세한 설명은
https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html
를 참고 부탁드립니다.
Replication 의 synchronization 종류
Replication 은 다른 synchronization type
을 제공합니다.
우선 기본적은 type 은 하나의 source server 로 운용되는 형태로 one-way asynchronous
방법이며, 하나 또는 여러개의 server 가 replicas 로 운용되는 구조입니다.
이러한 방법은 NDB Cluster 의 특색인 synchronous replication
과 대조적인 방법입니다.
MySQL 8.0 에서는 asynchronous replication 을 기반인 semisynchronous replication
을 지지합니다.
simisynchronous replication
은 session 이 transaction 의 log event 가 받았다는 것을 인지하고 돌아오기 전에 commit 이 source block 에 실행되는 구조입니다.
자세한 내용은 https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html 에서 참고 부탁드립니다.
Format
MySQL 에서는 binary log 를 쓰는 2가지의 핵심 type 을 제공합니다.
전체적인 SQL 문을 작성하는Statement Based Replication(SBR)
과 오직 변화된 row 만 기록하는 Row Based Replication(RBR)
입니다.
또한 두가지를 섞어서 Mixed Based Replicatoin(MBR)
로 사용할 수 있습니다.
(MySQL 에서는 GTIDs 를 사용할 땐, SBR 을 사용하면 transcation 에 부하가 생길 수 있기 때문에 RBR 을 권장합니다.)
결론
MySQL 8.0 에서 제공하는 Replication 의 종류와 기능에 대해서 알아봤습니다.
앞에서 설명한 기능 외에도 부가적인 설정이나 기능들을 MySQL 공식 사이트에서 제공하고 있습니다.
통계 데이터를 추출하거나, Source server 에 대한 부하를 줄이거나, 혹시 모르는 상황을 대비하기 위한 방법으로 Replication 을 많이 사용하는데 상황과 필요성에 맞게 Replicatoin 을 이해하고 사용하면 더욱 효율적으로 사용할 수 있습니다.
참고
- https://dev.mysql.com/doc/refman/8.0/en/replication.html
- https://sarc.io/index.php/mariadb/1770-mysql-multi-source-replication
'MYSQL' 카테고리의 다른 글
[MYSQL] TEMPORARY TABLE 이란 (1) | 2019.11.15 |
---|