MariaDB MaxScale monitor 매뉴얼

1
MaxScale Monitor
㈜네오클로바
DB컨설팅

2
개정이력
버전 변경일 변경사유1
변경내용2
작성자 승인자
Ver. 1.0 2020.11.12 최초작성 문서 최초 작성 김상모
1
변경 사유: 변경 내용이 이전 문서에 대해 최초작성/승인/추가/수정/삭제 중 선택 기입
2
변경 내용: 변경이 발생되는 위치와 변경 내용을 자세히 기록(장.절과 변경 내용을 기술한다.)

3
목차
1. About MariaDB MaxScale ..................................................................................................................................................5
2. Common Monitor Parameters .........................................................................................................................................6
1) Parameters.......................................................................................................................................................................6
2) Script events ................................................................................................................................................................ 11
3) Monitor Crash Safety............................................................................................................................................... 12
4) Script example ............................................................................................................................................................ 13
3. MariaDB Monitor................................................................................................................................................................. 15
1) Master selection......................................................................................................................................................... 15
2) Configuration............................................................................................................................................................... 16
3) MariaDB Monitor optional parameters ........................................................................................................... 17
4) Cluster manipulation operations........................................................................................................................ 22
- Operation details................................................................................................................................................ 23
- Manual activation............................................................................................................................................... 25
- Automatic activation......................................................................................................................................... 28
- Limitations and requirements....................................................................................................................... 28
- External master support.................................................................................................................................. 30
- Configuration parameters .............................................................................................................................. 30
5) Cooperative monitoring ......................................................................................................................................... 35
6) Troubleshooting ......................................................................................................................................................... 38
7) Using the MariaDB Monitor With Binlogrouter .......................................................................................... 38
4. Galera Monitor ..................................................................................................................................................................... 40
1) Configuration............................................................................................................................................................... 40
2) Galera Monitor optional parameters................................................................................................................ 41

4
3) Interation with Server Priorities .......................................................................................................................... 43
5. ColumnStore Monitor........................................................................................................................................................ 44
6. Automatic Failover With MariaDB Monitor............................................................................................................. 53

5
1. About MariaDB MaxScale
https://mariadb.com/kb/en/mariadb-maxscale-25-about-mariadb-maxscale/
MariaDB MaxScale 은 데이터베이스 서버에 SQL 을 전달하는 데이터베이스 프록시입니다.
서버로 전달은 SQL 에 대한 rules based 규칙과 데이터베이스들의 role 을 사용하여 수행됩니다.
MariaDB MaxScale 은 어플리케이션, Load Balancing, HA 기능들을 제공하도록 설계되었습니다.
다양한 프로토콜과 라우팅을 지원하는 플러그인들로 확장 가능하고 유연한 아키텍처를 가지고
있습니다.
MariaDB MaxScale makes extensive use of the asynchronous I/O capabilities of the Linux
operating system, combined with a fixed number of worker threads. epoll is used to provide the
event driven framework for the input and output via sockets.
Many of the services provided by MariaDB MaxScale are implemented as external shared object
modules loaded at runtime. These modules support a fixed interface, communicating the entry
points via a structure consisting of a set of function pointers. This structure is called the "module
object". Additional modules can be created to work with MariaDB MaxScale.
일반적으로 사용되는 모듈 유형은 protocol, router 및 filter 입니다. protocol 모듈은 클라이언트와
MariaDB MaxScale 사이, MariaDB MaxScale 과 백엔드 서버 사이의 통신을 구현합니다. router 는
클라이언트의 쿼리를 검사하고 대상 백엔드를 결정합니다. 백엔드 서버의 결정은 일반적으로
라우팅 규칙과 백엔드 서버 상태를 기반으로합니다. filter 는 MariaDB MaxScale 을 통과 하는
데이터에서 작동합니다. filter 는 종종 쿼리를 기록하거나 서버 응답을 수정하는 데 사용됩니다
A Google Group exists for MariaDB MaxScale. The Group is used to discuss ideas, issues and
communicate with the MariaDB MaxScale community. Send email to
maxscale@googlegroups.com or use the forum interface.
Bugs can be reported in the MariaDB Jira https://jira.mariadb.org

6
2. Common Monitor Parameters
https://mariadb.com/kb/en/mariadb-maxscale-25-common-monitor-parameters/
1) Parameters
 user
백엔드 서버의 모니터링을 위한 user를 설정 합니다.
Server 항목에서 monitoruser 설정이 있으면 해당 사용자를 사용합니다.
 password
user에 대한 비밀번호를 설정합니다.
Server 항목에서 monitorpw 설정이 있으면 해당 비밀번호를 사용합니다.
Note: In older versions of MaxScale this parameter was called passwd. The use of passwd was
deprecated in MaxScale 2.3.0.
 monitor_interval
Monitor가 서버 상태를 업데이트하는 빈도를 정의합니다. 기본값은 2 초입니다. 서버를 더 자주
조회해야하는 경우 더 낮은 값을 선택하십시오. 가능한 가장 작은 값은 100 밀리 초입니다. 서
버 쿼리가 monitor_interval보다 오래 걸리면 유효 업데이트 속도가 감소합니다.
단위를 지정하지 않으면 값은 MaxScale 2.4에서 밀리 초로 해석됩니다. 이후 버전에서는 단위가
없는 값이 거부 될 수 있습니다.
The default value of monitor_interval is 2000 milliseconds.
monitor_interval=2500ms
 backend_connect_timeout
이 매개 변수는 모니터링되는 서버에 connect 하기위한 제한 시간을 설정합니다. 단위를 지정
하지 않으면 MaxScale 2.4에서 값이 초로 해석됩니다. 이후 버전에서는 단위가 없는 값이 거부

7
될 수 있습니다. 밀리초 단위로는 설정 할 수 없습니다. 최소값은 1초이고 기본값은 3초입니다.
backend_connect_timeout=3s
 backend_write_timeout
이 매개 변수는 모니터링되는 서버에 write 하기위한 제한 시간을 설정합니다. 단위를 지정하지
않으면 MaxScale 2.4에서 값이 초로 해석됩니다. 이후 버전에서는 단위가 없는 값이 거부 될 수
있습니다. 밀리초 단위로는 설정 할 수 없습니다. 최소값은 1초이고 기본값은 3초입니다.
backend_write_timeout=3s
 backend_read_timeout
이 매개 변수는 모니터링되는 서버에 read 하기위한 제한 시간을 설정합니다. 단위를 지정하지
않으면 MaxScale 2.4에서 값이 초로 해석됩니다. 이후 버전에서는 단위가 없는 값이 거부 될 수
있습니다. 밀리초 단위로는 설정 할 수 없습니다. 최소값은 1초이고 기본값은 3초입니다.
backend_read_timeout=3s
 backend_connect_attempts
이 매개 변수는 모니터링 루프마다 백엔드 연결이 시도되는 최대 횟수를 정의합니다. 기본값은
1입니다. 모든 시도를 수행하는 데 최대 backend_connect_timeout 초가 걸릴 수 있습니다. 성
공한 시도가 없으면 백엔드에 연결할 수 없고 down 된 것으로 간주됩니다.
backend_connect_attempts=1
 disk_space_threshold
이 매개 변수는 server parameter 의 disk_space_threshold 설정과 중복됩니다. 매개 변수가
server 에 지정되지 않은 경우 모니터에 지정된 매개 변수가 적용됩니다.
Monitor 가 모니터링하는 모든 서버에서 디스크 구성이 동일하면 모니터 섹션에서 디스크 공간
임계 값을 지정하는 것으로 충분하고 (더 편리함) 디스크 구성이 일부 서버에서 다른 경우,
디스크 공간 설정 값을 각 server 에 대해 개별적으로 지정할 수 있습니다.

8
예를 들어 server1, server2 및 server3 이 모든면에서 동일하다고 가정합니다. 이 경우
모니터에서 disk_space_threshold 를 지정할 수 있습니다.
[server1]
type=server
...
[server2]
type=server
...
[server3]
type=server
...
[monitor]
type=monitor
servers=server1,server2,server3
disk_space_threshold=/data:80
...
서버가 서로 다른 경로에 마운트 된 데이터 디렉토리에 사용되는 디스크인 경우 디스크 공간
임계 값을 각 server에 대해 별도로 지정해야합니다.
[server1]
type=server
...
[server2]
type=server
disk_space_threshold=/Data:80
...
[server3]
type=server
disk_space_threshold=/DBData:80
...
[monitor]
type=monitor
...
대부분의 서버에 데이터 디렉토리 디스크가 동일한 경로에 마운트 되어있는 경우 디스크 공간
임계 값은 모니터에 설정 하고 다른 경로를 사용하는 경우는 server에서 별도로 지정 할 수 있
습니다.

9
[server1]
type=server
disk_space_threshold=/DbData:80
...
[server2]
type=server
...
[server3]
type=server
...
[monitor]
type=monitor
server1에는 /DbData에 마운트 된 데이터 디렉토리에 사용되는 디스크가 있고 server2와
server3은 /data에 마운트되어 있으므로 모니터의 설정이 적용됩니다.
 disk_space_check_interval
이 매개 변수를 사용하여 디스크 공간 검사 사이의 최소 시간을 지정할 수 있습니다. 단위가
지정 되지 않으면 값은 MaxScale 2.4 에서 밀리 초로 해석됩니다. 이후 버전에서는 단위가 없는
값이 거부 될 수 있습니다. 기본값은 0 이며, 이는 기본적으로 디스크 공간이 확인되지 않음을
의미합니다.
검사는 정기적인 모니터 간격 주기의 일부로 수행되므로 디스크 공간 검사 간격은
monitor_interval 값의 영향을 받습니다. 특히 disk_space_check_interval 의 값이
monitor_interval 의 값보다 작더라도 검사는 monitor_interval 간격으로 수행됩니다.
disk_space_check_interval=10000ms
 script
이 명령은 서버 상태 변경시 실행됩니다. 매개 변수는 명령에 대한 절대 경로이거나 명령이
실행 가능한 경로에 있어야 합니다. MaxScale 을 실행하는 사용자는 파일 자체 및 파일이 있는
디렉토리에 대한 실행 권한이 있어야 합니다. 스크립트에는 MaxScale 이 스크립트를 시작할 때
유용한 정보로 사용할 수 있는 placeholder 가 있을 수 있습니다.

10
The placeholders and their substition results are:
 $INITIATOR -> IP and port of the server which initiated the event
 $EVENT -> event description, e.g. "server_up"
 $LIST -> list of IPs and ports of all servers
 $NODELIST -> list of IPs and ports of all running servers
 $SLAVELIST -> list of IPs and ports of all slave servers
 $MASTERLIST -> list of IPs and ports of all master servers
 $SYNCEDLIST -> list of IPs and ports of all synced Galera nodes
 $PARENT -> IP and port of the parent of the server which initiated the event. For master-
slave setups, this will be the master if the initiating server is a slave.
 $CHILDREN -> list of IPs and ports of the child nodes of the server who initiated the
event. For master-slave setups, this will be a list of slave servers if the initiating server is a
master.
제공되는 변수 값은 변수의 요구 사항과 일치하는 서버가 없는 경우 빈 문자열이 될 수
있습니다. 예를 들어, 사용 가능한 마스터가 없는 경우 $MASTERLIST 는 빈 문자열로 제공
됩니다. list-type 변수 에는 현재 Monitor 가 모니터링 하는 서버만 포함됩니다.
script=/home/user/myscript.sh initiator=$INITIATOR event=$EVENT live_nodes=$NODELIST
The above script could be executed as:
/home/user/myscript.sh initiator=[192.168.0.10]:3306 event=master_down
live_nodes=[192.168.0.201]:3306,[192.168.0.121]:3306
See section Script example below for an example script.
실행 된 스크립트은 MaxScale 로그에 기록됩니다. 각각의 실행 결과는 별도의 로그 메시지로
기록됩니다.
메시지가 기록되는 로그 수준은 메시지 형식에 따라 다릅니다. 출력 줄의 첫 번째 단어가
alert :, error :, warning :, notice :, info : 또는 debug : 중 하나이면 해당 수준에서 메시지가
기록됩니다. 메시지에 키워드 중 하나가 접두사로 지정되지 않은 경우 메시지는 notice
수준으로 기록됩니다. 키워드와 콜론 앞, 뒤 또는 사이의 공백은 무시되며 일치 항목은 대소
문자를 구분하지 않습니다.
Currently, the script must not execute any of the following MaxCtrl calls as they cause a deadlock:

11
 alter monitor to the monitor executing the script
 stop monitor to the monitor executing the script
 call command to a MariaDB-Monitor that is executing the script
 script_timeout
스크립트의 실행 시간 timeout 입니다. 단위가 지정되지 않으면 MaxScale 2.4 에서 값이 초로
해석됩니다. 이후 버전에서는 단위가없는 값이 거부 될 수 있습니다. 시간 제한의 설정은
초이므로 기간이 1 초보다 길더라도 밀리 초 단위로 지정된 제한 시간이 거부됩니다. 기본값은
90 초입니다.
스크립트 실행이 설정된 시간 제한을 초과하면 SIGTERM 신호를 보내 중지됩니다. 프로세스가
중지되지 않으면 실행 시간이 구성된 timeout 의 두 배보다 크면 SIGKILL 신호가 전송됩니다.
 Events
스크립트가 실행되도록 하는 이벤트 이름 목록입니다. 이 옵션이 정의되어 있지 않으면 모든
이벤트에 스크립트가 실행됩니다. 목록에는 쉼표로 구분 된 이벤트 이름 목록이 포함 되어야합
니다.
events=master_down,slave_down
2) Script events
Monitor를 호출 할 수 있는 모든 가능한 이벤트 유형 및 설명은 아래 표와 같습니다.
Event Name Description
master_down A Master server has gone down
master_up A Master server has come up
slave_down A Slave server has gone down
slave_up A Slave server has come up
server_down A server with no assigned role has gone down
server_up A server with no assigned role has come up

12
lost_master A server lost Master status
lost_slave A server lost Slave status
new_master A new Master was detected
new_slave A new Slave was detected
 Journal_max_age
최대 저널 파일 사용 기간입니다. 단위가 지정되지 않으면 MaxScale 2.4 에서 값이 초로
해석됩니다. 이후 버전에서는 단위가 없는 값이 거부 될 수 있습니다. 최대 수명의 설정은
초이므로 기간이 1 초보다 길더라도 밀리 초로 지정된 최대 수명은 거부됩니다. 기본값은
28800 초입니다.
Monitor 가 시작되면 저장된 저널 파일을 읽습니다. 저널 파일이 journal_max_age 값보다
오래된 경우 제거되고 서버에 대한 상태 정보가 없이 Monitor 가 시작됩니다.
3) Monitor Crash Safety
MaxScale 2.2.0 부터 Monitor 모듈은 최신 서버 상태를 on-disk journal 로 유지합니다. 이로 인해
상태를 파악하는 옵션이 사용될 때 Monitor 가 crash-safe 되도록 합니다. 또한 MaxScale 이 다시
시작될 때 Monitor 가 상태 정보를 유지할 수 있습니다.
For MariaDB monitor, options that introduce states into the monitoring process are the
detect_stale_master and detect_stale_slave options, both of which are enabled by default.
Galeramon has the disable_master_failback parameter which introduces a state.
서버 상태 저널의 기본 위치는 /var/lib/maxscale/<monitor name>/monitor.dat 입니다. 여기서
<monitor name>은 구성 파일의 모니터 섹션 이름입니다. MaxScale 이 crash 되거나 알 수 없는
방식으로 종료되면 MaxScale 이 시작될 때 저널을 읽습니다. 복구 프로세스를 건너 뛰려면
MaxScale 을 시작하기 전에 저널 파일을 수동으로 삭제하십시오.

13
4) Script example
Below is an example monitor configuration which launches a script with all supported substitutions.
The example script reads the results and prints it to file and sends it as email.
[MyMonitor]
type=monitor
module=mariadbmon
servers=C1N1,C1N2,C1N3
user=maxscale
password=password
monitor_interval=10000
script=/path/to/maxscale_monitor_alert_script.sh --initiator=$INITIATOR --parent=$PARENT
--children=$CHILDREN --event=$EVENT --node_list=$NODELIST --list=$LIST --
master_list=$MASTERLIST --slave_list=$SLAVELIST --synced_list=$SYNCEDLIST
File "maxscale_monitor_alert_script.sh":
#!/usr/bin/env bash
initiator=""
parent=""
children=""
event=""
node_list=""
list=""
master_list=""
slave_list=""
synced_list=""
process_arguments()
{
while [ "$1" != "" ]; do
if [[ "$1" =~ ^--initiator=.* ]]; then
initiator=${1#'--initiator='}
elif [[ "$1" =~ ^--parent.* ]]; then
parent=${1#'--parent='}
elif [[ "$1" =~ ^--children.* ]]; then
children=${1#'--children='}
elif [[ "$1" =~ ^--event.* ]]; then
event=${1#'--event='}
elif [[ "$1" =~ ^--node_list.* ]]; then
node_list=${1#'--node_list='}
elif [[ "$1" =~ ^--list.* ]]; then
list=${1#'--list='}
elif [[ "$1" =~ ^--master_list.* ]]; then
master_list=${1#'--master_list='}
elif [[ "$1" =~ ^--slave_list.* ]]; then

14
slave_list=${1#'--slave_list='}
elif [[ "$1" =~ ^--synced_list.* ]]; then
synced_list=${1#'--synced_list='}
fi
shift
done
}
process_arguments $@
read -r -d '' MESSAGE << EOM
A server has changed state. The following information was provided:
Initiator: $initiator
Parent: $parent
Children: $children
Event: $event
Node list: $node_list
List: $list
Master list: $master_list
Slave list: $slave_list
Synced list: $synced_list
EOM
# print message to file
echo "$MESSAGE" > /path/to/script_output.txt
# email the message
echo "$MESSAGE" | mail -s "MaxScale received $event event for initiator $initiator."
mariadb_admin@domain.com

15
3. MariaDB Monitor
https://mariadb.com/kb/en/mariadb-maxscale-25-mariadb-monitor/
MariaDB Monitor 는 replication 클러스터를 모니터링 합니다. 백엔드의 상태를 확인하고 쿼리를
라우팅 할 위치를 결정할 때 router 에서 사용하는 master 및 slave 와 같은 서버 역할을
할당합니다. 또한 failover, switchover 및 rejoin 을 수행하여 replication 클러스터를 수정 할 수도
있습니다. MariaDB / MySQL 5.5 이전의 백엔드 서버 버전은 지원되지 않습니다. failover 및 기타
유사한 작업에는 MariaDB 10.0.2 이상이 필요합니다.
Up until MariaDB MaxScale 2.2.0, this monitor was called MySQL Monitor.
1) Master selection
한 번에 하나의 백엔드만 Master 가 될 수 있습니다. Master 가 실행 중이어야하며 (Monitor 에
의해 성공적으로 연결됨) read_only 설정이 꺼져 있어야 합니다. Master 가 Multi-master 그룹의
일부가 아니면 Master 가 모니터링되는 클러스터의 다른 서버에서 replicate 되지 않을 수
있습니다. Master 선택은 가능한 multiple replication layers 에서 가장 많은 slave 가있는 서버를
선택하는 것을 선호합니다. 실행중인 릴레이 체인을 통해 도달 할 수 있거나 Master 카운트에
직접 연결된 slave 만 가능합니다. Master 상태에 대해 여러 서버가 연결되어있는 경우 모니터의
서버 설정에서 먼저 설정한 서버가 선택됩니다.
cyclical replication topology (멀티 마스터 그룹)의 서버는 그룹의 모든 서버를 slave 로 갖는
것으로 해석됩니다. Multi-master 그룹에서도 하나의 서버만 Master 로 선택됩니다.
Master 를 선택한 후 Monitor 는 더 많은 slave 서버가 있는 다른 잠재적인 Master 를 사용할 수
있더라도 선택 사항을 고수하는 것을 선호합니다. 현재 Master 가 분명히 적합하지 않은 경우에만
Monitor 가 다른 Master 를 선택하려고합니다. 다음과 같은 경우 기존 Master 가 무효화됩니다.
1. It is unwritable (read_only is on).
2. It has been down for more than failcount monitor passes and has no running slaves.
Running slaves behind a downed relay count.
3. It did not previously replicate from another server in the cluster but it is now replicating.
4. It was previously part of a multimaster group but is no longer, or the multimaster group is
replicating from a server not in the group.

16
1 과 2 는 DBA, 외부 스크립트 또는 다른 MaxScale 이 이전 Master 가 더 이상 Master 로 작동 할
수 없도록 클러스터를 수정 한 상황을 다룹니다. 3 과 4 의 경우 replication 토폴로지가
변경되었으면 이전 Master 가 여전히 최선의 선택 일 수 있지만 Master 를 다시 선택 해야
합니다.
위에서 설명한 Master 변경은 failover, switchover 및 auto-rejoin 섹션에 설명 된 failover 및
switchover 와 다릅니다. Master 변경은 MaxScale 내부의 서버 역할 만 수정하고 읽기 및 쓰기
쿼리의 대상을 변경하는 것 외에 클러스터를 수정하지는 않습니다. failover 및 switchover 는
자체적으로 Master 변경을 수행합니다.
일반적으로 클러스터에 여러 standalone 서버, Master-slave 또는 multimaster 그룹이 있는 상황을
피하는 것이 좋습니다. Master 무효화 규칙 2 로 인해 standalone 마스터는 다운되면 다른 유효한
Master 에 대한 Master 상태를 쉽게 잃을 수 있습니다. 새 Master 에는 이전 Master 와 동일한
데이터가 없을 수 있습니다. Non-stanalone Master 는 실행중인 단일 slave 또는 multimaster 그룹
구성원이 down 된 경우에도 Master 를 유효하게 유지하므로 위험성이 있습니다.
2) Configuration
Monitor 에 대한 최소 구성에는 모니터링을 위한 서버 세트와 서버에 연결 하기 위한 user 및
비밀번호가 필요합니다.
[MyMonitor]
type=monitor
module=mariadbmon
user=myuser
password=mypwd
From MaxScale 2.2.1 onwards, the module name is mariadbmon instead of mysqlmon. The old
name can still be used.
사용자는 사용되는 Monitor 기능에 따라 권한이 필요합니다. REPLICATION CLIENT (MariaDB
10.5 의 경우 REPLICATION SLAVE ADMIN)를 사용하면 모니터가 복제 연결을 나열 할 수
있습니다. 필요한 권한에 대한 자세한 내용은 Cluster manipulation operations 을 참조하십시오.

17
MariaDB [(none)]> grant replication client on *.* to 'myuser'@'maxscalehost';
Query OK, 0 rows affected (0.00 sec)
3) MariaDB Monitor optional parameters
MariaDB Monitor에서 사용하는 선택적 매개 변수입니다. failover, switchover 및 rejoin 관련 매개
변수는 해당 섹션에 나열됩니다.
 assume_unique_hostnames
Boolean, default: ON.
Monitor 는 MaxScale 구성 파일의 서버 정의와 서버 자체의 "SHOW ALL SLAVES STATUS"
출력간에 서버 호스트 이름과 포트가 일치한다고 가정합니다. 특히 Monitor 는 서버 A 가 서버
B 에서 복제하는 경우 A 가 구성 파일에 있는 B 의 주소 및 포트와 동일한 Master_Host 및
Master_Port 와의 slave 연결이 있어야 한다고 가정합니다. 그렇지 않은 경우, 예 : 파일에
호스트 이름이 제공되는 동안 IP 가 서버에서 사용되면 Monitor 가 토폴로지를 잘못 해석 할 수
있습니다. MaxScale 2.4.1 에서 Monitor 는 단순 문자열 비교로 일치하는 항목을 찾지 못하면
주소에 대한 이름 확인을 시도합니다. 정확히 일치하는 주소를 사용하는 것이 좋습니다.
MaxScale 은 "CHANGE MASTER TO" 명령을 실행할 때 구성 파일의 주소와 포트를 사용하기
때문에 failover 또는 switchover 와 같은 클러스터 작업 기능을 사용하려면 ON 으로 설정
해야합니다.
네트워크 구성이 MaxScale 의 백엔드에 연결하는 데 사용하는 주소가 서버가 서로 연결하는 데
사용하는 주소와 다른 경우 assume_unique_hostnames 를 OFF 로 설정 해야합니다. 이
모드에서 MaxScale 은 서버 ID 를 사용합니다. 서버와 slave 연결의 Master_Server_Id 필드에서
쿼리하여 어느 서버에서 어떤 서버를 복제 하는지 추론합니다. MaxScale 이 연결되지 않은
서버의 ID 를 알지 못하기 때문에 이것은 완벽하지 않습니다 (예 : MaxScale 이 시작된 이후
서버가 down 되었습니다). 또한 slave 연결이 설정되지 않은 경우 Master_Server_Id 필드에
잘못된 값이 있을 수 있습니다. MaxScale 은 Monitor 에서 slave connection IO 스레드가 한 번
이상 연결 된 경우에만 값을 신뢰합니다. 그렇지 않은 경우 slave 연결이 무시됩니다.

18
 detect_stale_master
Boolean, default: ON. Deprecated.
OFF 로 설정하면 running_slave 설정이 master_conditions 매개 변수에 추가됩니다.
 detect_stale_slave
OFF로 설정하면 linked_master 설정이 slave_conditions 매개 변수에 추가됩니다.
 detect_standalone_master
OFF로 설정하면 connecting_slave 설정이 master_conditions 매개 변수에 추가됩니다.
 master_conditions
Enum, default: primary_monitor_master.
Master 상태에 대한 추가 조건을 지정합니다, i.e qualified for read and write queries.
일반적으로 Master selection에 설명 된대로 적합한 Master 후보 서버가 발견되면 MaxScale에
서 이를 Master로 지정합니다. master_conditions는 Master 서버에 대한 추가 조건을 설정합니
다. 이 설정은 enum 형이므로 여러 조건을 동시에 설정 할 수 있습니다. 조건 2, 3 및 4는
slave 서버를 나타냅니다. 결합 된 경우 단일 slave는 Master가 실행 가능하도록 주어진 모든
조건을 충족해야합니다.
Master 후보가 master_conditions에 실패했지만 slave_conditions를 충족하면 대신 Slave로 지정
될 수 있습니다.
The available conditions are:
none 추가 조건 없음
connecting_slave 하나 이상의 slave(no behind relay)가 replication을 시도하거나
Master에서 복제 중입니다(Slave_IO_Running은 'Yes' 또는

19
'Connecting', Slave_SQL_Running은 'Yes'). slave가 down 된 경우 마
지막으로 성공한 monitor tick의 결과가 사용 됩니다.
connected_slave connecting_slave와 동일하지만 replication 연결이 작동되어야한다는
차이점이 있습니다(Slave_IO_Running은 'Yes'). slave가 down 된 경우
마지막으로 성공한 monitor tick의 결과가 사용 됩니다.
running_slave connecting_slave와 동일하며 slave가 Running 중이어야합니다.
primary_monitor_master MaxScale이 다른 MaxScale과 cooperating하고 secondary MaxScale
인 경우, candidate Master도 primary MaxScale에서 선택 되어야 합니
다.
Candidate master는 primary MaxScale에서도 선택됩니다.
이 설정의 기본값은 master_requirements = primary_monitor_master입니다. 두 Monitor가 협력
할 때 동일한 Master 서버를 사용 하도록 합니다.
For example, to require that the master must have a slave which is both connected and running,
set
master_conditions=connected_slave,running_slave
 slave_conditions
Enum, default: none.
slave 상태에 대한 추가 조건을 지정합니다. i.e qualified for read queries.
일반적으로 Master 후보 또는 relay 에서 복제를 시도하는 서버는 slave 입니다. Master 후보는
반드시 쓰기가 가능 할 필요는 없습니다. master_conditions 에 실패하면 slave_conditions 는
slave 서버에 대한 추가 조건을 설정합니다. 이 설정은 enum 형이므로 여러 조건을 동시에
설정할 수 있습니다.
The available conditions are:
none 추가 조건 없음.
linked_master slave 는 Master 에 연결되어야하며 (Slave_IO_Running 및
Slave_SQL_Running 은 'Yes') Master 가 Running 중이어야합니다.
slave 와 Master 사이의 모든 relay 에도 동일하게 적용됩니다.
running_master Master 가 Running 중이어야 합니다. relay 가 down 되었을 수
있습니다.

20
writable_master Master 는 쓰기 가능해야합니다, i.e. labeled Master.
primary_monitor_master MaxScale 이 다른 MaxScale 과 cooperating 하고 secondary MaxScale
인 경우, candidate Master 도 primary MaxScale 에서 선택
되어야합니다.
For example, to require that the master server of the cluster must be running and writable for
any servers to have Slave-status, set
slave_conditions=running_master,writable_master
 ignore_external_masters
Boolean, default: OFF.
Monitor 에서 모니터링하지 않지만 replication 토폴로지의 일부인 서버는 무시 합니다.
외부 서버는 Monitor 에서 모니터링하지 않는 서버입니다. 서버가 외부 서버에서
replication 하는 경우 일반적으로 외부 서버 상태의 slave 를 얻습니다. 이 설정을 사용하면
상태가 설정되지 않습니다.
 failcount
default: 5.
Master 서버의 연속 모니터 통과 횟수는 fail 로 간주되기 전에 down 되어야합니다. 자동
failover 가 활성화 된 경우 (auto_failover = true) 이 때 수행 할 수 있습니다. 0 또는 1 값은
즉각적인 failover 를 활성화 합니다.
자동 failover 가 불가능한 경우 Monitor 는 Master 역할을 수행하기 위해 다른 서버를
검색하려고 시도합니다. 자세한 내용은 Master selection 섹션을 참조하십시오. Master 를
변경하면 이전 이벤트 없이 쿼리가 서버로 라우팅 될 수 있으므로 replication 이 중단 될 수
있습니다. 이를 방지하려면 클러스터에 여러 개의 유효한 마스터 서버를 두지 마십시오.
Master failure 와 failover 시작 사이의 최악의 지연은 backend_connect_timeout 값과
monitor_interval 을 합하고 이를 failcount 로 곱하여 추정 할 수 있습니다.

21
(monitor_interval + backend_connect_timeout) * failcount
 enforce_read_only_slaves
default: OFF.
ON으로 설정하면 모니터는 read_only가 OFF 인 slave 서버에서 서버 read_only 플래그를 ON
으로 설정하려고합니다. 이 플래그는 모든 Monitor 확인시에 적용 됩니다. Monitor 사용자는 이
기능이 작동하려면 SUPER 권한이 필요합니다. read_only가 ON 인 동안에는 SUPER 권한이있는
사용자만 백엔드 서버에 변경이 가능합니다. 임시 쓰기 액세스가 필요한 read_only를 비활성화
하기 전에이 기능을 비활성화해야합니다. 그렇지 않으면 모니터가 빠르게 다시 활성화합니다.
 maintenance_on_low_disk_space
default: enabled.
Master 또는 relay Master가 아닌 실행중인 서버에 디스크 공간이 부족하면 서버가 유지 관리
모드로 설정됩니다. 해당 서버는 router 세션에 사용되지 않으며 faillover 또는 기타 클러스터
수정 작업을 수행 할 때 무시됩니다. 디스크 공간 모니터링을 활성화하는 방법은 common
Monitor parameters의 disk_space_threshold 및 disk_space_check_interval을 참조하십시오.
서버가 유지 관리 모드로 전환되면 해당 서버의 디스크 공간 상황이 더 이상 업데이트되지 않
습니다. 더 많은 디스크 공간을 사용할 수 있어도 서버는 유지 관리 모드에서 벗어나지 않습니
다. 유지 관리 플래그는 수동으로 제거해야합니다.
maxctrl clear server server2 Maint
 cooperative_monitoring_locks
여러 MaxScale 이 동일한 백엔드 클러스터를 모니터링하는 경우 이 설정을 사용하는 것이
좋습니다. 활성화되면 모니터는 백엔드 서버에서 배타적 잠금을 획득하려고 시도합니다.
Monitor 는 majority of locks 경우 자신을 기본 Monitor 로 간주합니다. Majority 는 구성된 모든
서버 또는 실행중인 서버 위에 있을 수 있습니다. 이 기능의 작동 방식과 사용할 값에 대한
자세한 내용은 cooperative monitoring 을 참조하십시오.
Allowed values:

22
1. none Default value, no locking.
2. majority_of_all Primary monitor requires majority of locks, even counting servers which are
[Down].
3. majority_of_running Primary monitor requires majority of locks over [Running] servers.
이 설정은 global MaxScale 의 passive 설정이 있으면 무시됩니다. passive 로 설정하면
Monitor 가 잠금을 획득 한 경우에도 클러스터 작업이 비활성화됩니다. 일반적으로 협력
모니터링과 passive 설정을 혼합하지 않는 것이 가장 좋습니다.
4) Cluster manipulation operations
MaxScale 2.2.1 부터 MariaDB Monitor 는 replication 클러스터 수정을 지원합니다. 구현 된 작업은
다음과 같습니다.
- 장애가 발생한 Master 를 slave 로 대체하는 failover
- 실행중인 Master 를 slave 로 교체하는 switchover
- switchover 를 예약하고 반환하는 asyn-switchover
- 서버가 Master 에서 replication 하도록 지시하는 rejoin
- reset-replication (MaxScale 2.3.0 에 추가됨), binary log 를 삭제하고 gtid 를 재설정
각 명령에 대한 자세한 내용은 operation details 를 참조하십시오.
클러스터 작업을 수행하려면 Monitor user 에게 다음 권한이 있어야합니다.
 SUPER, to modify slave connections, set globals such as read_only and kill connections
from other super-users
 SELECT on mysql.user, to see which users have SUPER
 REPLICATION CLIENT (REPLICATION SLAVE ADMIN in MariaDB Server 10.5), to list slave
connections
 RELOAD, to flush binary logs
 PROCESS, to check if the event_scheduler process is running
 SHOW DATABASES and EVENT, to list and modify server events
GRANT super, replication client, reload, process, show databases, event on *.* to
'myuser'@'maxscalehost';

23
GRANT select on mysql.user to 'myuser'@'maxscalehost';
권한(privilege) 시스템은 MariaDB Server 10.5에서 변경되었습니다. SUPER 권한은 많은 필수 권한
을 포함하고 다른 수퍼 유저의 연결을 종료하는데 여전히 필요하기 때문에 MaxScale Monitor
user 에게 미치는 영향은 미미합니다.
GRANT super, reload, process, show databases, event on *.* to 'myuser'@'maxscalehost';
GRANT select on mysql.user to 'myuser'@'maxscalehost';
또한 Monitor 는 replication 를 시작할 때 slave 가 사용 해야하는 사용자 이름과 암호를
알아야합니다. replication_user 및 replication_password 에 설정 합니다.
user 는 클러스터 조작 명령에 의해 promote 되거나 demote 되는 모든 서버에서 실행되는 SQL
문의 파일을 정의 할 수 있습니다. 자세한 내용은 promotion_sql_file 및 demotion_sql_file 섹션을
참조하십시오.
Monitor 는 서버를 promote 또는 demote 할 때 예약 된 서버 이벤트를 조작 할 수 있습니다.
자세한 내용은 handle_events 섹션을 참조하십시오.
모든 클러스터 작업은 MaxCtrl 을 통해 수동으로 활성화 할 수 있습니다. 자세한 내용은 manual
activation 섹션을 참조하십시오.
failover 및 switchover 과 관련된 issue 에 대한 정보는 limitations and requirements 를
참조하십시오.
- Operation details
Failover 는 장애가 발생한 Master 를 실행중인 slave 로 대체합니다. 다음을 수행합니다.
1. Old Master 의 최신 slave 를 new Master 로 선택합니다. 선택 기준은 아래 순서와
같습니다.
1. gtid_IO_pos (latest event in relay log)
2. gtid_current_pos (most processed events)
3. log_slave_updates is on
4. disk space is not low

24
2. New Master 에 처리되지 않은 relay log 항목이있는 경우 취소하고 나중에 다시
시도합니다.
3. New master 준비:
1. Remove the slave connection the new master used to replicate from the old
master.
2. Disable the read_only-flag.
3. Enable scheduled server events (if event handling is on). Only events that were
enabled on the old master are enabled.
4. Run the commands in promotion_sql_file.
5. Start replication from external master if one existed.
4. 다른 모든 slave 를 리디렉션하여 new master 에서 복제합니다:
1. STOP SLAVE and RESET SLAVE
2. CHANGE MASTER TO
3. START SLAVE
5. 모든 slave 가 복제 중인지 확인합니다.
클러스터에 유효한 Master 서버가 있으며 1 ~ 3 단계가 성공하면 failover 가 성공한 것으로
간주됩니다.
Switchover 는 실행중인 Master 를 실행중인 slave 로 교체합니다. 다음을 수행합니다.
1. Demote 를 위해 old Master 를 준비합니다:
1. Stop any external replication.
2. Kill connections from super-users since read_only does not affect them.
3. Enable the read_only-flag to stop writes.
4. Disable scheduled server events (if event handling is on).
5. Run the commands in demotion_sql_file.
6. Flush the binary log (FLUSH LOGS) so that all events are on disk.
2. New Master 가 old Master 를 따라 잡을 때까지 기다립니다.
3. Failover 단계 3 및 4 에서와 같이 new Master 를 승격하고 slave 를 리디렉션합니다. 또한
demote 된 old Master 를 리디렉션합니다.
4. 모든 slave 가 복제 중인지 확인합니다.
failover 와 유사하게 new Master 가 성공적으로 promote 된 경우 switchover 이 성공한 것으로
간주됩니다.
Rejoin 은 standalone 서버를 클러스터에 join 하거나 Master 가 아닌 서버에서 replication 하는
slave 를 리디렉션합니다. Standalone 서버는 다음과 같이 join 됩니다:

25
1. Run the commands in demotion_sql_file.
2. Enable the read_only-flag.
4. Start replication: CHANGE MASTER TO and START SLAVE.
Wrong Master 에서 복제중인 서버는 STOP SLAVE, RESET SLAVE, CHANGE MASTER TO 및 START
SLAVE 명령으로 간단히 리디렉션됩니다.
Reset-replication (added in MaxScale 2.3.0)는 binary log 를 삭제하고 gtid 를 재설정합니다. 이
destructive 명령은 클러스터의 gtid 가 동기화 되지 않고 실제 데이터가 동기화 된 것으로 알려진
상황을 위한 것입니다. 작업은 다음과 같이 진행됩니다:
1. gtid 를 재설정하고 모든 서버에서 binary log 를 삭제합니다:
1. Stop (STOP SLAVE) and delete (RESET SLAVE ALL) all slave connections.
2. Enable the read_only-flag.
4. Delete binary logs (RESET MASTER).
5. Set the sequence number of gtid_slave_pos to zero. This also affects
gtid_current_pos.
2. new Master 준비:
1. Disable the read_only-flag.
2. Enable scheduled server events (if event handling is on). Reset-replication 작업을
시작할 때 클러스터에 Master 서버가있 는 경우에만 이벤트가 활성화됩니다. Old
Master 에서 활성화 된 이벤트만 new Master 에서 활성화됩니다.
3. 다른 작업에서와 같이 new Master 에서 replication 하도록 다른 서버에 지시합니다.
- Manual activation
REST API 또는 MaxCtrl 을 통해 클러스터 작업을 수동으로 활성화 할 수 있습니다. 이 명령은
MaxScale 이 active 모드 일 때만 수행됩니다. 이 명령은 일반적으로 automatic 실행과
일치합니다. rejoin 은 예외입니다. 이 경우 수동 명령을 사용하면 join 하는 서버에 gtid 가
비어있는 경우에도 rejoin 할 수 있습니다. 이 규칙을 사용하면 사용자가 binary log 없이 서버에
강제로 다시 join 할 수 있습니다.
모든 명령에는 첫 번째 매개 변수로 Monitor 인스턴스 이름이 필요합니다. Failover 는 new
Master 서버를 자동으로 선택하며 추가 매개 변수가 필요하지 않습니다. Rejoin 에는 두 번째

26
매개 변수로 참여하는 서버의 이름이 필요합니다. Reset-replication 은 new Master 서버의 이름을
두 번째 매개 변수로 허용합니다. 지정하지 않으면 현재 Master 가 선택됩니다.
Switchover 는 1 ~ 3 개의 매개 변수를 사용합니다. Monitor 이름 만 제공되는 경우 switchover 는
promote 할 slave 와 demote 할 서버로 현재 Master 를 모두 자동 선택합니다. 두 개의 매개
변수가 제공되면 두 번째 매개 변수는 promote 할 slave 로 해석됩니다. 세 개의 매개 변수가
제공되면 세 번째 매개 변수가 현재 Master 로 해석됩니다. 사용자가 제공 한 현재 Master 는
현재 Monitor 에 의해 추론 된 Master 서버와 비교되며 둘이 같지 않으면 오류가 발생합니다.
Example commands are below:
call command mariadbmon failover MyMonitor
call command mariadbmon rejoin MyMonitor OldMasterServ
call command mariadbmon reset-replication MyMonitor
call command mariadbmon reset-replication MyMonitor NewMasterServ
call command mariadbmon switchover MyMonitor
call command mariadbmon switchover MyMonitor NewMasterServ
call command mariadbmon switchover MyMonitor NewMasterServ OldMasterServ
명령은 표준 모듈 명령 구문을 따릅니다. 모두 첫 번째 매개 변수로 Monitor 구성 이름
(MyMonitor)이 필요합니다. Switchover 의 경우 마지막 두 매개 변수는 promote 할 서버
(NewMasterServ)와 demote 할 서버 (OldMasterServ)를 정의합니다. rejoin 을 위해서는 join 할
서버 (OldMasterServ)가 필요합니다. Reset-replication 을 위해서는 promote 할 서버
(NewMasterServ)가 필요 합니다.
자동 작업은 수동 작업과 동시에 수행 할 수 없으므로 자동 failover, switchover 또는 rejoin 이
활성화 된 상태에서 수동 작업을 수행하는 것이 안전합니다.
When a cluster modification is iniated via the REST-API, the URL path is of the form:
/v1/maxscale/modules/mariadbmon/<operation>?<monitor-instance>&<server-param1>&<server-
param2>
 <operation>은 명령의 이름입니다 : failover, switchover, rejoin 또는 reset-replication.
 <monitor-instance>는 MaxScale 구성 파일의 Monitor 섹션 이름입니다.

27
 <server-param1> 및 <server-param2>는 위에서 MaxCtrl 에 대해 설명한 서버 매개
변수입니다. Switchover 만 두 가지를 모두 허용하고, failover 에는 아무것도 필요하지
않으며 join 및 reset-replication 은 하나를 허용합니다.
MaxScale configuration file like
[Cluster1]
type=monitor
module=mariadbmon
servers=server1, server2, server3, server 4
...
with the assumption that server2 is the current master, then the URL path for making server4
the new master would be:
/v1/maxscale/modules/mariadbmon/switchover?Cluster1&server4&server2
Example REST-API paths for other commands are listed below.
/v1/maxscale/modules/mariadbmon/failover?Cluster1
/v1/maxscale/modules/mariadbmon/rejoin?Cluster1&server3
/v1/maxscale/modules/mariadbmon/reset-replication?Cluster1&server3
 Queued switchover
대부분의 클러스터 수정 명령은 작업이 성공하거나 실패 할 때까지 대기합니다. async-switchover
는 즉시 반환되므로 예외입니다. 그외에는 async-switchover가 일반 switchover 명령과 동일하게
작동합니다. 모듈 명령 fetch-cmd-result를 사용하여 대기중인 명령의 결과를 확인합니다. fetch-
cmd-result는 대기 여부에 관계없이 최신 수동 명령의 상태 또는 결과를 반환합니다.
maxctrl call command mariadbmon async-switchover Cluster1
OK
maxctrl call command mariadbmon fetch-cmd-result Cluster1
{
"links": {
"self": "http://localhost:8989/v1/maxscale/modules/mariadbmon/fetch-cmd-result"
},
"meta": "switchover completed successfully."
}

28
- Automatic activation
auto_failover 가 켜져 있으면 failover 가 자동으로 활성화 될 수 있습니다. 활성화는 Master 가
최소한 failcount 모니터 반복을 중단했을 때 시작됩니다. 클러스터를 수정하기 전에 Monitor 는
failover 를 위한 모든 전제 조건이 충족되었는지 확인합니다. 클러스터가 준비되지 않은 것
같으면 error 가 인쇄되고 다음 모니터 점검 중에 클러스터가 다시 확인됩니다.
Switchover 는 switchover_on_low_disk_space-setting 을 사용하여 자동으로 활성화 할 수도
있습니다. Master 서버의 디스크 공간이 부족하면 작업이 시작되지만 그렇지 않으면 운영 논리가
automatic failover 와 매우 유사합니다.
Rejoin 은 standalone 서버에서 replication 을 시작하거나 wrong Master (클러스터 마스터가 아닌
모든 서버)에서 replication 하는 slave 를 리디렉션하는 것을 의미합니다. 다시 join 된 서버는
현재 클러스터 Master 서버에서 replication 하도록 지정되어 replication 토폴로지를 1-Master-N-
slave 구성으로 강제합니다.
서버에 slave 연결이 없고 중지 된 연결도 없는 경우 서버는 standalone 으로 분류됩니다. slave IO
스레드가 연결되어 있지만 slave 에 표시된 Master 서버 ID 가 클러스터 Master ID 와 일치하지
않으면 서버가 wrong Master 에서 replication 됩니다. 또는 IO 스레드가 중지되었거나 연결 중일
수 있지만 Master 서버 호스트 또는 포트 정보가 클러스터 Master 정보와 다릅니다. 이러한
기준은 STOP SLAVE 가 아직 slave 를 standalone 으로 설정하지 않았음을 의미합니다.
auto_rejoin 이 활성화 된 상태에서 Monitor 는 위의 요구 사항과 일치하는 모든 서버에 다시 join
하려고 합니다. Rejoin 은 failcount 를 따르지 않으며 유효한 서버에 즉시 rejoin 을 시도합니다.
Rejoin 을 수동으로 활성화 할 때 사용자가 지정한 서버는 동일한 요구 사항을 충족해야합니다.
- Limitations and requirements
Switchover 및 failover 는 단순한 토폴로지만 이해합니다. 클러스터에 여러 Master, relay
Master 가 있거나 순환 토폴로지인 경우 작동하지 않습니다. 서버 클러스터는 심각한 replication
지연 없이 정상 작동하는 것으로 간주되며 클러스터를 수정하는 모든 명령이 몇 초 안에
완료됩니다 (backend_read_timeout 및 backend_write_timeout 보다 빠름).

29
백엔드는 모두 GTID 기반 replication 을 사용 해야하며 도메인 ID 는 switchover 또는 failover
중에 변경되지 않아야합니다. Master 와 slave 에는 slave 서버에 대한 추가 이벤트없이 잘
작동하는 GTID 가 있어야합니다.
Master 서버가 down 된 후에 MaxScale 이 시작된 경우 failover 를 수행 할 수 없습니다. 이는
MaxScale 이 new Master 를 적절하게 선택하기 위해 클러스터의 GTID 도메인과 일반적으로
replication 토폴로지에 대한 신뢰할 수있는 정보를 필요로하기 때문입니다.
Failover 로 인해 이벤트가 손실 될 수 있습니다. 새 이벤트를 하나 이상의 slave 에 보내기 전에
Master 가 down 되면 new Master 를 선택하면 해당 이벤트가 손실됩니다. Old Master 가 다시
온라인 상태가 되면 서버들이 다른 기록으로 이동했을 가능성이 높으며 old Master 는 더 이상
replication 클러스터에 join 할 수 없습니다.
데이터 손실 가능성을 줄이려면 semisynchronous replication 을 사용 하십시오. semisynchronous
모드에서 Master 는 클라이언트에게 승인을 반환하기 전에 slave 가 이벤트를 수신 할 때까지
기다립니다. 이것은 아직 clean filover 를 보장하지 않습니다. Master 가 트랜잭션을 준비한 후
slave 승인을 받기 전에 실패하면 크래시 복구의 일부로 준비된 트랜잭션을 커밋합니다. slave 가
이 트랜잭션을 실행한 적이 없기 때문에 old Master 가 slave 의 데이터가 달라질 수 있습니다.
자세한 내용은 Configuring the Master Wait Point 을 참조하십시오.
Master 의 계획된 shutdown 에서도 이벤트를 잃을 수 있습니다. 서버는 기본적으로 shutdown 할
때 모든 데이터가 slave 에 복제 될 때까지 기다리지 않고 대신 단순히 모든 연결을 닫습니다.
Slave 를 promote 시키려는 의도로 Master 를 종료하기 전에 먼저 switchover 을 실행하여 모든
데이터가 복제되었는지 확인하십시오. 서버 shutdown 에 대한 자세한 내용은 Binary Log Dump
Threads and the Shutdown Process 를 참조하십시오.
Switchover 를 위해서는 작업이 진행되는 동안 클러스터가 "frozen" 상태 이여야합니다. 이는
INSERT 또는 UPDATE 와 같은 데이터 수정 문이 실행되지 않고 Master 서버의 GTID 위치가
안정적이라는 것을 의미합니다. Switchover 가 시작되면 Monitor 는 old Master 백엔드에 전역
read_only 플래그를 설정하여 업데이트를 중지합니다. read_only 는 SUPER 권한을 가진
사용자에게 영향을 주지 않으므로 이러한 사용자는 switchover 중에 쓰기를 실행할 수 있습니다.
이러한 쓰기는 new Master 로 전환하기 전에 쓰기가 모든 slave 에 복제되지 않을 수 있으므로
replication 을 중단 할 가능성이 높습니다. 이를 방지하려면 일반적으로 업데이트를 수행하는
모든 사용자에게 SUPER 권한이 없어야 합니다. 보안 강화를 위해 전환 중 유일한 SUPER-user
세션은 MaxScale Monitor user 이여야 합니다.
Rejoin 과 failover / switchover 를 같이 사용하려면 백엔드에 log_slave_updates 가 켜져 있어야
합니다. 다시 join 하는 서버는 나머지 클러스터보다 뒤처 질 가능성이 있습니다. Rejoin 서버의

30
연결이 끊어진 순간부터 현재 클러스터 마스터에 binary log 가 없으면 rejoin 서버는
replication 을 계속할 수 없습니다. 이는 Master 가 변경되었고 new Master 에
log_slave_updates 가 설정되어 있지 않은 경우 문제가 됩니다.
Auto-failover 또는 auto-rejoin 과 같은 자동 클러스터 작업이 실패하면 모든 클러스터 수정
작업이 failcount 모니터 점검으로 비활성화되고 이후 작업을 다시 시도 할 수 있습니다.
클러스터가 이러한 작업에 적합하지 않은 경우에도 유사한 상황이 적용 됩니다. e.g. replication is
not using GTID.
- External master support
Monitor 는 클러스터의 서버가 external Master (Monitor 에서 모니터링하지 않는 서버)에서
replication 중인지 감지합니다. Replication 서버가 클러스터 Master 서버이면 클러스터 자체에
external Master 가 있는 것으로 간주됩니다.
Failover / switchover 가 발생하면 new Master 서버가 클러스터 external Master 서버에서
replication 되도록 설정됩니다. Replication 을 위한 사용자와 암호는 replication_user 및
replication_password 에 정의 할 수 있습니다. 사용 된 주소 및 포트는 이전 클러스터 Master
서버에서 SHOW ALL SLAVES STATUS 에 표시된 것입니다. Switchover 의 경우 old Master 는
토폴로지를 보존하기 위해 external 서버에서의 replication 도 중지합니다.
failover 후 new Master 는 external Master 에서 replication 됩니다. 장애가 발생한 old Master 가
다시 온라인 상태가 되면 external 서버에서도 replication 됩니다. 상황을 정상화하려면
auto_rejoin 을 켜거나 수동으로 rejoin 을 실행하십시오. 그러면 old Master 가 현재 클러스터
Master 로 리디렉션됩니다.
- Configuration parameters
 auto_failover
자동화 된 Master failover를 활성화합니다. 이 매개 변수는 부울 값으로 기본값은 false입니다.
자동 failover가 활성화되면 기존의 MariaDB Master-slave 클러스터는 old Master가 중단되고
failcount에 지정된 반복 횟수만큼 fail되면 자동으로 new Master를 선택합니다. MaxScale이
passive 인스턴스로 구성된 경우 failover가 발생하지 않습니다. MaxScale이 passive 모드에서 작
동하는 방법에 대한 자세한 내용은 failover_timeout에 대한 설명서를 참조하십시오.

31
Monitor user는 failover가 작동하려면 SUPER 및 RELOAD 권한이 있어야합니다.
 auto_rejoin
서버를 클러스터에 자동으로 join 할 수 있습니다. 이 매개 변수는 부울 값으로 기본값은
false 입니다.
활성화되면 Monitor 는 relay Master 에서 주 클러스터 Master 서버로 replication 하는 서버와
standalone 서버를 지정하여 1-Master-N-slave 구성을 적용합니다.
For example, consider the following event series.
1. Slave A goes down
2. Master goes down and a failover is performed, promoting Slave B
3. Slave A comes back
Slave A 는 failover 중 온라인 상태가 아니기 때문에 down 된 Master 에서 replication 을
시도하고 있습니다. auto_rejoin 이 켜져 있으면 slave A 가 현재 Master 인 slave B 로 빠르게
리디렉션됩니다.
 switchover_on_low_disk_space
이 기능은 기본적으로 비활성화되어 있습니다. 활성화 된 경우 Monitor 는 slave 를 사용하여
디스크 공간이 부족한 Master 서버를 switchover 하려고 시도합니다. 디스크 공간 문제가 없는
slave 가 발견 된 경우에만 switchover 가 수행됩니다. maintenance_on_low_disk_space 도 활성화
된 경우 old Master (현재는 slave)가 다음 모니터 점검 중에 maintenance 됩니다.
이 매개 변수가 적용 되려면 서버 또는 Monitor 에 대해 disk_space_threshold 를
지정해야합니다. 또한 Monitor 에 대해 disk_space_check_interval 을 정의해야합니다.
switchover_on_low_disk_space=true
 enforce_simple_topology

32
이 설정은 Monitor 에서 서버가 1-Master -N-slave 토폴로지로 배열 되어야 한다고 가정하고
Monitor 는 이를 유지 하도록 합니다. forced_simple_topology 가 활성화 된 경우,
assume_unique_hostnames, auto_failover 및 auto_rejoin 도 개별 설정에 관계없이 활성화됩니다.
이 설정을 통해 Monitor 는 Master 서버가 [Running]으로 보이지 않는 클러스터로 failover 를
수행 할 수도 있습니다. 이는 일반적으로 MaxScale 이 시작되기 전에 Master 가 down 되는
경우입니다. 이 기능을 사용할 때 Monitor 는 slave 에서 Master 의 GTID 도메인 ID 를
추측합니다. 신뢰할 수있는 결과를 얻으려면 클러스터의 GTID 는 간단 해야 합니다.
enforce_simple_topology=true
 replication_user and replication_password
Replication의 사용자 이름과 비밀번호입니다. CHANGE MASTER TO 명령이 실행될 때마다
MASTER_USER 및 MASTER_PASSWORD의 값으로 제공됩니다.
Replication 사용자를 사용하는 경우 replication_user 및 replication_password 매개 변수를 모두
정의해야합니다. 매개 변수가 정의되지 않은 경우 CHANGE MASTER TO 명령은 Replication 사
용자에 대한 Monitor 사용자를 사용합니다.
Replication 사용자에는 REPLICATION SLAVE 권한이 있어야합니다.
replication_password는 다른 암호 매개 변수와 동일한 암호화 체계를 사용합니다. 비밀번호 암
호화를 사용하는 경우 잘못된 암호 해독을 방지하기 위해 replication_password를 동일한 키로
암호화 해야 합니다.
 replication_master_ssl
Type: bool Default: off
ON으로 설정하면 생성 된 CHANGE MASTER TO 명령은 복제 스트림에 대한 암호화를 활성화
하기 위해 MASTER_SSL = 1을 설정합니다. 이 설정은 백엔드 서버가 SSL 용으로 구성된 경우에
만 활성화 해야 합니다. 이는 일반적으로 서버 구성 파일에서 ssl_ca, ssl_cert 및 ssl_key를 설정
하는 것을 의미합니다. 또한 복제 사용자의 자격 증명에는 암호화 된 연결이 필요합니다 (e.g.
ALTER USER repl@'%' REQUIRE SSL;).
설정이 OFF 인 경우 MASTER_SSL이 전혀 설정되지 않으므로 slave 연결을 리디렉션 할 때 기
존 설정이 유지됩니다.

33
 Failover_timeout and switchover_timeout
Failover 및 switchover 작업에 대한 timeout. 둘 다 기본값은 90 초입니다. switchover_timeout
은 rejoin 작업의 timeout으로도 사용됩니다. rejoin은 switchover보다 빠른 작업이므로 timeout
이 거의 발생하지 않습니다.
timeout은 여기에 설명 된대로 지정됩니다. 단위를 지정하지 않으면 MaxScale 2.4에서 값이 초
로 해석됩니다. 이후 버전에서는 단위가 없는 값이 거부 될 수 있습니다. timeout의 단위는 초
이므로 기간이 1 초보다 길더라도 밀리 초 단위로 지정된 timeout이 거부됩니다.
설정된 시간 내에 성공적인 failover / switchover가 발생하지 않으면 메시지가 기록되고
automatic failover가 비활성화됩니다. 이는 오작동하는 클러스터에 대한 추가 자동 수정을 방지
합니다.
 Verify_master_failure and master_failure_timeout
Automatic failover를 위해 추가 Master 오류 확인을 활성화합니다. verify_master_failure는 이 기
능을 활성화하는 부울 값 (기본값 : true)이며 master_failure_timeout은 timeout(기본값 : 10 초)
을 정의합니다.
Master failure timeout은 여기에 설명 된대로 지정됩니다. 단위를 지정하지 않으면 MaxScale 2.4
에서 값이 초로 해석됩니다. 이후 버전에서는 단위가없는 값이 거부 될 수 있습니다. timeout
단위는 초이므로 기간이 1 초보다 길더라도 밀리 초로 지정된 timeout은 거부됩니다.
장애 확인은 slave 서버가 여전히 Master에 연결되어 있고 이벤트를 수신하는지 확인하여 수행
됩니다. 이벤트는 SHOW SLAVE STATUS 출력의 Gtid_IO_Pos 필드의 변경 또는 heartbeat 이벤트
입니다. 실제로 slave가 master_failure_timeout 기간 내에 이벤트를 수신 한 경우 MaxScale이
Master에 연결할 수 없더라도 failover 여부를 결정할 때 Master가 down 된 것으로 간주되지
않습니다. master_failure_timeout이 유효하려면 slave 연결의 Slave_heartbeat_period보다 길어야
합니다.
모든 slave가 Master와의 연결이 끊어지면 (Slave_IO_Running이 "Yes"가 아님) timeout에 관계없
이 Master 장애가 확인 된 것으로 간주됩니다. 이것은 Master가 적절하게 연결을 끊을 때 더
빠른 failover를 허용합니다.
Automatic failover가 시작 되려면 failcount 요구 사항도 충족 되어야 합니다.

34
 Server_no_promotion
failover 중 Master promotion을 위해 선택되지 않거나 switchover을 위해 자동 선택되지 않는
쉼표로 구분 된 서버 이름 목록입니다. 사용자가 promote 할 서버를 선택하는 경우 switchover
에 영향을 주지 않습니다. 이 설정을 사용하면 최적이 아닌 서버가 선택되도록 failover를 위한
new Master 선택이 중단 될 수 있습니다. 최악의 경우 replication가 중단됩니다. 또는 모든 유
효한 promotion 후보가 제외 목록에있는 경우 failover가 실패 할 수 있습니다.
servers_no_promotion=backup_dc_server1,backup_dc_server2
 Promotion_sql_file and demotion_sql_file
선택적 설정으로 SQL 문이있는 텍스트 파일의 경로입니다. promotion 또는 demotion 중에 콘
텐츠를 한 줄씩 읽고 백엔드에서 실행합니다. 이 설정을 사용하여 built-in 작업을 보완하기 위
해 서버에서 사용자 지정 문을 실행합니다.
빈 줄 또는 '#'로 시작하는 줄은 무시됩니다. 명령문에서 반환 된 모든 결과는 무시됩니다.
failover, switchover 또는 rejoin을 계속 하려면 모든 명령문이 성공해야합니다. Monitor user는
사용자 정의 명령이 성공하기 위해 추가 privileges 및 grant가 필요할 수 있습니다.
failover 또는 switchover 중에 slave를 Master로 promote 할 때 read-only 설정이 비활성화 된
후 new Master 서버에서 promotion_sql_file을 읽고 실행합니다. 명령은 external Master에서
replication을 시작하기 전에 실행됩니다.
demotion_sql_file은 old Master가 new Master에서 replication를 시작하기 전에 slave로 demote
하는 동안 old Master에서 실행됩니다. standalone 서버는 일반적으로 old Master 서버이므로
standalone 서버를 클러스터에 다시 결합하기 전에 파일이 실행됩니다. Wrong Master에서
replication하는 slave를 리디렉션 할 때 sql-file은 실행되지 않습니다.
파일의 쿼리는 replication 토폴로지를 수정하는 작업 중에 실행 되므로 주의가 필요합니다.
promotion_sql_file에 데이터 수정 (DML) 쿼리가 포함 된 경우 new Master 서버는 external
Master에서 성공적으로 replication 하지 못할 수 있습니다. demotion_sql_file은 slave 스레드가
중지되기 전에 slave 서버로 복제가 되지 않아 replication이 중단 될 수 있으므로 DML 쿼리를
포함해서는 안됩니다.
promotion_sql_file=/home/root/scripts/promotion.sql
demotion_sql_file=/home/root/scripts/demotion.sql

35
 Handle_events
이 설정은 기본적으로 켜져 있습니다. 활성화 된 경우 Monitor는 활성화 된 예약 된 event에
대해 서버를 지속적으로 쿼리하고 클러스터 작업을 수행 할 때 이 정보를 사용하여 적절한
event를 활성화 및 비활성화합니다.
서버가 demote 될 때 "ENABLED" 상태의 모든 event는 "SLAVESIDE_DISABLED"로 설정됩니다.
서버가 Master로 promote 될 때 마지막으로 성공적으로 쿼리되었을 때 old Master 서버에서
도 동일한 event가 활성화 된 경우 "SLAVESIDE_DISABLED"또는 "DISABLED"인 event는
"ENABLED"로 설정됩니다. 동일한 스키마와 이름을 가진 event는 동일한 것으로 간주됩니다.
standalone 서버가 클러스터에 다시 참여하면 이제 slave 이므로 해당 event도 비활성화됩니
다.
Monitor는 failover 또는 switchover / rejoing 중에 동일한 event가 비활성화 및 활성화 되었
는지 여부를 확인하지 않습니다. 위의 기준을 충족하는 모든 event가 변경됩니다.
Monitor는 event scheduler 자체를 활성화 하거나 비활성화 하지 않습니다. New Master 서버
에서 event를 실행하려면 관리자가 event scheduler를 활성화 해야 합니다. 서버 구성 파일에
서 활성화하는 것을 권고합니다.
높은 빈도로 실행되는 event로 인해 failover 시나리오에서 replication이 중단 될 수 있습니다.
failover 된 old Master가 다시 시작되면 서버 구성 파일에 설정된 경우 event scheduler가 켜
집니다. event는 또한 "ENABLED" 상태를 기억하고 예약 된 시간에 실행됩니다. 이는 Monitor
가 서버에 다시 참여하고 event를 비활성화하기 전에 발생할 수 있습니다. 이는 Monitor 간
격보다 더 자주 실행되는 event 또는 서버가 다시 시작된 직후에 실행되는 event에 대해서
문제가 됩니다.
5) Cooperative monitoring
MaxScale 2.5부터 MariaDB-Monitor는 협력 모니터링을 지원합니다. 즉, 여러 Monitor (일반적으로
다른 MaxScale 인스턴스에 있음)가 동일한 백엔드 서버 클러스터를 모니터링 할 수 있으며 하나
만 기본 Monitor가 됩니다. Primary Monitor만 failover, switchover 또는 rejoint 작업을 수행 할 수
있습니다. 또한 primary MaxScale은 Master 서버를 결정합니다. cooperative_monitoring_locks-
setting으로 협력 모니터링이 활성화됩니다. 이 설정을 사용하더라도 MaxScale은 서버 당 하나의

36
Monitor 만 허용됩니다. 이 제한은 구성 파일에서 서버의 여러 복사본을 정의하여 피할 수 있습
니다.
협력 모니터링은 Monitor 간 조정을 위해 서버 잠금을 사용합니다. 협력 할 때 Monitor는 모든
서버에서 maxscale_mariadbmonitor라는 이름의 잠금 상태를 정기적으로 확인하고 사용 가능한
경우 이를 획득합니다. Monitor가 대부분의 잠금을 획득하면 이것이 primary입니다. Monitor가 과
반수 잠금을 요구할 수 없는 경우 secondary Monitor 입니다.
클러스터의 primary Monitor는 Master 서버에서 maxscale_mariadbmonitor_master 잠금도 획득합
니다. Secondary Monitor는 이 잠금이 적용된 서버를 확인하고 해당 서버 만 Master로 허용합니
다. replication 토폴로지에 관계없이 Master가 되는 서버에 대해 여러 Monitor가 동의 할 수 있도
록 이러한 배열이 필요합니다. Secondary Monitor가 Master 잠금을 확인하지 않으면 어떤 서버도
[Master]로 표시하지 않아 쓰기가 실패합니다.
잠금 설정은 primary 상태에 필요한 잠금 수를 정의합니다. cooperative_monitoring_locks =
majority_of_all 설정은 primary Monitor에 n_servers / 2 + 1 (반올림) 잠금이 필요함을 의미합니다.
예를 들어, 3 개의 서버로 구성된 클러스터에는 다수의 경우 2 개의 잠금이 필요하고 4 개의 클
러스터에는 3 개의 클러스터가 필요하며 5 개의 클러스터에는 3 개가 필요합니다. 이 체계는 여
러 Monitor가 동시에 primary가 될 수 없다는 점에서 split-brain 상황을 방지합니다. 그러나 분할
로 인해 두 Monitor 모두 자신을 secondary로 간주 할 수 있으며 이 경우 Master 서버가 감지되
지 않습니다. 또한 너무 많은 서버가 다운되면 두 Monitor 모두 잠금 과반수를 요구할 수 없습니
다.
cooperative_monitoring_locks = majority_of_running을 설정하면 n_servers가 계산되는 방식이 변
경됩니다. 총 서버 수를 사용하는 대신 현재 [Running] 서버 만 고려됩니다. 이 체계는 down 되
는 여러 서버에 적응하여 잠금 과반수를 주장하는 것이 항상 가능 하도록 합니다. 그러나 split-
brain 상황에서 primary 상태를 주장하는 여러 Monitor로 이어질 수 있습니다. 예를 들어,
MaxScales A 및 B가있는 서버 1 ~ 4가 있는 클러스터를 고려하십시오. A가 1과 2에는 연결할 수
있지만 3과 4에는 연결할 수 없는 반면 B는 반대의 경우 두 MaxScales는 두 개의 실행중인 서버
에서 두 개의 잠금을 요구합니다. . 그러면 두 개의 MaxScale이 쓰기를 다른 서버로 라우팅합니다.
권장 전략은 어떤 실패 시나리오가 더 가능성이 높거나 더 destructive 적인지에 따라 다릅니다.
여러 대의 서버가 동시에 down 될 가능성이 희박하다면 most_of_all이 더 안전한 선택 일 것입니
다. 반면에 split-brain이 발생하지 않을 가능성이 있지만 여러 서버가 동시에 다운 될 수있는 경
우, major_of_running은 클러스터 작동을 유지합니다.
Monitor가 primary인지 확인하려면 maxctrl show를 사용하여 Monitor 진단을 가져옵니다.
Monitor 또는 REST API. 부울 필드 primary는 모니터가 클러스터에서 과반수 잠금을 가지고 있는

37
지 여부를 나타냅니다. 협력 모니터링이 비활성화 된 경우 필드 값은 null입니다. 개별 서버에 대
한 잠금 정보는 서버 별 필드 lock_held에 나열됩니다. 다시 null은 잠금이 사용 중이 아니거나 잠
금 상태를 알 수 없음을 나타냅니다.
primary는 Monitor가 클러스터에서 과반수 잠금을 가지고 있는지 여부를 나타냅니다. 협력 모니
터링이 비활성화 된 경우 필드 값은 null입니다. 개별 서버에 대한 잠금 정보는 서버 별 필드
lock_held에 나열됩니다. 다시 null은 잠금이 사용 중이 아니거나 잠금 상태를 알 수 없음을 나타
냅니다.
- Releasing locks
Monitor 협력은 서버 잠금에 따라 다릅니다. 잠금은 연결별로 다릅니다. 소유 연결은 수동으로 잠
금을 해제하여 다른 연결이 이를 요청할 수 있도록합니다. 또한 소유 연결이 닫히면 MariaDB 서
버 프로세스가 잠금을 해제합니다. 끊어진 연결이 감지되는 속도는 primary Monitor 상태가 한
Monitor와 MaxScale에서 다른 Monitor로 이동하는 속도에 영향을줍니다.
Primary MaxScale 또는 해당 Monitor가 정상적으로 중지되면 Monitor 연결이 제대로 닫히고 잠
금이 해제됩니다. 이를 통해 secondary MaxScale이 신속하게 잠금을 요청할 수 있습니다. 그러나
primary가 단순히 사라지면 (네트워크가 끊어짐) 연결이 idel 상태로 보일 수 있습니다. 이 경우
MariaDB 서버는 Monitor 연결이 끊어진 것으로 간주하기까지 오랜 시간이 걸릴 수 있습니다. 이
시간은 궁극적으로 MariaDB-server를 실행하는 컴퓨터의 TCP keepalive 설정에 따라 다릅니다.
MariaDB-server 10.3.3 이상에서는 서버 프로세스에 대해서만 TCP keep 설정을 구성 할 수 있습니
다. tcp_keepalive_interval, tcp_keepalive_probes 및 tcp_keepalive_time 설정에 대한 정보는 서버
시스템 변수를 참조하십시오. 이러한 설정은 여기에 설명 된대로 OS 수준에서도 설정할 수 있습
니다.
Monitor는 모듈 명령 release-locks를 통해 수동으로 잠금을 해제 하도록 할 수도 있습니다. 이것
은 primary Monitor를 수동으로 변경할 때 유용합니다. release-command를 실행 한 후 Monitor는
시작할 primary Monitor가 아니더라도 1 분 동안 잠금을 다시 획득 하려고 시도하지 않습니다.
이 명령으로 인해 MaxScale에서 클러스터를 일시적으로 사용 할 수 없게 될 수 있습니다. 잠금을
요청할 준비가 된 다른 Monitor가 있을 때만 사용하십시오.
maxctrl call command mariadbmon release-locks MyMonitor1

38
6) Troubleshooting
- Failover / switchover fails
failover 또는 switchover를 수행하기 전에 MariaDB Monitor는 먼저 전제 조건이 충족되었는지 확
인하고 발견 된 error를 인쇄합니다. 이는 failover 또는 switchover가 작동하지 않는 대부분의 문
제를 파악하고 설명합니다. 조작을 시도했지만 여전히 실패하면 Monitor가 서버에 수행 한 명령
중 하나가 실패 했거나 timeout 되었을 가능성이 높습니다. 로그는 실패한 쿼리를 설명 합니다.
서버로 전송 된 모든 쿼리를 인쇄하려면 --debug = enable-statement-logging을 사용하여
MaxScale을 시작하십시오. 이 설정은 Monitor 및 authenticator가 백엔드로 보낸 모든 쿼리를 인
쇄합니다.
실패의 일반적인 이유는 STOP SLAVE와 같은 명령이 Monitor의 backend_read_timeout보다 오래
걸려서 연결이 끊어지기 때문입니다. 2.3부터 Monitor는 timeout으로 인해 오류가 발생한 경우 대
부분의 쿼리를 다시 시도합니다. 재 시도는 failover 또는 switchover의 총 시간까지 계속됩니다.
로그에 명령 시간 초과에 대한 경고 또는 오류가 표시되는 경우 Monitor의 백엔드 timeout 설정
을 늘리면 도움이 됩니다. 살펴볼 또 다른 설정은 query_retries 및 query_retry_timeout입니다. 구
성 가이드에 설명 된 일반적인 MaxScale 설정입니다. query_retries를 2로 설정하고 다시 시도를
해 볼 필요가 있습니다.
- Slave detection shows external masters
slave가 maxctrl에서 "Slave"대신 "Slave of External Server"로 표시되면 replication 연결의
"Master_Host" 설정이 MaxScale 서버 정의와 일치하지 않기 때문 일 수 있습니다. 2.3.2부터
MariaDB Monitor는 기본적으로 slave 연결 (SHOW ALL SLAVES STATUS로 표시)이 MaxScale 구성
파일 서버 정의에 사용 된 것과 똑같은 "Master_Host"를 사용한다고 가정합니다. 이것은
assume_unique_hostnames 설정에 의해 제어됩니다.
7) Using the MariaDB Monitor With Binlogrouter
MaxScale 2.2부터는 Binlog Server를 포함하는 replication 설정을 감지 할 수 있습니다. 필요한 작
업은 master_id가 동일하게 설정된 경우에만 binlog 서버를 서버 목록에 추가하는 것입니다.

40
4. Galera Monitor
https://mariadb.com/kb/en/mariadb-maxscale-25-galera-monitor/
Galera Monitor 는 Galera 클러스터를 모니터링하는 MaxScale 용 모니터링 모듈입니다. 노드가
클러스터의 일부인지 여부와 나머지 클러스터와 동기화되어 있는지 감지합니다. 또한 MaxScale
내에서 Master 및 slave 역할을 할당 할 수 있으므로 Galera 클러스터를 기존 Master-slave
클러스터 용으로 설계된 모듈과 함께 사용할 수 있습니다.
기본적으로 Galera Monitor 는 가장 낮은 wsrep_local_index 값을 가진 노드를 Master 로
선택합니다. 이는 서로 다른 서버에서 실행되는 두 개의 MaxScale 이 Master 와 동일한 서버를
선택 함을 의미합니다.
 Galera clusters and slaves replicating from it
MaxScale 2.4.0은 Galera 노드에서 복제되는 slave에 대한 지원을 추가했습니다. galeramon에서 모
니터링하는 비 Galera 서버가 galeramon에서도 모니터링되는 Galera 노드에서 replication 되는
경우 복제가 작동하는 한 Slave, Running 상태가 할당됩니다. 이를 통해 Galera 클러스터의 크기
를 늘리지 않고도 Galera 서버로 읽기 확장이 가능합니다.
1) Configuration
Monitor에 대한 최소 구성에는 모니터링을위한 서버 세트와 이러한 서버에 연결 하기위한 사용자
이름 및 비밀번호가 필요합니다. 사용자는 서버 상태를 성공적으로 모니터링하려면 REPLICATION
CLIENT 권한이 필요합니다.
[Galera-Monitor]
type=monitor
module=galeramon
user=myuser
password=mypwd

41
2) Galera Monitor optional parameters
 disable_master_failback
MaxScale 내부에서 Master로 표시된 노드가 실패하고 Master 상태가 다른 노드에 할당 된 경
우 MaxScale은 일반적으로 백업 후 Master 상태를 원래 노드로 반환합니다. 이 옵션을 활성화
하면 Master 상태가 새 노드에 할당되면 new Master 노드가 실행되는 동안 원래 노드에 다시
할당되지 않습니다.
disable_master_failback=true
 available_when_donor
이 옵션을 사용하면 SST 방법이 non-blocking 이고 (예 : wsrep_sst_method = mariabackup) SST
작업이 donor에서 할때 Galera 노드를 정상적으로 사용할 수 있습니다.
일반적으로 SST가 수행되면 참여하는 두 노드 모두 동기화 됨, Master 또는 slave 상태를 잃게
됩니다. 이 옵션이 활성화되면 donor는 클러스터의 일반 구성원 인 것처럼 처리됩니다 (예 :
wsrep_local_state = 4). 이는 클러스터가 한 노드로 떨어지고 클러스터 크기를 늘리기 위해 SST
가 필요한 경우 특히 유용합니다.
현재 non-blocking SST 방법은 xtrabackup, xtrabackup-v2 및 mariabackup입니다. 자세한 내용
은 wsrep_sst_method 문서를 읽으십시오.
available_when_donor=true
 disable_master_role_setting
Galera 클러스터 노드에 Master 및 slave 역할 할당이 비활성화됩니다. 이 옵션을 사용하면
synced가 Monitor에 의해 할당 된 유일한 상태입니다.
disable_master_role_setting=true
 user_priority
서버 우선 순위와의 상호 작용을 활성화합니다. Monitor가 모니터링되는 Galera 클러스터에 대
한 쓰기 노드를 deterministically하게 선택할 수 있으며 제어 된 노드 교체가 가능합니다.

42
use_priority=true
 root_node_as_master
쓰기 Master Galera 노드에 wsrep_local_index 값 0이 필요한지 여부를 제어합니다. 이 옵션은
MaxScale 2.1.0에서 도입되었으며 버전 2.1.5 이상에서는 기본적으로 비활성화되어 있습니다.
2.1.4 및 이전 버전에서는이 옵션이 기본적으로 활성화되었습니다.
Galera 클러스터에는 항상 wsrep_local_index 값이 0 인 노드가 있습니다. 이 정보를 기반으로
여러 MaxScale 인스턴스는 쓰기를 위해 항상 동일한 노드를 선택할 수 있습니다.
galeramon에 대해 root_node_as_master 옵션이 비활성화 된 경우 인덱스가 가장 낮은 노드가
항상 Master로 선택됩니다. 활성화 된 경우 wsrep_local_index 값이 0 인 노드 만 Master로 선
택할 수 있습니다.
 set_donor_nodes
slave 상태의 각 클러스터 노드에 전역 변수 wsrep_sst_donor를 설정 해야 하는지 여부를 제어
합니다. 변수에는 가능한 Master 후보가 끝에 자동으로 정렬 된 slave 서버 목록이 포함됩니다.
정렬은 use_priority 옵션 값에 따라 wsrep_local_index 또는 노드 서버 우선 순위를 기반으로합
니다. 우선 순위가 정의 된 서버가 없으면 정렬이 wsrep_local_index로 전환됩니다.
wsrep_node_name 변수의 결과를 가져 와서 노드 이름을 수집합니다.
Example of variable being set in all slave nodes, assuming three nodes:
SET GLOBAL wsrep_sst_donor = "galera001,galera000"
Note: 전역 변수 wsrep_sst_donor를 설정하려면 클러스터 노드에 연결하는 모니터 사용자에게
적절한 권한이 필요합니다. 이 옵션은 기본적으로 비활성화되어 있으며 MaxScale 2.1.0에서 도
입되었습니다.
set_donor_nodes=true

43
3) Interation with Server Priorities
use_priority 옵션이 설정되고 서버가 priority = <int> 매개 변수로 구성된 경우 galeramon 은
이를 Master 노드가 선택되는 기준으로 사용합니다. disable_master_role_setting 은 정의되지
않거나 비활성화 되어야 합니다. 대체 Galera 노드가 MaxScale 내부의 Master 서버로 promote
될 때 우선 순위의 가장 낮은 양수 값을 가진 서버가 Master 노드로 선택됩니다. 모든 후보
서버의 우선 순위가 동일한 경우 servers 매개 변수의 순서에 따라 Master 로 서버가 결정됩니다.
양수가 아닌 값 (우선 순위 <= 0)을 가진 노드는 Master 로 선택되지 않습니다. 이를 통해 양수가
아닌 값을 우선 순위에 할당하여 일부 서버를 영구 slave 로 표시 할 수 있습니다.
Here is an example.
[node-1]
type=server
address=192.168.122.101
port=3306
priority=1
[node-2]
type=server
address=192.168.122.102
port=3306
priority=3
[node-3]
type=server
address=192.168.122.103
port=3306
priority=2
[node-4]
type=server
address=192.168.122.104
port=3306
priority=0
이 예에서 node-1 은 사용 가능한 경우 항상 Master 로 사용됩니다. node-1 을 사용할 수 없는
경우 우선 순위가 가장 높은 node-3 이됩니다. node-1 과 node-3 이 모두 작동 중지 된 경우
node-2 가 사용됩니다. node-4 의 우선 순위 값은 0 이므로 Master 가 되지 않습니다. 우선 순위
매개 변수가 없는 노드는 우선 순위가 가장 낮은 것으로 간주되며 우선 순위 매개 변수가있는
모든 노드를 사용할 수없는 경우에만 사용됩니다. 우선 순위를 사용하면 MaxScale 이 Master
노드를 선택하는 순서를 제어 할 수 있습니다. 이를 통해 장애 대응 및 노드 교체가 가능합니다.

44
5. ColumnStore Monitor
https://mariadb.com/kb/en/mariadb-maxscale-25-columnstore-monitor/
ColumnStore Monitor인 csmon은 MariaDB ColumnStore 서버용 Monitor 모듈입니다. 여러 UM 노
드를 지원하며 Master로 레이블이 지정된 DML / DDL 문에 대한 해당 서버로 명령을 수행 할 수
있습니다. 다른 UM 노드는 읽기에 사용됩니다.
1) Required Grants
사용자 매개 변수로 정의 된 user에는 infinidb_vtable 데이터베이스에 대한 모든 권한이 있어야합
니다.
For example, to create a user for this monitor with the required grants execute the following SQL.
CREATE USER 'maxuser'@'%' IDENTIFIED BY 'maxpwd';
GRANT ALL ON infinidb_vtable.* TO 'maxuser'@'%';
2) Master Selection
MaxScale 2.5의 Columnstore Monitor는 Columnstore 1.0, 1.2 및 1.5를 지원하며 Master 선택은 각
버전마다 다르게 수행됩니다.
 If the version is 1.0, the master server must be specified using the primary parameter.
 If the version is 1.2, the master server is selected automatically using the Columnstore
function mcsSystemPrimary().
 If the version is 1.5, the master server is selected automatically by querying the Columnstore
daemon running on each node.
3) Configuration
 version
이 필수 매개 변수를 사용하여 사용 된 Columnstore 버전이 지정됩니다. 허용되는 값은 1.0, 1.2
및 1.5입니다.

45
 primary
버전 값이 1.0 인 경우에 필수로 사용됩니다.
기본 매개 변수는 Master 서버로 선택되는 서버를 제어합니다.
이 매개 변수가 가리키는 서버가 사용 가능하고 쿼리를 처리 할 준비가 되면 Master 상태를 수
신합니다.
 admin port
1.5 버전인 경우에만 허용됩니다.
이 선택적 매개 변수는 Columnstore 관리 데몬의 포트를 지정합니다. 기본값은 8640입니다. 모
든 노드의 데몬은 동일한 포트에서 수신해야합니다.
 admin_ base_path
이 선택적 매개 변수는 Columnstore 관리 데몬의 기본 경로를 지정합니다. 기본값은
/cmapi/0.4.0 입니다.
 api_key
이 선택적 매개 변수는 Columnstore 관리 데몬과의 통신에 사용할 API 키를 지정합니다. 키를
지정하지 않으면 키가 생성되어 MaxScale의 데이터 디렉터리에 있는 Monitor와 동일한 이름의
디렉터리에 있는 api_key.txt 파일에 저장됩니다. 일반적으로 /var/lib/maxscale/<monitor-
section>/api_key.txt 입니다.
Columnstore는 제공된 첫 번째 키를 저장하고 이후 요청을 합니다. 키를 변경하려면
Columnstore 노드에서도 키를 재설정 해야 합니다.
 local_address

46
이 매개 변수를 사용하여 IP MaxScale이 상주하는 Columnstore 노드에 알려야 하는 IP
MaxScale을 지정합니다. MaxScale 구성 파일의 전역 수준에서 local_address를 지정해야합니다.
둘 다 지정된 경우 Monitor에 지정된 것이 대체됩니다.
4) Commands
Columnstore Monitor는 Columnstore 클러스터를 관리 할 수있는 모듈 명령을 제공합니다. 명령
은 curl과 같은 클라이언트와 함께 REST-API를 사용하거나 maxctrl을 사용하여 호출 할 수 있습니
다.
모든 명령에는 첫 번째 매개 변수로 Monitor 인스턴스 이름이 필요합니다. 명령에 따라 추가 매
개 변수를 제공해야합니다.
maxctrl 자체에는 10 초의 제한 시간이 있으므로 명령에 제공되는 제한 시간보다 큰 제한 시간이
있으면 maxctrl의 제한 시간도 늘려야 합니다. For instance:
maxctrl --timeout 30s call command csmon shutdown CsMonitor 20s
maxctrl에 대해 30초 제한 시간이 지정해서 종료 명령에 대해 제공된 제한 시간 20초 전에 만료
되지 않도록합니다. 출력은 항상 JSON 객체입니다.
In the following, assume a configuration like this:
[CsNode1]
type=server
...
[CsNode2]
type=server
...
[CsMonitor]
type=monitor
module=csmon
servers=CsNode1,CsNode2
...
 start
Starts the Columnstore cluster.

47
call command csmon start <monitor-name> <timeout>
Example
call command csmon start CsMonitor 20s
 shutdown
Shuts down the Columnstore cluster.
call command csmon shutdown <monitor-name> <timeout>
Example
call command csmon shutdown CsMonitor 20s
 status
Get the status of the Columnstore cluster.
call command csmon status <monitor-name> [<server>]
Returns the status of the cluster or the status of a specific server.
Example
call command csmon status CsMonitor
call command csmon status CsMonitor CsNode1
 mode-set
Sets the mode of the cluster.
call command csmon mode-set <monitor-name> (readonly|readwrite) <timeout>
Example
call command csmon mode-set CsMonitor readonly 20s

48
 config-get
Returns the cluster configuration.
call command csmon config-get <monitor-name> [<server-name>]
If no server is specified, the configuration is fetched from the first server in the monitor
configuration, otherwise from the specified server.
Note that if everything is in order, the returned configuration should be identical regardless of
the server it is fetched from.
Example
call command csmon config-get CsMonitor CsNode2
 add-node
Adds a new node located on the server at the hostname or IP host to the Columnstore cluster.
call command csmon add-node <monitor-name> <host> <timeout>
Example
call command csmon add-node CsMonitor mcs2 20s
 remove-node
Remove the node located on the server at the hostname or IP host from the Columnstore cluster.
call command csmon remove-node <monitor-name> <host> <timeout>
Example
call command csmon remove-node CsMonitor mcs2 20s

49
4) Example
The following is an example of a csmon configuration.
[CSMonitor]
type=monitor
module=csmon
version=1.5
user=myuser
passwd=mypwd
monitor_interval=5000
api_key=somekey1234
- Adding a Node
Adding a new node to a Columnstore cluster can be performed dynamically at runtime, but it must
be done in two steps. First, the node is added to Columnstore and then, the corresponding server
object (that possibly has to be created) in the MaxScale configuration is added to the Columnstore
monitor.
In the following, assume a two node Columnstore cluster and an initial MaxScale configuration like.
[CsNode1]
type=server
...
[CsNode2]
type=server
...
[CsMonitor]
type=monitor
module=csmon
...
Invoking maxctrl list servers will now show:
┌────────────┬────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────────┼────────────────────────┤
│ CsNode1 │ 10.10.10.10 │ 3306 │ 0 │ Master, Running │ │
├────────────┼────────────────────────┤
│ CsNode2 │ 10.10.10.11 │ 3306 │ 0 │ Slave, Running │ │

50
└────────────┴────────────────────────┘
If we now want to add a new Columnstore node, located at mcs3/10.10.10.12 to the cluster, the
steps are as follows.
First the node is added
maxctrl --timeout 30s call command csmon add-node CsMonitor mcs3 20s
After a while the following is output:
{
"links": {
"self": "http://localhost:8989/v1/maxscale/modules/csmon/add-node"
},
"meta": {
"message": "Node mcs3 successfully added to cluster.",
"result": {
"node_id": "mcs3",
"timestamp": "2020-08-07 10:03:49.474539"
},
"success": true
}
}
At this point, the Columnstore cluster consists of three nodes. However, the Columnstore monitor
is not yet aware of the new node.
First we need to create the corresponding server object.
maxctrl create server CsNode3 10.10.10.12
Invoking maxctrl list servers will now show:
┌─────────────────────────────────────┐
├─────────────────────────────────────┤
│ CsNode3 │ 10.10.10.12 │ 3306 │ 0 │ Down │ │
├─────────────────────────────────────┤
├─────────────────────────────────────┤

51
└─────────────────────────────────────┘
The server CsNode3 has been created, but its state is Down since it is not yet being monitored.
┌─────────────────────┐
│ Monitor │ State │ Servers │
├─────────────────────┤
│ CsMonitor │ Running │ CsNode1, CsNode2 │
└─────────────────────┘
It must now be added to the monitor.
maxctrl link monitor CsMonitor CsNode3
Now the server is monitored and maxctrl list monitors shows:
┌─────────────────────────┐
├─────────────────────────┤
│ CsMonitor │ Running │ CsNode1, CsNode2, CsNode3│
└─────────────────────────┘
The state of the new node is now also set correctly, as shown by maxctrl list servers.
┌─────────────────────────────────────┐
├─────────────────────────────────────┤
├─────────────────────────────────────┤
├─────────────────────────────────────┤
└─────────────────────────────────────┘
Note that the MaxScale server object can be created at any point, but it must not be added to the
monitor before the node has been added to the Columnstore cluster using call command csmon
add-node.

52
- Removing a Node
Removing a node should be performed in the reverse order of how a node was added. First, the
MaxScale server should be removed from the monitor. Then, the node should be removed from the
Columnstore cluster.
Suppose we want to remove the Columnstore node at mcs2/10.10.10.12 and the current situation
is as:
┌─────────────────────────┐
├─────────────────────────┤
│ CsMonitor │ Running │ CsNode1, CsNode2, CsNode3│
└─────────────────────────┘
First, the server is removed from the monitor.
maxctrl unlink monitor CsMonitor CsNode3
Checking with maxctrl list monitors we see that the server has indeed been removed.
┌─────────────────────┐
├─────────────────────┤
│ CsMonitor │ Running │ CsNode1, CsNode2 │
└─────────────────────┘
Now the node can be removed from the cluster itself.
maxctrl --timeout 30s call command csmon remove-node CsMonitor mcs3 20s
{
"links": {
"self": "http://localhost:8989/v1/maxscale/modules/csmon/remove-node"
},
"meta": {
"message": "Node mcs3 removed from the cluster.",
"result": {
"node_id": "mcs3",
"timestamp": "2020-08-07 11:41:36.573425"
},
"success": true
}
}

53
6. Automatic Failover With MariaDB Monitor
https://mariadb.com/kb/en/mariadb-maxscale-25-automatic-failover-with-mariadb-monitor/
MariaDB Monitor는 MariaDB Master-slave 클러스터의 상태를 모니터링 할 수 있을 뿐만 아니라
failover 및 switchover를 수행 할 수도 있습니다. 또한 어떤 상황에서는 down 되었다가 나중에
Master에 rejoin 할 수 있습니다.
Failover (및 switchover 및 rejoin) 기능은 GTID 기반 replication만 지원되며 처음에는 단순한 토폴
로지, 즉 1 개의 Master와 여러 개의 slave에 대해서만 지원됩니다.
Failover, switchover 및 rejoin 기능은 MariaDB Monitor의 기본 기능이지만 automatic failover 나
automatic rejoin은 기본적으로 활성화되어 있지 않습니다.
다음 예제는 4개의 서버 (server1, server2, server3, server4)가 있다고 가정하여 작성 되었습니다.
이 중 server1은 초기 Master이고 다른 서버는 slave입니다. 또한 이러한 서버를 모니터링하는
TheMonitor라는 Monitor가 있습니다.
Somewhat simplified, the MaxScale configuration file would look like:
[server1]
type=server
address=192.168.121.51
port=3306
protocol=MariaDBBackend
[server2]
...
[server3]
...
[server4]
...
[TheMonitor]
type=monitor
module=mariadbmon
servers=server1,server2,server3,server4
...

54
1) Manual Failover
If everything is in order, the state of the cluster will look something like this:
$ maxctrl list servers
┌────┬────────┬───┬──────┬─────────┐
│ Server │ Address │ Port │ Connections│ State │
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Master, Running │
├────┼────────┼───┼──────┼─────────┤
│ server2│ 192.168.121.190│ 3306 │ 0 │ Slave, Running │
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
If the master now for any reason goes down, then the cluster state will look like this:
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Down │
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
Note that the status for server1 is Down.
Since failover is by default not enabled, the failover mechanism must be invoked manually:
$ maxctrl call command mariadbmon failover TheMonitor
OK
각각을 인수들에 대해서 개별적으로 살펴 보겠습니다. call command는 호출 될 모듈 명령임을 나
타내며, mariadbmon은 호출 할 명령이있는 모듈 (즉, MariaDB Monitor)을 나타내고, failover는 호
출하려는 명령이고 TheMonitor는 해당 명령에 대한 첫 번째이자 유일한 인수이며 구성 파일에
지정된 Monitor 이름입니다.
MariaDB Monitor는 이제 어떤 slave가 Master로 promote 될 가장 적합한 slave인지를 자율적으

55
로 추론하고, Master로 promote하고 그에 따라 다른 slave를 수정합니다.
If we now check the cluster state we will see that one of the remaining slaves has been made into
master.
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Down │
├────┼────────┼───┼──────┼─────────┤
│ server2│ 192.168.121.190│ 3306 │ 0 │ Master, Running │
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
If server1 now reappears, it will not be rejoined to the cluster, as shown by the following output:
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Running │
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
auto_rejoin = true가 Monitor 섹션에 지정 되었으면 server1에 다시 참여하려고 시도했을 것입니
다.
MaxScale 2.2.1에서는 rejoin을 수동으로 시작할 수 없지만 후속 버전에서는 해당 기능에 대한 명
령이 제공됩니다.

56
2) Automatic Failover
Automatic failover를 활성화하려면 구성 파일의 Monitor 섹션에 auto_failover = true를 추가하면됩
니다.
[TheMonitor]
type=monitor
module=mariadbmon
auto_failover=true
...
When everything is running fine, the cluster state looks like follows:
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
If server1 now goes down, failover will automatically be performed and an existing slave promoted
to new master.
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Down │
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
서버 상태를 지속적으로 모니터링하는 경우 잠시 동안 server1의 상태가 Down이고 server2의 상

57
태가 여전히 Slave, Running임을 알 수 있습니다.
3) Rejoin
Automatic rejoin을 활성화하려면 구성 파일의 모니터 섹션에 auto_rejoin = true를 추가하면됩니다.
[TheMonitor]
type=monitor
module=mariadbmon
auto_rejoin=true
...
Automatic rejoin이 활성화되면 MariaDB Monitor는 실패한 Master가 다시 나타나면 slave로 rejoin
을 시도합니다.
When everything is running fine, the cluster state looks like follows:
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
auto_failover = true가 구성 파일에 지정되었다고 가정하면 server1이 어떤 이유로 down되면
failover가 수행되고 다음과 같은 클러스터 상태가됩니다.
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Down │
├────┼────────┼───┼──────┼─────────┤

58
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
이제 server1이 다시 나타나면 MariaDB Monitor는 이를 감지하고 old Master를 slave로 다시 연결
하려고 시도합니다.
Rejoin 성공 여부는 old Master의 실제 상태에 따라 다릅니다. 예를 들어, old Master가 수정되고
변경 사항이 new Master에 복제되지 않은 경우 old Master가 다운되기 전에 automatic rejoin이
불가능합니다.
If rejoining can be performed, then the cluster state will end up looking like:
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
│ server1│ 192.168.121.51 │ 3306 │ 0 │ Slave, Running │
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘
4) Switchover
Switchover는 Master 역할을 다른 서버로 관리자가 이동하려는 경우를 위한 것입니다.
이전 예제가 끝날 때 클러스터 상태에서 계속해서 server1을 Master로 만들려면 다음 명령을 실
행 해야 합니다.
$ maxctrl call command mariadbmon switchover TheMonitor server1 server2
OK
각각을 인수들에 대해서 개별적으로 살펴 보겠습니다. call command는 호출 할 모듈 명령임을 나

59
타내고, mariadbmon은 호출 할 명령이 있는 모듈을 나타내고, switchover는 호출하려는 명령임을
나타냅니다. TheMonitor는 명령에 대한 첫 번째 인수, 구성 파일에 지정된 Monitor의 이름,
server1은 명령에 대한 두 번째 인수, Master로 만들려는 서버의 이름, server2는 명령, 현재
Master의 이름 입니다.
If the command executes successfully, we will end up with the following cluster state:
┌────┬────────┬───┬──────┬─────────┐
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
├────┼────────┼───┼──────┼─────────┤
└────┴────────┴───┴──────┴─────────┘

MariaDB MaxScale monitor 매뉴얼

More Related Content

What's hot (20)

Similar to MariaDB MaxScale monitor 매뉴얼 (20)

MariaDB MaxScale monitor 매뉴얼