MySQL MMM 구성 (Centos7 + MySQL 8.0)

 

·       Version : MySQL 8.0.XX, Centos 7

 

MySQL MMM(MySQL Multi-Master) 구성하는 방법에 대해서 살펴본다. 이번 포스트에서는 MMM 구성에 대해서만 다루므로 MySQL 설치 Master-Slave 구성은 다른 글을 참고할 있도록 한다.

 

MMM구성에 관한 글을 찾아보면 대부분 Centos6 기반의 환경에서 설치된 글을 많이 있다. 필자의 경우 Centos7 환경에서 구성을 진행하였는데, Centos7 버전에서는 공식 가이드 문서에서 제공하는 코드와 조금 다르게 디렉터리 경로가 바뀐 부분이 있어 처음 설치시 오류가 발생하였다. 디렉터리 PATH 대한 설정 값을 수정하고 정상 작동확인한 내용을 정리하였다.

 

서버 구성

Host

IP

VIP

Role

DevMMM-Witness

192.168.0.1

 

Monitoring

DevMySQLMMM-1

192.168.0.2

192.168.0.102

Master 1

DevMySQLMMM-2

192.168.0.3

192.168.0.103

Master 2

 

·       Write VIP : 192.168.0.101

 

MNM 구성

·       MMM Monitor : MMM Agent 서버의 상태를 체크하고 상태에 따라 역할(reader, writer) 변경,관리

·       MMM Agent : MMM 에서 reader, writer 역할을 하는 구성원

·       MMM VIP : 유동적으로 writer 마스터 역할을 변경할 있도록 writer 구성하는 virtual IP

·       역할구성 : master역할을 있는 writer후보자들은는 두개로 구성하고, 나머지는 slave 역할만 하도록 구성

 

 

DevMMM-Witness

DevMySQLMMM-1

DevMySQLMMM-2

MMM 사용할 계정 생성

 

CREATE USER 'mmm_monitor'@'%' IDENTIFIED BY 'PASSWORD';

CREATE USER 'mmm_agent'@'%' IDENTIFIED BY 'PASSWORD';

 

GRANT ALL PRIVILEGES on *.* TO'mmm_monitor'@'%';

GRANT ALL PRIVILEGES on *.* TO'mmm_agent'@'%';

 

FLUSH PRIVILEGES;

 

호스트에 사용자 계정 추가

 

useradd --comment "MMM Script owner" --shell /sbin/nologin mmmd

 

MMM 설치

sudo yum install mysql-mmm mysql-mmm-monitor

sudo yum install mysql-mmm mysql-mmm-agent

sudo yum install mysql-mmm mysql-mmm-agent

mmm_common.conf 설정

sudo vi /etc/mysql-mmm/mmm_common.conf

 

아래 설정 입력

active_master_role          writer

 

<host default>

        cluster_interface eth0

        pid_path /run/mysql-mmm-agent.pid

        bin_path /usr/libexec/mysql-mmm/

        replication_user repluser

        replication_password PASSWORD

        agent_user mmm_agent

        agent_password PASSWORD

</host>

 

<host DevMySQLMMM-1>

        ip 192.168.0.2

        mode master

        peer DevMySQLMMM-2

              mysql_port 3306

</host>

 

 

<host DevMySQLMMM-2>

        ip 192.168.0.3

        mode master

        peer DevMySQLMMM-1

              mysql_port 3306

</host>

 

<role writer>

        hosts DevMySQLMMM-1, DevMySQLMMM-2

        ips 192.168.0.101

        mode exclusive

</role>

 

<role reader>

        hosts DevMySQLMMM-1,DevMySQLMMM-2

        ips 192.168.0.102,192.168.0.103

        mode balanced

</role>

mmm_agent.conf 설정

 

sudo vi /etc/mysql-mmm/mmm_agent.conf

 

아래 설정 입력

include mmm_common.conf

this DevMySQLMMM-1

sudo vi /etc/mysql-mmm/mmm_agent.conf

 

아래 설정 입력

include mmm_common.conf

this DevMySQLMMM-2

mmm_mon.conf 설정

sudo vi /etc/mysql-mmm/mmm_mon.conf

 

아래 설정 입력

include mmm_common.conf

 

<monitor>

    ip                  127.0.0.1

    pid_path            /run/mysql-mmm-monitor.pid

    bin_path            /usr/libexec/mysql-mmm/

    status_path         /var/lib/mysql-mmm/mmm_mond.status

    ping_ips            192.168.0.2,192.168.0.2

    auto_set_online     60

</monitor>

 

<host default>

    monitor_user        mmm_monitor

    monitor_password    PASSWORD

</host>

debug 0

 

 

부팅시 자동 시작 등록

sudo systemctl enable mysql-mmm-monitor

sudo systemctl enable mysql-mmm-agent

sudo systemctl enable mysql-mmm-agent

MMM 시작

sudo systemctl start mysql-mmm-monitor

sudo systemctl start mysql-mmm-agent

sudo systemctl start mysql-mmm-agent

 

MMM동작 확인

·       sudo mmm_control show

·       sudo mmm_control checks all

 

·       Role Change (Run as Monitor)

sudo mmm_control move_role writer DevMySQLMMM-1

 

 

MMM Troubleshooting

MMM 서비스 아래와 같이 ADMIN OFFLINE 표시한 경우 아래 명령어 실행

 

mmm_control set_online mysqltest-2

 

 

[참고자료]

·       https://mysql-mmm.org/mmm2_guide.html

 

 

2020-01-31 / Sungwook Kang / http://sungwookkang.com

 

MySQL, MMM, MySQL 복제, MySQL 이중화, MySQL Multi Master, 멀티마스터 복제, HA, Database 이중화, DBA

SQL Server 2016 향상된 복제 기능 배포 데이터베이스 클린업 향상

 

·      Version : SQL Server 2016 SP2, 2012 SP4 이후

 

SQL Server 2016 SP2 에서 복제 기능 향상으로 배포 데이터베이스를 클린업 할때 사용자가 일괄 삭제에 대한 입력 값을 정의할 있으며 대량 삭제 작업시 시스템이 자동으로 삭제 비율을 조정 있도록 변경되었다.

 

복제의 배포 데이터베이스는 전체 복제 토폴로지에서 매우 중요한 구성요소이다. 트랜잭션 복제의 경우 배포 에이전트는 복제 에이전트에 대한 복제 메타 데이터와 기록을 저장하는 외에도 구독자에게 전달 트랜잭션과 명령에 대한 중간 저장소를 제공한다.  이러한 트랜잭션과 명령은 MSRepl_Transactions MSRepl_Commands 테이블에 저장된다. 트랜잭션수가 매우 많은 게시자를 포함하는 트랜잭션 복제 토폴로지에서는 배포 데이터베이스의 MSRepl_Commands  MSRepl_Transactions 테이블이 상당히 커질 있다.

 

배포 서버에서 10분마다 실행되는 배포 클린업 작업은 지정된 트랜잭션 보존기간(기본 72시간) 기준으로 오래된 트랜잭션 명령을 삭제한다. 또한 배포 클린업 작업은 배포 서버에서 만료된 구독을 삭제한다.


 

배포 데이터베이스 클린업에서 사용자가 오해하는 부분이 있는데 동일한 게시 데이터베이스에 여러 트랜잭션 또는 스냅샷 게시가 있고 이러한 게시에 대한 클린업 작업을  배포 에이전트가 서로 다른 간격으로 실행되도록 구성하는 경우 클린업은 72시간 보다 오래된 데이터를 삭제하지 않을 있다. 이유는 배포 에이전트는 개별 게시자 데이터베이스에 대한 개별 배포 에이전트가 아닌 게시자 데이터베이스 기반으로 @max_cleanup_xact_seqno 계산하기 때문이다.

 

트랜잭션이 많은 환경에서 배포 클린업 작업은 많은 양의 만료된 트랜잭션 명령을 삭제해야한다. 클린업 작업은 while 루프를 사용하여 MSRepl_Commands MSRepl_Transactions 항목을 2000 5000행씩 일괄 삭제 한다. MSRepl_Commands MSRepl_Transactions 테이블 크기에 따라 삭제 시간이 오래 걸리수 있으므로 잠금 차단 또는 복제 에에전트 실패와 같은 여러가지 성능 문제가 발생할 있다.  복제 테이블의 크기가 작을 때는 문제 없지만 200~ 300 이상의 테이블 경우 성능 문제가 발생할 있다.

 

향상된 배포 클린업 기능으로는 삭제 프로시저에서 사용할 일괄 처리 행수를 사용자가 정의할 있다. 만약 매개 변수를 명시적으로 정의하지 않으면 기본값(batch size = 2000, row = 5000) 사용한다.   또한 반복마다 일괄 처리 크기를 이전의 반복 성능에 따라 배치 크기를 늘리거나 줄인다. 삭제 쿼리가 수행한 시간이 이전 실행과 비교하여 50% 향상되면 배치 크기 값을 20% 까지 증가하여 최대 50000행까지 증가한다. 만약 이전 실행과 비교하여  20% 감소하면 배치 크기 값을 50% 감소하고 기본값 2000/5000 으로  MSRepl_Commands MSRepl_Transactions 각각에 대해 일괄 처리 비율을 조절한다.

 

또한 향상된 기능으로 만료된 구독을 클린업 하는 작업을 기존의 배포 클린업 작업과 분리하였다. 하루에 실행되도록 등록된 구독 만료 클린업 작업은 배포 데이터베이스 서버에 연결하여 구독 클린업 저장 프로시저를 실행 한다. 클린업 작업은 삭제된 행의 누적값이 아닌 while루프의 마지막 반복을 기반으로 계수를 보고한다. 또한 메시지에서 표현되는 값을row/sec 에서row/ms 변경되어 보다 정확한 비율을 제공한다.

 

사용자 정의 파라메터를 지원하기 위해 sp_adddistributiondb 저장 프로시저에 개의 새로운 매개변수 @deletebtchsize_xact @deletebatchsize_cmd 추가 되었다. 매개 변수는 MSRepl_Transactions MSRepl_Commands 테이블의 일괄 삭제 처리를 제어한다. 또한 SSMS 변경 사항을 지원하도록 업데이트 되었다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sql_server_team/replication-enhancement-improved-distribution-database-cleanup/

 

 

 

2018-06-08 / 강성욱 / http://sqlmvp.kr / http://sqlangeles.com

 

SQL Server, MS SQL, SQL replication, Replication Enhancement, SQL 복제, 배포 데이터베이스, SQL Server AG, Availability Group, HA

SQL Server 2017향상된 복제 기능 배포 데이터베이스의 AG 지원

 

·      Version : SQL Server 2017 CU6

 

SQL Server 2017 CU6부터 SQL Server 복제 기능 향상으로 배포 데이터베이스가 가용성 그룹(AG) 포함이 가능하게 되었다. 개선 사항은 향후 SQL Server 2016 2014에도 적용될 예정이다.

SQL Server 가용성 그룹(AG) 사용하여 SQL Server 인스턴스간에 데이터베이스 그룹에 대한 실시간 데이터 복제 기능을 제공한다. 가용성 그룹은 복제할 모든 데이터베이스가 하나의 가용성 단위로 포함되어 동작한다. AG 페일오버가 발생해도 SQL Server 복제가 정상적으로 작동한다. 복제 게시 구독 데이터베이스는 가용성 그룹을 사용하도록 구성할 있지만 복제 배포 데이터베이스는 AG 포함할 없었다. 이번 업데이트를 통해서 AG 포함할 있게 되었다.

 

지원 기능

·       배포 데이터베이스가 AG 포함되도록 구성

·       AG 장애 조치 전후의 게시 구독과 같은 복제 구성

·       장애 조치 전과 후에 복제 작업이 작동

·       배포 데이터베이스가 AG 있는 경우 배포자 게시자에서 복제 제거

·       기존 배포 데이터베이스 AG 노드 추가 또는 제거

·       배포자는 여러 배포 데이터베이스를 가질수 있으며 배포 데이터베이스는 자체 AG 있을 있으며 여러 배포 데이터베이스는 동일한 AG 속할 있음

 

제약 사항

·       로컬 배포 지원되지 않음. 예를 들어 게시자와 배포자는 서로 다른 SQL Server 인스턴스여야 한다. 배포자로 자체 사용하는 게시자는 AG 배포 데이터베이스를 지원할 없음

·       병합복제 지원 안됨

·       즉시 또는 대기중인 업데이트 구독자가 있는 트랜잭션 복제는 지원되지 않음

·       피어 피어 복제는 지원 안됨

·       양방향 트랜잭션 복제는 지원 안됨

·       배포 데이터베이스 복제본을 호스팅하는 모든 SQL Server 인스턴스는 동일한 버전의 SQL Server (SQL Server 2017 CU6 이상) 사용 해야함

·       배포 데이터베이스 AG에는 수신기가 구성되어 있어야

·       배포 데이터베이스 AG 보조 복제본은 동기식 또는 비동기식일 있는데 동기모드가 권장됨. 비동기 모드는 데이터 손실 동기화 문제가 발생할 있음

·       배포 데이터베이스 AG 모든 복제본은 읽을 있어야 . 이는 2 복제본에서 실행해야하는 가지 구성단계 때문이다.

·       배포 데이터베이스 AG 모든 노드는 SQL Server 에이전트를 실행하는데 동일한 도메인 계정을 사용해야 하며 도메인 계정은 노드에 대해 동일한 권한을 가져야

·       복제 에이전트가 프록시 계정에서 실행되는 경우 프록시 계정은 배포 데이터베이스 AG 모든 노드에 존재해야하며 노드에서 동일한 권한이 필요함

·       배포자를 변경하거나 배포 데이터베이스 속성을 변경해야하는 경우 배포 데이터베이스 AG 참여하는 모든 복제본에서 작업을 수행해야함

·       게시자에서 배포자를 구성하려면 복제 마법사를 사용할 없으며 스크립트를 사용해야함

·       배포 데이터베이스용 AG구성은 스크립트를 통해서만 수행할 있음

·       AG 배포 데이터베이스를 설정하는 것은 새로운 복제 구성이어야 . 기존 배포 데이터베이스를 AG 전환하는것은 지원되지 않음. 또한 배포 데이터베이스를 AG에서 가져오면 이상 유요한 배포 데이터베이스로 작동 없으므로 삭제해야한다.

 

복제 기능 향상으로 가능 시나리오

·       복제 배포 데이터베이스의 고가용성 배포 데이터베이스는 복제 토폴로지의 핵심으로 배포 데이터베이스가 손실되면 전체 토폴로지가 변경사항 수신을 중지한다. 배포 서버는 SQL Server FCI 인스턴스로 보호할 있지만 로컬HA 제공하는 사이트 DR 제공하지 않는다. 사이트 DR 달성하기 위해 현재 권장되는 솔루션은 지리적으로 분산된 장애조치 클러스터 인스턴스를 사용하여 저장소 수준의 복제를 사용하는 것이다. (SAN기반 복제 또는 Windows 2016 S2D 소프트웨어 기반의 SAN 복제)

·       업그레이드/마이그레이션 중단 최소화 – SQL Server 복제는 서버 이름에 크게 의존하기 때문에 복제 배포 데이터베이스를 호스팅하는 SQL Server 인스턴스를 업그레이드/마이그레이션 하려면 전체 복제 토폴로지를 다시 배포하거나 다시 설정해야 한다. 이는 상당한 가동 중지 시간을 필요하다. 이번 기능 향상으로 복제 토폴로지에서 SQL Server 업그레이드하기 위한 가동 중지 시간과 복잡성을 최소화 있다.

·       기업 전체에 걸쳐 단일 HADR 솔루션 표준화 – Tier 1고객의 대다수는 SQL Server FCI 유일한 옵션인 복제 배포 데이터베이스를 제외하고 HADR 요구사항에 맞는 솔루션으로 SQL Server 가용성 그룹을 표준화 하고 있다. 새로운 기능 향상으로 배포 데이터베이스를 AG 포함하여 표준화가 가능하다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sql_server_team/replication-enhancement-distribution-database-in-availability-group/

 

 

 

2018-06-07 / 강성욱 / http://sqlmvp.kr / http://sqlangeles.com

 

SQL Server, MS SQL, SQL replication, Replication Enhancement, SQL 복제, 배포 데이터베이스, SQL Server AG, Availability Group, HA


+ Recent posts