1901;팔리면 1656;문Ȣ16;1648; 맙시다. 소1473;한 NJ13;변 댓글1012; 삭1228;Ȣ16;lj16;,148; ǥ12;-124;러운 1068; 1077;니다 
idc 에 불났1012;ǐ12; 최대한 빠른시간내 복구 ( 무1473;단 목표 ) 를 Ȣ16;고 1080;습니다. ( 데1060;터 용량1060; 많아서 클라우드lj16; 1228;외 합니다. )
서/196; 다른 1648;역 ( 가산ᇼ1; - 서초ᇼ1; ) 1032; idc를 1060;용1473; 1060;구요.
ᇼ1;시 0176;포나 디비 리플리케1060;션1008; 간단7176; 설1221;Ȣ16;고 넘Ǻ12;갔lj16;데 첨ǥ12;파1068; ᇼ1;기화가 문1228;1077;니다. 
1차/196; glusterfs geo-replication /196; 구축1012; 했더니
1060;,172; 양0169;향1060; 아니라 단0169;향 1077;니다. 슬래1060;브가 read-only /196; 마운트가 .121;니다..
그래서 마스터 idc 1109;애시 사람1032; 수1089;업1060; 필요Ȣ16;고 다시 또 마스터 서버 복구시 번,144;ǘ13;,172; 1089;업1012; 또 해야 합니다...
그런데 geo-replication 1089;ᇼ1;0169;식1012; 유심7176; 살6196;보고 테스트도 1328; 해봤더니
슬래1060;브에서 read-only off 상태 (rw모드)/196; 그냥 운영1060; .104;네요.
Ȣ16;1648;만 NJ17;연Ȣ16;,172;도 슬래1060;브 수1221;사항1008; 마스터/196; 0152;영1060; 안.104;기에
ᕬ1;시나 Ȣ16;고 슬래1060;브도 그냥 마스터처/100; 똑같1060; 설1221;Ȣ16;여 결과1201;1004;/196; 양0169;향 ᇼ1;기화를 해봤습니다.
gfs1 (마스터), gfs2 (슬래1060;브) 각각 glusterfs volume 1008; distvol1008; 만들Ǻ12; .160;고
아래와 같1060; 설1221;1012; 했더니 너무나 1096; .121;니다 ??!!
gfs1에서
mount.glusterfs gfs1:/distvol /mnt/gfs1_distvol/
gluster system:: execute gsec_create
gluster volume geo-replication distvol gfs2::distvol create push-pem force
gluster volume geo-replication distvol gfs2::distvol start
gluster volume set distvol read-only off
gfs2에서
mount.glusterfs gfs2:/distvol /mnt/gfs2_distvol/
gluster system:: execute gsec_create
gluster volume geo-replication distvol gfs1::distvol create push-pem force
gluster volume geo-replication distvol gfs1::distvol start
gluster volume set distvol read-only off
같1008; 파1068; 생성1060;나 수1221;해서 충돌시켜도 나1473;에 생성한 파1068;/196; 1096; 덮Ǻ12;Ǹ16;네요.
1060;리1200;리 테스트 해봐도 아무 문1228;가 없Ǻ12; 보여서 1060;/111;,172; 운영해봐도 ƻ16;찮1008;,152;까 dz10;Ǻ12;서
양0169;향 geo-replication 에 대해서 1648;1064; + 구글링 መ1;መ1; 사/168;를 찾아봐도 나오1656; 않아서
ᕬ1;시 2cpu 에 양0169;향1004;/196; 써보ǯ12;,144;나 사용1473;1060;신 ǥ16;1060; 1080;lj16;1648; 문1228;lj16; 없lj16;1648; 1656;문 올/140; 봅니다.
사용하시는 데이터베이스 엔진에 따라 달라지지만
잘 되시면 잘 않될것도 없지만
Active-Stanby 개념으로 사용할 수 있는 것이죠.
장애 극복용으로 사용할 수 있는 것이죠.
끊기지 않는 서비스 이걸 이루실려면
로드벨런싱을 앞단해서 해야야 하고.
원거리라면 Name Server의 변경 시간이 걸리어 이런 문제도 있습니다.
Oracle DB와 MS-SQL 은 어떻게 반응 할 지 ... 궁금하네요.
Oracle DB는 이런것을 거의 허용하지 않는데.. 궁금합니다.
게시판이나 댓글이 폭주하는 사이트에 적용하는거고 일반적인 DB에는 해당사항 없습니다.
디비야 뭐 여차하면 aws az 라도 쓰면 되는데
첨부파일은 용량이 너무 커서 ( 20테라가 넘어가요 ) 클라우드로는 비용 감당이 되지 않아
glusterfs geo-replication 양방향 운영을 검토중인 상황입니다.
현업에서 그리 쓰는데 없습니다.
데이터 정합성이 안된상태에서 역복제 일어나면 그냥 망하는거에요.
저도 제일 우려되었던게 역방한 연결시 정합성 체크를 하면서 기존에 쌓여있던 데이터를 삭제해 버리면 어쩌나 였거든요.
그런데 한달 넘도록 테스트만 반복하고 있는데 아직 그런 상황은 발생하지 않고 있습니다.
양방향을 껏다가 켰다가
단방향의 방향을 반대로 했다가
연동을 끄고 데이터를 쌓고 기존 데이터를 지우고 수정하고 다시 연결하고
여러가지 시나리오를 테스트 하고 있습니다만 아직까진 다행이 큰일?나는 상황은 발생하지 않았습니다.
여러가지 다양한 테스트를 해보면서 발생한 유일한 문제(?) 점은
create push-pem 를 한 순간 반대쪽이 read only 가 된다는 겁니다. 그래서 운영중 양방향 설정을 한다면
create push-pem 를 할때 반대쪽에서 read-only off 만 거의동시에 실행해 주거나 잠시 점검공지 올리고 진행하면 문제가 없습니다.
물론 아직은 저도 겁나서 운영서버에 양방향 설정은 하지 않았고요
만약 하더라도 스냅샷은 원래 기본이고 별도로 로컬에 백업대책을 만들어 두고 운영할 생각입니다.
gluster로 가능하면 MultiAZ 구현이 그리 어려울리 없죠
되던데요? 된다니까!! 하는 사람들 간혹 보입니다.
아니요! 못합니다.
그저 복구시 번거로운 작업을 줄이고 싶은 딱 그정도 입니다.