블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

     본 문서는 MySQL Cluster 버전을 기준으로 한다.

 

MySQL 배포 구조

MySQL 배포 구조는 다음과 같다.



크게 3가지 종류의 노드를 갖는다.

     MySQL Data Node : Data Node는 실제로 데이타를 저장하고, Query 등을 수행하는 역할을 한다.

     MySQL Application Node : 일종의 라우터 역할로, MySQL 클라이언트에 의해서 들어오는 request를 적절한 Data Node로 라우팅 한다.

     MySQL Management Node : 전체 클러스터에 대한 관리 기능을 수행한다.

위의 그림과 같이 Application Node Data Node는 다수가 존재할 수 있다. Application Node는 실제로 데이타를 저장하지 않고 라우팅 하는 역할만 하기 때문에, 부하 분산과 장애시 Fail Over가 가능하고, Data Node 역시 Node간에 데이타를 replication (복제) 하기 때문에, 특정 Node가 장애가 나더라도 전체 서비스에 문제가 없는 Single Point of Failure 가 없는 구조로 고 가용성을 보장한다.

Memcached 기반의 NoSQL

이번 릴리즈에서 재미있는 기능중 하나는 NoSQL이 유행하다 보니, 이 부분에 대한 보강이 이루어졌다.



Memcached NoSQL에 포함시켰는데, memcached MySQL의 맨 앞단에 넣고, MySQL과 통합 시켜 버렸다. Memcached Key/Value 기반의 스토리지 기능을 제공하는데, 메모리 기반이라는 한계로 인하여, 영구적으로 데이타를 저장할 수 없고 또한, 용량적인 한계도 가지고 있었다. 뒷단에 MySQL을 통합함으로써,

     전체 저장 용량을 확장하고

     데이타를 영구적으로 저장할 수 있으며

     MySQL Cluster의 복제 기능을 이용하여, 다른 MySQL과 복제가 가능하게 되서, 데이타 센터내의 복제나, 데이타 센터간의 복제가 가능하게 되었다.

기존에 MySQL을 사용하고 있으면, 운영 경험을 되살려서 쉽게 운영할 수 있으며, memcached NoSQL 계열에서 복잡도가 가장 낮고 사용이 편리하기 때문에 양쪽의 장점을 잘 융합한 형태라고 볼 수 있다.

Multi Site Replication

SNS 등의 영향으로 인하여 시스템이 거대화 되고, 지역적으로 분리된 데이타 센터를 거쳐서 서비스 하는 시나리오 많아짐에 따라 MySQL도 여러 데이타 센터에 걸친 복제(클러스터링)모델을 제공한다.



Multi-Site Replication이라고 하는데, 거의 근 실시간으로 물리적으로 떨어진 데이타 센터간의 데이타 동기화가 가능하다. 물론 네트웍 구간 속도에 대한 상당한 제약 사항을 가지고 있다.

Ÿ  Latency between remote data nodes must not exceed 20 milliseconds

Ÿ  Bandwidth of the network link must be more than 1 Gigabit per Second

데이타 센터간에 고속 네트웍이 없으면 사실상 어려운 설정이다. 그러나 같은 도시 정도의 근거리에 있는 센터라면 충분히 구축이 가능한 복제 모델이다.

 

이외에도,

1) Auto Sharding을 통한 용량 향상

2) Virtualization 환경을 지원 (XenServer와 OracleVM 만 Certi)

3) OnLine 상태에서 정지 없이 Scale out 할 수 있는 기능 (아마도 클라우드 환경에서 Auto Scale Out을 고려 한듯)

과 같이, 기존에 RDBMS가 가지고 있는 한계점을 보완하고, 클라우드 환경에 맞춰진 기능들이 보강된것이 많이 보인다...

물론 검증되고 잘 보강되어야 하겠지만, 이정도면 왠만한 애플리케이션은 NoSQL없이도 충분히 개발이 가능하지 않을까 싶다.


 

MS SQL Replication 아키텍쳐

엔터프라이즈 솔루션/MS-SQL | 2010.04.28 17:44 | Posted by 조대협



MS SQL 데이타 베이스간의 실시간 데이타 복제를 위해서 "Replication"이라는 기능을 제공한다.

보면, Oracle Golden Gate, IBM Info sphere, Quest Shareflex,MySQL geo replication 비슷한 CDC 기능이다.

Replication 방식은 크게 두가지로 나뉘어 지는데, Snapshot replication TransactionalReplication이다.

 

  1. Snapshot Replication

복제 방식은 간단하게 생각하면 Source 데이타 베이스의 내용을 Export해서 Target Import하는 개념으로 생각하면 된다. 데이타 베이스에 대한 복제를 시작하기 전에 초기 데이타를 적재 하거나, 또는 업무가 없을때 데이타를 적재하거나 주기로 변경이 되는 곳에 사용할 있다.

Snapshot Agent 의해서 주기적 또는 스케쥴에 따라서 데이타를 Export하면여 파일로 저장되고 파일은 Distributor 서버로 FTP,윈도우 파일공유,HTTP등을이용하여 전송된다. Distributor 1 이상의 수신 데이타베이스에 데이타를 전송하여 데이타를 반영한다.

 

  1. Transactional Replication

이게 전통적인 CDC 방식이다. Transaction Log Log Reader 캡춰해서 Distributor 통해서 타겟으로 보내는것인데. 재미있는 것중에 하나가 Capture 최소 단위가 하나의 트렌젝션 이하라는 것이다. 최소 단위가 트렌젝션 하나하나를 잡는게 아니라 트렌젝션이 경우 하나의 트렌젝션을 잘라서도 Capture 가능하다.

 

오라클 연동

 

그외에 흥미로운것중 하나가, 송수신 DB 모두 오라클을 지원한다. TransactionalReplication 경우 오라클의 redo 로그를 잡는 것이 아니라 테이블에 트리거를 걸어서 데이타 변경 사항을 Interface table 넣은후, interface 테이블을 읽어서 반영하는 방식이고, 오라클과의 연결은 ADO.NET,OLEDB,ODBC 이용한다

'엔터프라이즈 솔루션 > MS-SQL' 카테고리의 다른 글

MS SQL Replication 아키텍쳐  (0) 2010.04.28
MS SQL 2008 Tutorial  (1) 2010.04.27
http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/comment-page-1/

Cassandra의 센터간 데이타 복제에 대한 자료를 찾다가 발견했는데,
Cassandra 소개 페이지에 들어가보면 inter-data-center 복제가 가능하다고 명시되어 있다.
그런데 위의 링크된 문서를 보니

방식이 Coordinator가 변경된 내용을 실시간으로 복제하는 방식이다. 
문제는 전제 조건이 센터간 Fiber 망을 사용하는 low latency 환경이라야 하는것.. 이래서야 센터간의 망 구축 비용이 더 들테니까는 PASS, 거기에 아직 검증된 사례가 없다.

반면에 HBase의 경우 Golden Gate와 같은 CDC나 MySQL georeplication과 유사한 원리로 Update Log를 Replication하는 방식으로 복제 성능은 Cassandra보다는 느릴지 몰라도 훨씬 합리적인 구조를 가지고 있다.

설치는 Cassandra가 쉽지만 관리 기능이 매우 미약하고, HBase는 관리 UI까지 이미 제공한다. 거기에 HBase는 Hadoop 기반으로 Map&Reduce를 적용하기가 용이하지만, Cassandra는 데이타가 논리적으로 나누어지지 않기 때문에 Map&Reduce를 이용한 데이타 Processing등에는 용이하지 않다.

결과적으로 Local 데이타 Stroage로 간단하게 사용하려면 Cassandra가, 그게 아니라 지역간의 분산구조나 BI와 같은 데이타 Processing이 필요하다면 HBase가 적절할것 같다.

P.S. 어디까지나 개인의견임

s the world’s leading database, Oracle offers a wealth of options to replicate geographically distributed systems.  Each method has its own features and it is the job of the Oracle professional to choose the one that makes sense for their business requirements:
 

  • Data Guard – Data Guard standby databases provide standby databases for failover in system that do not have a high downtime cost.  In a data guard failover, the last redo log must be applied (up to 20 minutes to re-open the standby database), and if the last redo cannot be recovered from the crashed instance, the most recent updates may be lost.
     

  • Multi-Master Replication – See the excellent book for implementing multi-master replication.  Uses advanced queuing to cross-pollinate many databases with updates.  Has an advantage over Data Guard because the standby database can be used for updates, and a disadvantage that replication is not instantaneous and update collisions may occur.
     

  • Oracle Streams – See the comprehensive book on Oracle Streams Technology by Madhu Tumma.  Ready for production use in Oracle 10g, Oracle Streams allows near real-time replication and support for master-to-master replication.  Oracle Streams has no licensing costs (RAC costs extra) and it is less complex to configure than a RAC database.  This disadvantage over RAC is that there is no continuous availability, update collisions may occur, replication is not instant, and application failover is usually done manually. 
     

  • Real Application Clusters – The Cadillac of Oracle continuous availability tools, RAC allows for Transparent Application Failover (TAF) and RAC is de-rigueur for systems with a high cost of downtime and continuous availability on RAC


    원문 : http://www.dba-oracle.com/oracle_tips_multi_master_replication_streams.htm


물리적으로 분리된 위치에서 데이타 SYNC에 대한 솔루션을 research 하던중에 mysql에 대한 이야기가 많이 나온다. Facebook도 master 와 slave center (미국 서부와 동부)의 데이타를 mysql georeplication 을 이용해서 구현한것으로 보인다.


MySQL georeplication의 원리는 위의 그림과 같다. Master node의 변경 사항을 BinLog라는 형태로 저장하여 복제 대상에 전송한후 replay를 하는 방식이다. record & replay 방식인데, binlog는 오라클의 redo 로그와 유사하다. 데이타베이스의 redo 로그 자체를 레코딩해서 전송하는 방식이기 때문에 데이타 복제만이 가능하고 ETL과 같은 변환은 불가능하며, 변경된 부분만 전송하기 때문에, 성능이 빠르다. 그리고 XA(분산 트렌젝션)처리 등이 필요하지 않다.
사실 이 개념은 DR센터(재해복구를 위한 백업센터)로 데이타를 복제하는 아키텍쳐에 많이 사용되어 왔고, IBM의 CDC나 오라클의 Golden Gate가 매우 유사한 아키텍쳐를 사용한다.
그나저나 MySQL사용해본지가 몇년전인데, 정말 좋아졌다.