트위터의 새로운 분산 관리 라이브러리 Gizzard를 소개합니다.

Posted on 2012-03-09 | by gywndi | 7 Comments

Overview

바로 이전 “하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어” 포스팅에서 트위터의 새로운 저장 스토어에 관해서 전반적으로 설명 드렸는데요, 이번에는 그 중 Gizzard에 관해서 심층 분석(?)을 해볼까합니다.

Gizzard는 트위터에서 데이터를 분산 및 복제 관리하기 위한 자체 개발 프레임워크입니다. 클라이언트와 서버 사이에 위치하며 모든 데이터 요청을 처리하는 구조입니다. Gizzard 관련 몇 가지 키워드는 아래와 같습니다.

분산 관리(Sharding)
– 분할(Partitioning)
– 복제(Replication)
부하분산(Load-Balancing)
장애복구(Fail-Over)
멱등성(idempotent) / 가환성(commutative)
– 멱등성 : 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
– 가환성 : 연산의 순서를 바꾸어도 그 결과가 변하지 않는 일

분산 관리(Sharding)이란?

과거에는 서비스 성능 저하가 발생하면 곧바로 해당 서버에 CPU또는 Memory 사이즈를 증설하여 성능 이슈를 해결하였습니다. 하지만, 최근 Web 서비스에서 데이터 사이즈가 급증하여, 더 이상은 서버 성능 고도화만으로는 한계가 있기 때문에, 다수 장비에 데이터를 분산 위치(Data Sharding)하여 데이터를 처리하는 움직임이 일반화되고 있습니다.

분산 처리는 Hadoop, Cassandra, MongoDB 등 NOSQL 분야에서 유행처럼 번져나가고 있으며, 최근에는 기존 RDBMS 를 활용한 분산 관리 기법도 방안이 모색되고 있습니다. 사실 RDBMS의 대표적인 선두 주자인 Oracle도 예전부터 Grid Control 원칙 하에 데이터 분산 관리에 초점을 맞추고 있습니다.

데이터 분산 즉 Data Sharding이란 데이터를 조각으로 관리하자는 것인데, Sharding을 크게 Partitioning(분할) 과 Replication(복제) 두 가지로 나눕니다.

“Partitioning”은 데이터를 조각화하여 다수 서버에 위치하는 것입니다. 물론 각각의 데이터 조각들은 서버에 저장할 수 있도록 충분히 작아야 하고, 데이터를 효과적으로 관리하고 질의가 가능해야 하겠죠.

“Replication”은 여러 서버에 데이터 복사본을 위치하는 것입니다. 이 기술은 각각의 장비에서 동작하고 질의 처리를 할 수 있으며, 데이터 복사본 추가만으로 “READ” 관련 트래픽을 효과적으로 처리할 수 있습니다. 또한 다른 Node 어딘가에는 복사본 데이터가 존재하기 때문에, 특정 데이터에 장애가 발생하거나 유실이 되어도 쉽게 데이터 복구를 할 수 있다는 이점이 있습니다.

Gizzard란 무엇일까요?

Gizzard는 데이터를 분할하여 관리하는 프레임워크입니다. 트위터에서 자체 개발한 또 다른 분산 데이터 저장소이고, 데이터를 쉽게 구성하고 관리하기 위한 미들웨어입니다. 장애 발생에 유연하게 대처할 수 있고, 분산 데이터를 쉽게 관리할 수 있으며, Scala기반으로 만들어져있기 때문에 Config가 쉽다고 합니다.(저는 아직 Scala를 써보지는 않아서.. 써보고 말씀드릴께요.^^)

사실 많은 오픈 소스 분산 데이터 관리 시스템이 많이 나오고는 있지만, 효과적으로 데이터 구조를 정의하고 시스템 장애에 유연하게 대처하거나 데이터 일관성 유지 문제를 해결하는데에는 많은 어려움이 있는 것은 사실입니다.

Gizzard는 트위터에 최적화된 오픈 소스 분산 관리 프레임워크입니다. 물론 앞선 문제를 모든 시스템 상황과 사용자 요구사항을 충족하지는 못하지만, 대부분 데이터 저장소에 존재하는 문제점을 “어느정도” 유연하게 대처합니다.

Gizzard는 데이터를 분할/복제 관리하고, 네트워크 상에서 어플리케이션(PHP/JAVA/Ruby)와 저장소(MySQL/ Lucene/Redis) 사이에 위치합니다.

Partitioning 구성 정보는 데이터 저장 위치를 정의하는 선행 맵핑 테이블에 저장이 됩니다. 그리고 Partition 내부적으로 데이터 조각에 관한 Replication(복제)를 유지하는데, 이것은 “Replicate Tree”로 제어됩니다. 또한 쉬운 Migration과 Load-balancing이 가능하고, 장애 시 유연하게 대처합니다. 멱등성과 가환성 원칙에 의해서 복제 데이터 간 일관성을 유지한다는 특징도 있습니다.

Gizzard를 자세히 살펴봅시다.

Gizzard는 네트워크 서비스 미들웨어입니다.
클라이언트(PHP/Ruby/JAVA)와 데이터 저장소(Partitioning과 Replication으로 구성) 사이에 위치하고 모든 데이터 질의는 오직 Gizzard를 통해서 이루어집니다. 특별한 인스턴스는 형태가 없는 구조이고, JVM위에서 실행되며, 상당히 효율적입니다. 트위터에서 사용하고 있는 Gizzard는 머신 당 초당 10,000 쿼리를 수용할 수 있다고 합니다.

Gizzard는 어떤 종류의 데이터 저장소에도 적용할 수 있습니다.
Gizzard는 애초에 네트워크를 통해서 데이터 저장소에 복제하도록 디자인되었습니다. 그렇기 때문에 데이터 저장소를 SQL Server, Lucene, Redis 등 어떠한 솔루션을 선택해도 큰 문제가 없습니다. 그리고 Gizzard는 모든 쓰기 작업을 “멱등성” 및 “가환성”의 원칙에 의거하여 동작하기 때문에, 저장소 자체에 관한 제약을 걸지는 않습니다. 즉, 저장 시스템 자체에 존재하는 제약 사항에는 여전히 의존한다고 볼 수 있습니다. 예를 들어 RDBMS 에서 Unique 조건이 있는 경우 Gizzard에서는 정상적으로 Writing을 시도하나, 데이터베이스 내부에서는 제약사항에 걸려 데이터 입력이 막히게 됩니다.
Gizzard에 관한 중요한 사실은 순차적으로 데이터가 적용된다는 것을 보장하지 않는다는 것입니다. 그렇기 때문에 쓰기 연산 적용 순서와 관계없이 데이터 일관성을 유지할 수 있도록 설계하는 것이 가장 중요합니다.

Gizzard는 데이터 맵핑 선행 테이블에서 데이터 조각을 관리합니다.
Gizzard는 특정 Shard를 관리를 데이터 범위 관리를 통해서 수행합니다. 선행 테이블의 맵핑 정보 안에는 특정 데이터가 어떤 범위의 구역에 저장이 되어 있는 것에 대한 정보가 숫자 범위로 저장이 되어 있습니다.

Gizzard Partitioning

조금 더 자세하게 풀자면, 특정 데이터에 관한 키 값을 Hash 함수로 돌리고 결과 값을 Gizzard에 전달하면, Gizzard는 해당 데이터가 어떤 구역에 속할 지 숫자 정보를 생성합니다. 이러한 함수는 프로그래밍 가능하기 때문에 사용자 구미에 따라서 지역성 혹은 균형성 면에서 최적화할 수 있습니다.
Gizzard는 “Replication Tree”로 복제 데이터를 관리합니다.
선행 테이블에서 지칭하고 있는 각 데이터 조각들은 물리 혹인 논리적인 형태로 구현될 수 있습니다. 물리적인 형태는 특정 데이터 저장소를 의미하고, 논리적인 형태는 데이터 조각에 관한 Tree를 의미합니다. 트리 안의 각 Branch들은 데이터의 논리적인 변형을 나타내고, 각 Node들은 데이터 저장소를 의미합니다. 예를 들어서 아래와 같이 두 단계의 “Replicating Tree”가 있습니다. 하지만 이것들은 선행 테이블에 지칭을 해서 관리되는 오직 하나의 파티션에 저장될 뿐입니다.

Gizzard Replication

위 그림에서 Replicate라는 Branch 역할은 간단합니다. 단지 자신의 모든 자식 Node에 쓰기만 반복하고, 읽기 균형을 유지한다는 단순한 전략 하에 동작합니다. 데이터 저장소 요구사항에 맞게 추가적인 트랜잭션 혹은 Node 개수 전략을 추가하여 데이터 조각을 재구성할 수 있습니다. 그러나 Gizzard는 기본적으로 Replicating, Write-Only, Read-Only, Blocked 등 몇 가지 전략을 제공합니다.
복제 구성에 관한 세부 형상은 Partition에 따라 다양합니다. 자주 사용되는 데이터에는 더욱 많은 복제를 추가하면 될 것이고, 간헐적으로 사용되는 데이터에는 적은 데이터 복제를 가질 수 있도록 유도하면 됩니다. 한 데이터에 관해서 Primary/Secondary/Tertiary 유지할 수도 있고, 복제를 유지하지 않아도 되는 데이터인 경우에는 Striping Partitioning 구성하여 복제를 하나도 유지하지 않을 수도 있습니다.
Gizzard는 장애 상황에 강한 시스템입니다.
분산 시스템에서 장애 대처는 가장 큰 이슈입니다. 다수 컴퓨터가 동시에 동작하는 구조이기 때문에, 특정 장비에서 예기치 않게 언제든지 장애가 발생할 수 있습니다. Gizzard는 어떠한 장애 상황에서도 유연하게 대처할 수 있도록 디자인되었습니다. 만약 특정 파티션 내에 있는 복제 데이터가 유실되었을 지라도, Gizzard는 읽기/쓰기 요청을 남은 다른 정상적인 복제 데이터로 전환합니다.

Gizzard Failover

위와 같이, 데이터 조각 안의 “특정 복제 데이터 불능”이 발생하면 Gizzard는 최대한 빠르게 다른 정상적인 복제 데이터에 읽기/쓰기 작업을 시도할 것입니다. 그리고 문제가 발생했던 복제 데이터가 정상으로 돌아오면, 변경 이력을 다시 적용을 합니다. 여기서 가장 기본적인 원칙은 트랜잭션 단위 기록을 견고하게 구현한다는 것입니다. 모든 데이터 복제는 비 동기로 이루어지겠지만, 최대한 지연이 없이 진행됩니다.

Gizzard Failover

만약 “모든 복제 데이터 불능 상태”이 빠지면 해당 데이터에만 읽기 요청이 불가할 뿐 다른 정상적인 데이터에는 영향을 미치지 않습니다. 데이터 조각 안의 모든 복제 데이터가 불능에 빠지면, 일단은 “Error Queue”라는 곳에 상태를 기록하고 버퍼에 변경 내용을 쌓습니다. 그리고 파티션 정상화가 되면, 변경된 데이터를 다시 적용합니다. 최종 데이터 일관성은 “멱등성”과 “가환성” 원칙 하에 유지되기 때문에 이전 실패가 적용되기 전에 최근 변경 사항이 먼저 적용된다고 하더라도 결과적으로는 아무런 문제가 없습니다.
Gizzard는 데이터 이관 방안을 제시합니다.
경우에 따라서 데이터를 다른 장비로 데이터 이관 작업이 필요합니다. 로드발란싱을 위한 경우도 있고, 데이터가 적은 장비로 옮기는 경우도 있으며, 하드웨어 장애로 인한 경우도 있습니다. Gizzard에서 논리적인 Shard들을 다른 장비로 이관하는 방식을 설명하겠습니다.

Gizzard Data Migration

Original에서 Target로 이관한다고 가정했을 때, “Replicate Shard”가 Original 와 Target 사이에, “WriteOnly Shard”는 Target 앞에 위치할 것입니다. 그리고 Original 에서 Target으로 데이터가 복사됩니다. WriteOnly Shard는 Target이 사용 가능한 시점까지 유지하며, 전체 데이터가 복사되기 전까지 Target에서는 어떠한 데이터 조회도 불가합니다. 쓰기 작업이 순서에 관계없이 중복으로 발생할 수 있기 때문에 모든 쓰기 작업은 반드시 멱등성 및 가환성 원칙 하에 동작해야 합니다.

데이터 일관성은 멱등성 및 가환성 원칙 하에 유지합니다.
동일 데이터를 동시에 변경하려고 하면 데이터 충돌(Confliction) 이 발생합니다. Gizzard는 데이터는 적용 순서를 보장하지 않기 때문에 모델링 시 반드시 이러한 점을 염두 해야 합니다.

Gizzard Concurrency

높은 가용성과 데이터가 저장되는 순서를 보장하는 것보다 훨씬 간단한 방식입니다. 예를 들어, Rowz에서는 Timestamp를 기준으로 새로운 데이터 변경 요청 여부를 구분합니다.

타 시스템과 비교

GIZZARD Replicate VS MySQL Replication
MySQL Replication과 가장 큰 차이는 Gizzard는 데이터가 저장되는 순서를 보장하지 않는다는 점입니다. 모든 데이터 일관성은 멱등성 및 가환성에 의거하에 보장되며, 일시적인 데이터 불일치는 허용합니다. 물론 일시적인 데이터 불일치를 허용한다는 점은 MySQL Replication도 마찬가지지만, 데이터를 순차적으로 적용한다는 점은 확연하게 다릅니다. 만약 데이터가 순차적으로 수행되다가 실패를 한다면, 그 이후 적용되어야하는 데이터는 실패했던 연산 처리 후 처리될 수 있습니다.

GIZZARD VS Cassandra
트위터에서 사용하고 있는 두 데이터 저장 스토어를 간단하게 비교해보았습니다. Gizzard는 데이터 일관성을 멱등성/가환성에 의거하여 유지합니다. 하지만 Cassandra는 데이터 일관성을 Gossip 통신과 Timestamp로 최신 데이터 결정한다는 가장 큰 차이가 있습니다. Cassandra에서 CorrencyLevel 설정 값에 따라서 동시성 레벨을 조정할 수 있는데, 서비스 특성 및 사용자 요구 사항에 따라서 다양하게 설정할 수 있습니다.

마치며..

최근 이슈가 되는 대용량 데이터 시스템을 보면 공통적인 부분이 데이터 분산 처리입니다. 이제는 과거 기가바이트 단위가 아닌 테라바이트 단위로 데이터가 증가하기 때문에, 분산 처리에 관한 기술은 지속적인 습득이 필요하겠네요. “하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어” 포스팅을 작성을 하면서 많은 생각을 하게 만든 새로운 경험이었습니다.^^

읽어주셔서 감사합니다.

참고자료)
How Twitter Stores 250 Million Tweets A Day Using MySQL
Gizzard: a library for creating distributed datastores

하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어

Posted on 2012-03-08 | by gywndi | 4 Comments

Overview

트위터는 하루 평균 2.5억 건의 트윗을 저장한다고 합니다. 과거 트위터는 “날짜 기준으로 데이터를 분할 관리”하여 저장을 하였고, 대략 3주에 한번씩 서버를 추가하여 Scale-out 하였습니다.

하지만 이 방식에는 다음과 같은 문제가 있었습니다.

부하 분산
고비용
복잡한 프로세스

문제를 해결하기 위해서 트위터에서 New Tweet Store를 고안했다고 합니다.

자, 그럼 기존 문제점부터 차근차근 알아보도록 합시다^^;

Problems

부하 분산(Load Balancing)
날짜 기준으로 데이터를 나눠서 분산 저장 및 관리하기 때문에, 시간이 지날수록 과거 데이터 조회 건수는 비약적으로 낮아집니다. 특히 대부분의 데이터 조회 요청은 현재 시각 기준으로 들어오기 때문에, 데이터 읽기 HOTSPOT이 발생할 수 밖에 없습니다.

Load Balancing Problem

고 비용(Expensive)
데이터는 나날이 쌓여만 가고 이를 위해서는, 매 3주에 걸쳐서 신규 노드를 추가해줘야 합니다. 신규 노드는 서버 한 대가 아닌 마스터/슬레이브로 구성되기 때문에 상당한 비용이 소요됩니다.

Expensive Problem

절차 복잡성(Logistically complicated)
무엇보다 가장 큰 문제는 신규 노드를 추가하는 것이 상당히 어렵다는 것입니다. 매 3주에 걸쳐서 신규 노드를 도입하는 것은 DBA 팀 입장에서는 상당히 부담되고 고된 일이었다고 합니다.

Logistically Complicated Problem

NEW Tweet Store

트위터는 당면한 문제를 해결하기 위해 데이터 분산 도구로는 Gizzard, 데이터 저장소로는 MySQL, 그리고 UUID 생성에는 SnowFlake등으로 새롭게 데이터 분산 재구성 하였습니다.

결과적으로 기존의 과거 날짜 기반의 데이터 축적에서 점진적으로 데이터가 축적되는 효과를 가져왔으며, 3주에 한번씩 고된 업무를 기획하고 이행해야했던 복잡한 절차도 사라졌다고 합니다.

전체적인 트위터 동작에 관한 내용을 하단 그림으로 표현해봅시다.

트윗이 저장되는 저장소를 T-Bird, 보조 인덱스가 저장되는 저장소를 T-flock라고 내부적으로 지칭합니다. 두 시스템 모두 Gizzard 기반으로 이루어져 있으며, Unique ID는 Snowflake로 생성을 합니다.

그러면 New Tweet Store에 적용된 Gizzard, MySQL, Snowflake에 관해서 알아보도록 하겠습니다.

Gizzard in New Tweet Store
Gizzard는 데이터를 분산 및 복제해주는 프레임워크입니다. 클라이언트와 서버 사이에 위치하며 모든 데이터 요청을 처리합니다. 데이터 분산 및 복제 관리 뿐만 아니라 데이터 이관, 장애 대처등 다양한 역할을 수행합니다.

Gizzard Architect

가장 큰 특징은 Write연산에 관해서는 “멱등성” 및 “가환성” 원칙에 의해 적용된다는 점입니다. 기본적으로 Gizzard는 데이터가 저장되는 순서를 보장하지 않습니다. 이 말은 곧 언제든지 예전 Write 연산이 중복되어 다시 수행될 수 있음을 의미하는데, 중복 적용될 지라도 최종적인 데이터 일관성을 보장합니다.

MySQL in New Tweet Store
MySQL이 저장소로 사용됩니다. 물론 Gizzard에서 다른 다양한 저장소를 지원하지만, 트위터에서는 일단 MySQL로 스토리지 엔진은 InnoDB로 선택해서 사용하였습니다. InnoDB 스토리지엔진을 사용한 이유는 행단위 잠금과 트랜잭션을 지원하기 때문데, 다른 스토리지 엔진 대비 데이터가 망가질 확률이 훨씬 적기 때문이 아닐까 추측해 봅니다.각 MySQL 서버에 관한 하드웨어 사양과 데이터 사이즈는 다음과 같습니다.MySQL 관련된 가장 특이한 사항은 정말 단순 데이터 저장 용도로만 사용된다는 점입니다. 일반적으로 MySQL에서 데이터 복구와 이중화를 위해서 Binary Log를 사용하지만, Gizzard와 함께 사용되는 MySQL은 이 기능마저 사용하지 않습니다. 게다가 데이터 복제를 위해서 MySQL 고유의 Replication 기능마저 사용하지 않는다는 점에서, MySQL은 new tweet store에서는 단순한 데이터 저장 수단인 것을 알 수 있었습니다.
그 이유는 Gizzard가 데이터 분산 및 복제 모두를 수행하기 때문입니다.

Snowflake in New Tweet Store
Snowflake는 New Tweet Store에서 고유 아이디 값(Unique ID)을 할당하는 역할을 합니다. 총 8Byte로 구성되어 있으며 시간 순으로 정렬 가능한 값입니다.

Snowflake

Time – 41 bits : millisecond이며 앞으로 최대 69년 사용할 수 있음
Machine id – 10 bits : 1024 대의 머신에 할당 가능
Sequence number – 12 bits : 머신당 같은 millisecond에 4096개 생성 가능

마치며..

작년 Amazon RDS에 서비스를 올리기 위해서 아래와 같이 구상을 한 적이 있습니다. Amazon RDS 상 제약사항을 회피하고자 한 것으로, 기본적으로 공통으로 필요한 정보만 공유하자는 컨셉이었습니다. 변경 로그는 멱등성을 가지며 주기적(1초)으로 각 서비스 DB에서 변경 로그들을 Pulling하여 데이터 일관성을 유지하자는 내용이었습니다.

트위터 사례는 참으로 많은 점을 느끼게 하였습니다. 결과적으로 새롭게 데이터 분산을 재구성하여 점진적인 데이터 증가와 더불어 DBA 팀 자체 업무가 크게 줄었다는 사실에서 깊은 찬사를 보냅니다.

감사합니다.

참고자료)
How Twitter Stores 250 Million Tweets A Day Using MySQL
Gizzard: a library for creating distributed datastores
Snowflake

MySQL Replication 이해(2) – 구성

Posted on 2012-02-10 | by gywndi | 2 Comments

Overview

MySQL Replication 개념에 이어, 이번에는 실 구성에 관한 내용입니다.
각 서버 구성 방법은 “리눅스에 MySQL 설치하기” 편을 참고하시기 바랍니다.

시작에 앞서서 Server_id는 다른 숫자로 설정하세요^^.

Replication 구성은 다음 세 단계를 거쳐서 수행됩니다.

DB 유저 생성
DB 데이터 동기화(셋 중 택 1)
– DB Data File Copy
– MySQL Dump (All Lock)
– Export/Import (Single Transaction)
리플리케이션 시작

1. DB 유저 생성

복제 데이터 전송을 위한 리플리케이션 권한의 DB 유저를 마스터에 생성합니다. 각 슬레이브 IO 쓰레드들은 추가된 DB 유저를 통해 데이터를 받습니다.

[mysql@master] $ mysql -uroot -p비밀번호
 mysql> GRANT REPLICATION SLAVE ON *.*
     -> TO repl IDENTIFIED BY 'repl';

2. DB 데이터 동기화

DB Data File Copy
DB 서버 데몬을 내린 상태에서 데이터 파일 자체를 복사하는 방식입니다.
데이터 파일 복사 과정만 수행하면 되기 때문에 대용량 서버에서 슬레이브 추가 시 유용한 방식입니다.

## MySQL 데몬 중지
[mysql@master] $ /etc/init.d/mysqld stop
[mysql@slave] $ /etc/init.d/mysqld stop

## 슬레이브에 데이터 복사
[mysql@slave] $ scp -r mysql@master:/data/mysql/mysql-data /data/mysql

## 마스터 바이너리 로그 파일 확인
[mysql@master]$ cd /data/mysql/mysql-binlog
[mysql@master ]$ ls -alh
합계 21M
drwxr-xr-x. 2 mysql DBA 4.0K 13:34 .
drwxrwx---. 7 mysql DBA 4.0K 16:34 ..
-rw-rw----. 1 mysql DBA 21M  13:34 mysql-bin.000006
-rw-rw----. 1 mysql DBA 126 13:34 mysql-bin.000007
-rw-rw----. 1 mysql DBA 126  13:34 mysql-bin.index

DB가 재시작되면 기본적으로 새로운 바이너리 로그를 생성됩니다.
* 로그 파일명 : mysql-bin.000007
* 로그 포지션: 106

MySQL Dump (All Lock)
DB 전체에 READ LOCK을 걸고 데이터를 Export하는 방식입니다. 트랜잭션이 지원 안되는 스토리지 엔진이 섞여 있고, 데이터량이 작은 경우 사용하면 되겠습니다. “MySQL Table Lock에 관한 이해”와 같이 뜻하지 않은 Dead Lock이 발생할 수 있습니다.
Lock을 걸고 데이터를 Export 후 슬레이브 장비에서 다시 Import하는 방식입니다. 백업하는 도중에는 데이터 변경 작업은 수행 불가하며, MyISAM의 경우 백업 수행 시간 동안 Dead Lock이 발생할 수 있습니다.
데이터량과 트랜잭션이 작은 경우 사용할 수 있는 방식입니다.

<마스터 세션1> 
## READ LOCK을 걸어서 데이터 변경을 방지합니다.
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)

mysql> show master status\G
*********** 1. row ***********
File: mysql-bin.000008
Position: 456730
1 row in set (0.00 sec)

<마스터 세션2> 
## 다른 세션에서 전체 데이터를 백업합니다.
[mysql@master]$ export -uroot -p비밀번호 --all-databases > /data/mysql/mysql-dump/dump.sql

<마스터 세션1> 
## 원래 세션에서 READ LOCK을 해제합니다.
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

## 슬레이브에 데이터 이관
[mysql@slave] $ scp -r mysql@master:/data/mysql/mysql-dump/dump.sql /data/mysql/mysql-dump
[mysql@slave] $ mysql -uroot -p비밀번호 --force < /data/mysql/mysql-dump/dump.sql

MySQL Dump (Single Transaction)
서비스 중지가 불가하고, 테이블이 트랜잭션을 지원하는 경우에만 사용할 수 있는 방법으로, 트랜잭션 고립 (Isolation)을 특성을 활용하는 방식입니다. 즉, Database 가 InnoDB로만 이루어진 경우 많이 쓰이는 방식이죠.^^

## 시점 데이터 생성
[mysql@master ~]$ export -uroot -p비밀번호 --single-transaction --master-data=2 --all-databases > /data/mysql/mysql-dump/dump.sql

## 슬레이브에 데이터 이관
[mysql@slave] $ scp -r mysql@master:/data/mysql/mysql-dump/dump.sql /data/mysql/mysql-dump
[mysql@slave] $ head -n 22 full_backup.sql | tail -n 1
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql_bin.000008', MASTER_LOG_POS=456730;
[mysql@slave] $ mysql -uroot -p비밀번호 --force < /data/mysql/mysql-dump/dump.sql

3. 리플리케이션 시작

데이터 통신 용도로는 별도 네트워크에 구성해야 NIC 간섭을 최소화할 수 있습니다. 그리고 앞서서 기록을 해놓은 마스터 Binlog 파일과 포지션을 세팅 후 슬레이브 서버를 구동하면 되겠습니다.

## 슬레이브에서 실행
mysql> CHANGE MASTER TO
    -> MASTER_HOST='master-pri',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='repl',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mysql-bin.000008',
    -> MASTER_LOG_POS=456730,
    -> MASTER_CONNECT_RETRY=5;
## 슬레이브 시작
mysql> START SLAVE;

## Slave_IO_Running, Slave_SQL_Running 상태 확인
mysql> show slave status\G
*********************** 1. row ***********************
               Slave_IO_State: Waiting for master to..
                  Master_Host: gisselldb01-pri
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 5
              Master_Log_File: mysql-bin.000008
          Read_Master_Log_Pos: 456730
               Relay_Log_File: mysql-relay.000001
                Relay_Log_Pos: 251
        Relay_Master_Log_File: mysql-bin.000008
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
            ..중략..
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 456730
              Relay_Log_Space: 547
              Until_Condition: None
            ..중략..
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

다음 편에는 실제 활용할 수 있는 분야에 관해서 정리하도록 하겠습니다.
긴 글 읽으시느라 수고하셨어요^^