이 글은 다음의 url을 번역한 것입니다.
http://mysqlhighavailability.com/mysql-group-replication-hello-world/
MySQL Group Replication : Hello World!
The first preview release of MySQL Group Replication, a MySQL plugin that brings multi-master update everywhere to MySQL, is available on labs. This plugin ties together concepts and technologies from distributed systems, such as group communication, with traditional database replication. The ultimate result is a seamlessly distributed and replicated database over a set of MySQL servers cooperating together to keep the replicated state strongly consistent.
이 글은 MySQL Group Replication에 대한 첫번째 리뷰글이다. MySQL Group Replication은 MySQL에서 여러대의 master를 두고 사용할 수 있는 plugin 모듈로 아직은 lab 버젼으로 제공된다. 이 plugin은 기존의 리플리케이션과 함께 사용할 수 있는 것으로 분산 시스템에서 사용할 수 있는 기술이다. 궁극적으로는 함께 구성된 서버군들 사이에 강력한 데이터 일관성을 바탕으로 분산 시스템을 구축하는 것이 이 구성의 목표이다.
Introduction
Before diving into the details of MySQL Group Replication, lets first introduce some background concepts and an overview of how things work. These will provide some context to help understand what this is all about and what are the differences between traditional MySQL replication and the one implemented in this new plugin.
MySQL Group Replication에 대해 자세히 알아보기 전에 먼저 내부적으로 어떻게 동작하는지에 대해 간단히 알아보도록 하자. 이 기능을 이해함으로서 기존의 리플리케이션과 어떻게 다르게 동작하는지 쉽게 이해할 수 있을 것이다.
Primary-Backup Replication
Native MySQL Replication protocol’s nature lies within the realm of a simple Primary-Backup approach to replication. There is a primary (master) and there is one or more backups (slaves). The primary executes transactions, commits them and then they are later (thus asynchronously) sent to the backups to be either re-executed (in statement-based replication) or applied (in row-based replication). It is a shared-nothing system, where all servers have a full copy of the data by default.
기존의 MySQL 리플리케이션 프로토콜은 기본적으로 간단한 Primary-Backup 방법의 영역내에 있다. 즉, 주 서버인 마스터 서버가 있고, 그것에 대한 백업 또는 대기 서버로 슬레이브 서버가 존재하는 것이다. 그래서 Primary 서버가 트랜잭션을 실행하고 커밋을 하면 그 이후에 해당 내역을 슬레이브 서버에 전달하고 그것을 슬레이브 서버에서 재 실행하였다. 즉, 기본적으로 어떤 것도 공유하지 않고, 전체 데이터의 복사본으로 모든 서버가 가지고 있는 구조이다.
There is also a variant implemented as a plugin, called semisync replication, which adds one synchronization step to the protocol, between the primary and the backup, whereas the backup has to inform the primary that it has received the transaction before the primary is allowed to proceed (commit – if the server is configured to wait before commit, or just release the session, if the server is configured to wait after the commit).
You can see a diagram of the protocol (and its semi-synchronous variant) in Figure 1.
semisync 리플리케이션도 있다 이것은 한대의 서버에 대해서만 동기 방식으로 동작하는 구성이다. 즉 한대의 슬레이브 서버만 트랜잭션 정보를 받았다는 메세지를 마스터 서버에 보내면 커밋이 완료되는 구조인것이다.
Group Replication
Group-based replication is a technique that can be used to implement fault-tolerant systems. The replication group is a set of servers that interact with each other through message passing. The communication layer provides a set of guarantees such as atomic message delivery and total ordering of messages. These are powerful primitives and abstractions that allow building more advanced database replication solutions.
Group-based 리플리케이션은 무정지 시스템에 사용할 수 있는 기술이다. replication group은 서버들의 묶음인데, 서로간의 메세지를 주고 받는다. communication layer는 메세지의 전송과 순서를 보장해준다. 이것은 강력한 기본 요소로 한단계 진화된 리플리케이션을 가능하게 가상화된것이다.
MySQL Group Replication builds on such concepts and implements a multi-master update everywhere replication protocol. In a nutshell, a replication group is formed by multiple servers. Each server in the group may execute transactions independently, but a RW transaction only commits after that operation is coordinated within the group. Thence, when a transaction is ready to commit, the server atomically broadcasts the write values (row events) and write set (unique identifiers of the rows that were updated). This establishes a global total order for that transaction. Ultimately, this means that all servers receive the same set of transactions in the same order. As a consequence, all servers apply the same set of changes in the same order, therefore they remain consistent within the group.
MySQL Group Replication은 리플리케이션 프로토콜로 여러 마스터 서버를 사용가능하게 하는 것을 기본 개념으로 하고 있다. 간결하게 말해, replication group은 여러대의 서버로 이루어진다. 그룹의 각 서버들은 각자 독립적으로 트랜잭션이 실행될 수도 있다. 하지만, 쓰기 작업이 있는 트랜잭션의 경우 작업 후에 그룹안에 조정되어진다. 트랜잭션이 커밋을 준비할 때, 각 서버들은 해당 트랜잭션을 다른 서버들에 전달하게 된다. write value와 write set으로 해당 트랜잭션 내용을 전달하게 된다. 그리고 전체적으로 해당 트랜잭션의 순서를 정하게 된다. 즉, 모든 서버들이 같은 순서로 해당 그룹에 들어오는 트랜잭션들을 실행한다는 것을 의미한다. 즉, 모든 서버들은 동일한 데이터를 가지게 된다.
However, there may be conflicts between transactions that execute concurrently at different servers. Such conflicts are detected by inspecting the write sets of two different and concurrent transactions. If two concurrent transactions, that executed at different servers, update the same row, then there is a conflict. The end result is that the transaction that was ordered first will commit on all servers, whereas the other transaction will abort, thus rolled back on the server it had originally executed and dropped by the other servers in the group.
그러나, 다른 서버에서 동작하는 트랜잭션들 사이에 충돌이 발생할 수도 있다. 이런 충돌은 동시에 동작하는 트랜잭션의 write set을 비교함으로서 검출할수 있다. 다른 서버사이에 동시에 같은 row를 수정하는 트랜잭션이 있을 경우 충돌이 발생하게 된다. 충돌을 감지하면 순서를 정해서 첫번째로 오는 트랜잭션은 완료 처리되고, 두번째로 판명된 트랜잭션은 취소된다.
Finally, this is a shared-nothing replication scheme where each server has its own entire copy of the data. Figure 1 depicts MySQL Group Replication protocol and just by comparing it to the MySQL Replication (or even MySQL Semi-synchronous replication) you can already figure out some differences.
마지막으로 이것도 shared-nothing 리플리케이션 구조를 가지고 있다. 즉, 모든 서버가 자신이 가지고 있는 데이터셋이 있다는 것이다. 이 내용을 그림을 통해 확인할 수 있다.
This is, to some extent, similar to the database state machine approach to replication (DBSM) [1].
The MySQL Group Replication Details
MySQL Group replication is an implementation of a multi-master update everywhere replication protocol using group communication. It is implemented as a MySQL plugin and is an extension to the existing replication framework. It uses the binary log caching infrastructure, Global Transaction Identifiers framework and Row-based replication. Apart from this, it requires data to be stored in InnoDB, and also an external component for the messaging and group membership parts, Corosync. Moreover, it implements an automatic and distributed recovery mechanism for servers that are added dynamically to an existing group, so that they are able to catch up and be brought online.
MySQL Group replication은 group commnucation을 사용하여 replication protocol 어디서든지 마스터서버로 실행할 수 있는 구조를 말한다. MySQL plugin으로 사용이 가능하고 기존 리플리케이션에 업그레이드 방법으로 사용이 가능하다. 여기서는 binary log cache 기반인 GTID와 Row-based replication을 사용한다. 이것을 제외히고, MyQL Group Replication은 InnoDB에 저장하는 데이터를 요구한다. 그리고, Corosync라고 하는 컴포넌트를 필요로 하는데, 이것은 메세징과 group membership 부분에서 필요한 컴포넌트이다. 게다가, 서버에서 복구가 가능하게 제공하고, 동적으로 group에 서버를 추가하는 것도 가능하다. 이 모든 것이 온라인 상에서 가능하다.
Self-healing, Elasticity, Redundancy : The Group
In MySQL Group Replication, a set of replicated servers forms a group. A group has a name, which currently takes the form of a UUID. The group is dynamic and servers can leave (either voluntarily or involuntarily) and join it at any time. The group itself will
self-adjust without human intervention, very much autonomically. If a server joins the group, it will automatically bring itself up to date by copying state from an existing server. In fact, state is transferred by means of regular MySQL replication, so there is nothing new or overly complex happening behind the scenes. This means that the overall look and feel does not change much from what MySQL users are used to.
In the event that a server leaves the group, for instance it was taken down for maintenance, the remaining servers shall notice that it has left and will reconfigure the group automatically.
So, the group is elastic so to speak!
MySQL Group Replication에서 리플리케이션에 진행되는 전체 서버 모임을 그룹이라고 한다. 그룹은 하나의 이름을 가지고, 그것은 UUID 의 형태를 가진다. 그룹은 온라인 상에서 언제든지 서버 투입이 가능하고 탈퇴하는 것도 가능하다. 그룹은 사람이 수동으로 하는 것이 아닌 자동적으로 조절하게 할 수 있다. 만약, 그룹에 서버가 추가되면, 자동적으로 이미 투입된 서버에서 데이터를 복사하여 가져가는 것이 가능하다. 사실 state는 일반 리플리케이션에서 하는 것과 같은 것이다. 그래서, 그렇게 새롭거나 복잡한 구조는 아니다. 즉, 전체적인 모양새나 사용하는 방법이 크게 다르지 않다는 것을 의미한다. 그룹에서 서버가 탈퇴할 때에는 유지보수상태인 것처럼 서버를 down하고 나머지 서버들로 다시 그룹을 재설정하며 작업을 진행하게 한다.
Update Everywhere
Since there are no primary servers (masters) for any particular data set, every server in the group is allowed to execute transactions at any time, even transactions that change state (RW transactions).
그룹 안에서 특별한 Primary 서버가 없기 때문에 그룹 안의 모든 서버에서 언제든지 트랜잭션을 실행하는 것이 가능하다.
As explained above, any server may execute a transaction optimistically and later when finishing the transaction, it will coordinate the commit within the group. This coordination serves two purposes: (i) check whether the transaction should commit or not; (ii) and propagate the changes so that other servers can apply the transaction as well if they all decided to commit.
위의 설명에서 어떤 트랜잭션이 실행되는 동안에 다른 트랜잭션이 어떤 서버에서 실행된다면 그룹안에서 해당 트랜잭션에 대한 완료 처리는 조절하게 된다고 설명했다. 이때 두가지 목적으로 작업을 수행한다.
1. 해당 트랜잭션이 커밋되어야 하는지 아닌지 판단한다.
2. 커밋하기로 결정했으면 다른 서버들에도 그 내용이 전파되도록 변경사항을 전파한다.
Since a transaction is sent through an atomic broadcast, either all servers in the group receive the transaction or none will. If they do receive, then they all receive it in the same order w.r.t. other transactions that were sent before. Conflict detection is done by inspecting and comparing write sets of transactions. Thence, they are detected at row level. Conflict resolution follows the first writer wins rule. If t2 precedes t1, both changed the same row on different servers and when t2 executed t1 was not yet applied on t2‘s server, then t1 wins the conflict and t2 shall abort. t2 was attempting to change stale data!
트랜잭션이 다른 서버들에 보내지면, 그룹안의 모든 서버들이 해당 트랜잭션을 적용하던가 모두 적용하지 않던가 둘중의 하나로 동작하게 된다. 만약, 모두 트랜잭션에 대한 내용을 받게 되면, 모든 작업은 모든 서버에 동일한 순서로 실행되어 처리된다. 충돌에 대한 검출은 트랜잭션에 대한 Write Set을 비교 검사하여 판단하게 된다. 즉, row level로 검사한다는 것이다. 충돌이 발생하는 경우 무조건 첫번째 실행자가 처리되는 것을 원칙으로 한다. 즉, 비슷하게 실행된 T1과 T2가 있고, T1이 먼저 실행하였는데 둘 사이에 충돌이 발생한 것이 확인되었으면 T1은 실행되고, T2는 작업이 취소된다.
TIP: If there are transactions that are bound to conflict more often than not, then it is a good practice to start them on the same server. Then they have a chance to synchronize on the local lock manager instead of aborting later in the replication protocol.
만약, 충돌이 많이 발생한다면, 같은 서버에서 트랜잭션이 실행되게 하는것이 좋은 방법이 될 수 있다. 그렇게 되면 local의 lock manager가 조절하여 문제를 피하게 할 수 있다.
Monitoring and Inspecting the System Through Performance_Schema
After introducing the concept of Group and the update everywhere nature of this replication plugin, lets just briefly see how the user can look at what’s happening behind the scenes.
사용자가 간단하게 내부적으로 어떤 일이 진행되는지 확인할 수 있는 방법에 대해 알아보자.
The entire state of the system (including the composition of the group, conflict statistics and service states) can be consulted by querying a set of performance_schema tables. In fact, even though this is a totally distributed replication protocol, the user may monitor it by connecting to just one server in the group, no matter which, and query such tables.
시스템에 대한 전체 상태는 performance_schema 테이블들을 통해 확인해 볼 수 있다. 사실 하나의 서버에만 접근하면 전체 그룹에 대한 상태도 확인하는 것이 가능하다.
For example, the user can connect to one server and check which are the members of the group and their status:
예를 들어 다음과 같이 상태를 조회하여 체크할 수 있다.
node1> select * from performance_schema.replication_connection_nodes\G *************************** 1. row *************************** GROUP_NAME 8a94f357-aab4-11df-86ab-c80aa9429573 NODE_ID 597dbb72-3e2c-11e4-9d9d-ecf4bb227f3b NODE_HOST nightfury NODE_PORT 13000 NODE_STATE ONLINE *************************** 2. row *************************** GROUP_NAME 8a94f357-aab4-11df-86ab-c80aa9429573 NODE_ID 59efb8a1-3e2c-11e4-9d9d-ecf4bb227f3b NODE_HOST nightfury NODE_PORT 13001 NODE_STATE ONLINE *************************** 3. row *************************** GROUP_NAME 8a94f357-aab4-11df-86ab-c80aa9429573 NODE_ID 5a706f6b-3e2c-11e4-9d9d-ecf4bb227f3b NODE_HOST nightfury NODE_PORT 13002 NODE_STATE RECOVERING
The user can also connect to a server and find out statistics about the replication protocol. For instance, how many messages were sent or the maximum size of the messages sent:
서버들간에 메세지를 얼만큼 주고 받았는지 확인하는 것도 가능하다.
node1 > SELECT * from performance_schema.replication_connection_status \G *************************** 1. row *************************** GROUP_NAME 8a94f357-aab4-11df-86ab-c80aa9429573 SOURCE_UUID 8a94f357-aab4-11df-86ab-c80aa9429573 THREAD_ID NULL SERVICE_STATE ON RECEIVED_TRANSACTION_SET LAST_ERROR_NUMBER 0 LAST_ERROR_MESSAGE LAST_ERROR_TIMESTAMP 0000-00-00 00:00:00 TOTAL_MESSAGES_RECEIVED 10 TOTAL_MESSAGES_SENT 2 TOTAL_BYTES_RECEIVED 782 TOTAL_BYTES_SENT 374 LAST_MESSAGE_TIMESTAMP 2014-09-17 10:04:54 MAX_MESSAGE_LENGTH 323 MIN_MESSAGE_LENGTH 51 VIEW_ID 50 NUMBER_OF_NODES 4
Sneak Peek at the Architecture
Lets look briefly at the architecture of the system. A lot of the existing infrastructure has been reused. Some parts of the code were considerably refactored or modularized and interfaces were created that the plugin can use.
Group 리플리케이션에 대한 구조는 다음과 같다. 기존의 내부 구조를 많이 재사용하였다.
The plugin itself is very much integrated with the server and the current replication layer. It makes use of the binary log caches, slave applier infrastructure, global transaction identifiers, relay log infrastructure, existing replication threads, etc. So the look and
feel to the MySQL end user is not that different from what he is used to. Nonetheless, this had to be very well played together, through proper interfaces, so that modularization of the many components that form this plugin could take place and everything fit together in the end. Figure 2 presents a block diagram depicting the architecture of MySQL Group Replication.
플러그인 자체는 현재 서버와 복제 계층을 매우 통합한 모양새이다. binary log caches, slave applier infrastructure, global transaction identifiers, relay log infrastructure, replication thread 를 사용하게 구성되어있다. 그래서 사용자는 크게 다른점을 느끼기 어려울수도 있다. 많은 내부 컴포넌트드를 모듈화 하고 그것을 플러그인 형태로 구현함으로서 사용하기에 불편함없이 구성하였다. Figure2는 그런 구성을 보여주고 있다.
Starting from the top, there is a set of APIs that rule how the plugin interacts with the server. There are interfaces to pass information from the server to the plugin and vice versa. Such interfaces isolate the server core from the plugin and are mostly hooks placed in the transaction execution pipeline. In one direction, from server to the plugin, we have notifications such as server is starting, server is recovering, server is ready to accept connections, server is about to commit a transaction, … In the other direction, there is the plugin instructing the server to commit/abort ongoing transactions, queue transactions in the relay-log, etc.
그림의 가장 최 상단에서 서버와 통신하는 API 집단이 있다. 즉, 서버에서 플러그 인으로 아니면 그 반대로 통신하는 인터페이스이기도하다. 이러한 인터페이스는 플러그인으로 부터 서버 코어를 분리시키고, the transaction execution 실행을 컨트롤 하게 된다. 서버에서 플러그인으로는 다음과 같은 정보들이 전달된다. " server is starting, server is recovering, server is ready to accept connections, server is about to commit a transaction" 반대 방향으로는 "commit/abort ongoing transactions, queue transactions in the relay-log"와 같은 메세지들이 전송된다.
Below the API block, there is a set of components that react when a notification is routed to them. The capture component is responsible for keeping track of context related to transactions that are executing. The applier component is responsible for installing remote transactions into the database. The recovery component manages distributed recovery and is responsible for getting a server up to date or even donate state to new servers in the group.
API 블럭아래는 어떤 작업내용을 전송할 때 재실행하는 컴포넌트들의 set이 있다.capture 컴포넌트는 현재 실행하는 트랜잭션에 딸린 context를 추적하고 유지하는 것을 책임진다. Applier 컴포넌트는 데이터베이스 안에서 리모트 트랜잭션을 실행하는 것을 책임진다. recovery 컴포넌트는 분산된 복구 작업을 관리하고, 그룹안에 새롭게 들어온 서버를 구성하는데에 책임이 있다.
Continuing down the stack, the replication protocol module contains the specific logics of the replication protocol. It handles conflict detection, receives and propagates transactions to the group.
그 아래에 있는 replication protocol은 리플리케이션 프로토콜에 대한 로직을 가지고 있는 부분이다. 여기에서 충돌을 검출하여 조치를 취히고, 그룹에 적용해야 하는 트랜잭션을 전파하는 작업을 한다.
Finally, the last orange box, is the Group Communication API. It is a high level API abstracting the messaging toolkit. Thence it decouples the messaging layer from the rest of the plugin. As mentioned before, the MySQL Group Replication plugin contains a binding of such interface to corosync, thus there is an implicit mapping of our interface into corosync’s own client API.
마지막으로 Group Communication API 부분은 toolkit에 메세지를 보내는데 사용할는 추상화된 하이 레벨의 API 집단이다. 즉, 플러그 인의 메세지 레이어인것이다. 전에 MySQL Group Replication Plugin은 corosync 와 인터페이스를 통해 통신한다고 이야기 했었는데 바로 여기에서 corosync의 client API를 포함하여 통신하게 된다.
The purple boxes are components external to the plugin. Since they make up the rest of the stack and are shown here for completion.
This architecture has some similarities to existing architectures, noticeable with the one proposed by the project Open Replication of Databases
(GORDA) [2].
그 아래에 있는 자주색 박수들에 있는 컴포넌트들은 플러그인 외부에 있는 컴포넌트 들이다. 하지만, 구성에 대한 완성을 보여주기 위해 포함하여 표시하였다.
High-Availability With MySQL Group Replication
Typically, fault-tolerant systems resort to redundancy, using replication, to copy the system state throughout a set of servers that may fail independently. Consequently, even if some of the servers fail but not all, the system is still available (may be degraded, performance or scalability-wise, but still available).
일반적으로 무정지 시스템은 독립적으로 문제가 될 수 있는 서버들의 묶음을 통해 시스템 상태를 복사하여 중복성에 의존하고 구성한다. 따라서 전체 묶음 중 하나의 시스템에 문제가 발생해도 시스템 전체적으로 봤을 때 사용에는 문제가 없다.
MySQL Group Replication fits very nicely into this classification. Server failures are isolated and independent. They are tracked by a group membership service which relies on a distributed failure detector that is able to figure out which are the servers that go down. There is a distributed recovery procedure to ensure that servers get up to date automatically when they join the group. There is no need for server fail-over. Given its multi-master update everywhere nature, not even updates are blocked in the event of a single server failure. Thus, MySQL Group Replication, guarantees that the database service is continuously up.
MySQL Group Replication은 이런 분류안에서도 매우 쉽게 사용할 수 있는 구조이다. 서버는 분리되어 있고 독립적이러 장애가 발생해도 문제가 되지 않는다. MySQL Group Replication은 group membership service에 의해 서로의 문제를 추적하여 조치를 취할 수 있다. 그리고 그룹에 추가될때 자동적으로 해당 서버가 최신의 정보를 가질 수 있게 분산 복구하는 절차를 가지고 있다. 그래서 서버를 중지하는 것이 필요가 없다. 멀티 마스터로 사용되는 구조이기 때문에 한대의 서버에서 실패가 발생해도 작업은 블럭된다. 그래서, MySQL Group Replication은 모든 서버가 같은 데이터를 가질수 있게 보장된다.
Mind you that even if the database service is up, in the event of a server crash, those clients connected to it must be redirected/failed over to a different server. This is not something this plugin tries to resolve. The connector, load balancer, or even MySQL Fabric are the more suitable to deal with this issue.
데이터베이스 서비스를 오픈한 후에 서버에 문제가 발생하게 되면 클라이언트들은 다른 서버에 재접속을 해야 한다. 이와 같은 경우에 플러그인은 어떤 해결도 해주지 못한다. 만약 Fabric이나 로드 발란서와 같은 것을 사용한다면 이와 같은 문제를 좀 더 쉽게 처리할 수 있을 것이다.
Moreover, adding servers to the group requires at least one round of the distributed recovery procedure to run. This includes a state transfer operation and synchronization. Thence, it is a good practice that when adding a server to the group, one provisions the server beforehand. This makes recovery much faster, since only the missing state is transferred.
추가적으로 그룹에 서버를 추가할 때 적어도 한대의 서버는 분산 복구 작업(전송작업과 동기화 작업)에 투입되어야 한다. 즉, 이것은 그룹에 서버를 추가하는 작업에 최소한의 한대는 여유분이 있어야 한다는 것이다. 그래야 복구 작업이 더 빨리 끝나게 된다.
In a nutshell, MySQL Group Replication alone provides a highly available, highly elastic, dependable MySQL service.
Examples of Use Case Scenarios
There are use cases where MySQL Group Replication comes in handy:
- Elastic Replication – Environments that require a very fluid replication infrastructure, where the number of servers has to grow or shrink dynamically and with as little pain as possible. For instance, database services for the cloud.
- Highly Available Shards – Sharding is a popular approach to achieve write scale-out. Users can use MySQL Group Replication to implement highly available shards. Each shard can map into a Replication Group.
- Alternative to Master-Slave replication – It may be that a singe master server makes it a single point of contention. Writing to an entire group may prove more scalable under certain circumstances.
Apart from these scenarios, the user may just choose to deploy MySQL Group Replication for the sake of the automation alone that is built into the replication protocol.
Where to Go From Here?
Expect a series of blog posts with more technical details about this plugin and also more details about how the user shall make the best out of this new plugin.
In the meantime, you can go and try this new plugin by downloading from labs.mysql.com the package: mysql-5.7.5-labs-group-replication.
Limitations
Let me also highlight known limitations and extra features:
- Bugs – It is very likely that people find bugs. In fact, if you do so, we kindly ask you to let us know about them. File bugs on the bugs db.
- DDL Support – The current preview has limited DDL support. If DDL is executed concurrently with DML there will be problems. DDL에 제약사항이 있다. 만약, DML과 동시에 DDL을 한다면 문제가 발생할 수 있다.
- Supported Platforms – The plugin is limited to the platforms that corosync supports.corosync 를 지원하는 플랫폼에서만 사용할 수 있다.
Very Special Acknowledgement
We would like to acknowledge and thank the contribution from our dear late friend and colleague Astha Pareek. We miss her kindness and cheerful mood everyday.
'MySQL HA & DR' 카테고리의 다른 글
| MySQL Group Replication: Distributed Recovery behind the scenes (번역) (0) | 2015.03.23 |
|---|---|
| Group Communication behind the scenes(번역본) (0) | 2015.03.19 |