본문 바로가기
프로그래밍/MySQL

[Ubuntu] MariaDB + Galera 완벽 설치

낭만온달 2019. 12. 28. 16:07

1. 개요

  Unbunto 환경에서 최신 버전의 마리아DB(MariaDB)를 설치하고 고가용성(HA)를 달성하기 위한 DB서버 이중화 방법중의 하나인 Galera를 설치하여 실사용이 가능한 상태까지 만들어 본다.

 

2. 목차

    1. 개요

    2. 목차

    3. Ubuntu 서버 만들기(클라우드)

    4. MariaDB 최신버전 설치하기

    5. Galera에 대한 이해

    6. Galera 설정

    7. 운영 테스트

    8. Maxscale 설치

 

3. Ubunto서버 만들기

  테스트를 위한 서버가 구비되어 있지 않아도 쉽게 클라우드 서비스를 이용해 테스트 서버를 구축 할 수 있다.

  테스트하기 적당한 클라우드 서비스 임대로 Vultr.com(vultr.com) 서비스를 추천하며, 사용한 만큼만 사용료를 지불하고, 필요하지 않은 경우 바로 서비스를 종료시킬 수 있기 때문에 많은 사용자를 가지고 있지만 모든 서버가 해외 IDC를 이용하고 있다는 단점으로, 속도에 민감하지 않은 서비스라면 가성비 차원에서 가상서버 임대를 고민해 볼 수 있다.

또한 가상서버의 생성 및 관리가 비교적 직관적으로 되어 있어서 편리 하다.

vultr 서비스에 이메일 주소로 가입이 가능하고, 신용카드로 일정 금액을 적립하고 사용한 만큼 월별 청구되어 소진 되는 형태로 운영된다. 사용하지 않은 남은 금액에 대한 환불 요구시 친절하게도 즉시 환불 받았던 좋은 기억이 있다.

아무래도 해외 사이트 신용카드 결제가 우려되긴 하는데 결제시만 신용카드 앱에서 해외결제를 활성화 시키고 결제 완료 후 해외결제를 비활성 시키는 방법으로 카드가 도용되는 우려를 줄이고 있다.

3.1 vultr 가상서버 구축하기(Ubuntu)

가상서버 추가 요청
서비스 유형(클라우드)를 선택하고, 서버의 위치(일본-도쿄, 다른지역도 가능하나 아시아에서는 일본이 상대적으로 빠름)
테스트 목적이므로 Server Type을 Ubuntu 16.04 x64를 선택하고, 유지비용이 적게 드는 5$ / 월 서버 선택

 

  서버 생성을 위하여 "Deploy Now"를 클릭하여 서버를 생성한다.

생성된 서버 인스턴스 목록

 

3.2 vultr 가상서버 Ubuntu(Linux base) 관리

  Ubuntu 서버를 관리하기 위해서는 Telnet을 지원하는 터미널을 이용하면 되는데 수많은 터미널 관리 프로그램이 있어 어렵지 않게 구할 수 있다. 비교적 쉽게 접근할 수 있는 SSH를 지원하는 터미널 클라이언트 프로그램으로 "Bitvise SSH Client"를 이용해 본다.

 Bitvise SSH Client의 장점은 로그인시 파일전송도구창과, Console이 함께 떠서 로컬 PC와 Ubuntu서버간의 파일 전송/수신을 쉽게 할 수 있는 장점이 있다.

다운로드 : https://www.bitvise.com/ssh-client-download

터미널 프로필 관리자 및 파일/송수신 윈도우와 터미널 창을 이용해 쉽게 서버를 관리

 

3.3 vultr 가상서버 Ubuntu(Linux base) 로그인 및 비밀번호 변경

Vultr에 Ubuntu 서버를 생성하고 해당 노드를 클릭 하면 해당 서버의 초기 설정 정보가 나오는데 반드시 root계정으로 초기 부여된 비번으로 로그인 하여 비번을 변경하여 사용하여야 한다.

새로 생성된 서버 노드의 기본 정보 확인(초기 비밀번호 확인)

//비번 변경

$root@UbuntoNode1:~# passwd
New password:

 

 

 

4. MariaDB 최신버전 설치하기

  Ubuntu를 설치하면 Ubuntu 배포 시점의 MariaDB의 버전이 배포패키지 레파지터리에 등록되어 있으며 다음 명령으로 MariaDB를 설치 하면 되는데, 현재 MariaDB와 버전 차이가 상당히 날 수 있으니 반드시 다음 과정을 거쳐서 패키지 레파지토리에 MariaDB의 최신 버전으로 업데이트 시켜 주어야 한다.

MariaDB 공식 홈페이지로 이동 : https://downloads.mariadb.org/mariadb/repositories/#mirror=tuna

 

MariaDB - Setting up MariaDB Repositories - MariaDB

To generate the entries select an item from each of the boxes below. Once an item is selected in each box, your customized repository configuration will appear below. 1. Choose a Distro SLES openSUSE Arch Linux Mageia Fedora CentOS RedHat Mint Ubuntu Debia

downloads.mariadb.org

이 페이지에서 순차적으로 MariaDB의 배포OS(Ubuntu), 버전(16.04 LTS "xenial"),  MariaDB버전(10.4 [Stable])을 선택하면 다음과 같이 Ubuntu 배포 패키지 레파지토리를 업데이트 할 수 있는 스크립트가 나온다.

  배포 레파지토리 업데이트를 위해 다음을 실행한다.

4.1 Ubuntu MariaDB 배포 패키지 최신 버전으로 업데이트 하기

sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
sudo add-apt-repository 'deb [arch=amd64,arm64,i386,ppc64el] http://mirrors.tuna.tsinghua.edu.cn/mariadb/repo/10.4/ubuntu xenial main'

 

4.2 MariaDB 설치 

sudo apt update
sudo apt install mariadb-server

 

4.3 MariaDB 관리자 비밀번호 변경

~# sudo mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] Y
New password:
Re-enter new password:
Sorry, you can't use an empty password here.

New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

 

 

5. Galera에 대한 이해

5.1 고가용성(HA)

   서비스의 안정성 및 영속성을 보장하기 위하여 고가용성(HA)를 확보하는 것이 최근 트렌드로 자리잡고 있는데 서버에 대한 이중화 방식으로 대체로 Active-StandBy 방식과 Active-Active 방식을 사용한다. 

Active-StandBy 방식 - 

  일상적인 서비스 시점에서는 Active Node를 사용자에게 노출하여 주로 사용하게 되고 Active노드에서 발생되는 모든 트랜잭션은 StandBy 노드로 복제(Replication)되는 것을 보장하고, Active노드가 서비스 불능 상태에 빠졌을 경우 자동 또는 수동으로 Fail Over를 진행하여 서비스를 정상화 시키고, 손상된 Active노드를 복구하여 항상 Active-StandBy 상태를 유지시켜 HA를 달성하는 방법으로 Fail Over시 약간의 서비스 지연이 발생해도 큰 문제가 되지 않는 서비스의 경우 구성이 단순하여 많이 사용됨.

 

Active-Active방식 - 

  금융권 처럼 서비스 중지가 발생하면 안되는 Mission-Critical한 시스템에 주로 사용되며 2개 이상의 서비스 노드가 실시간으로 동작하여 어떤 노드로 서비스를 받더라도 동일한 서비스를 받을 수 있으며 특정 노드가 Fail 상태에 빠져도 서비스는 중지되지 않는 서비스로 두 서버간에는 복제가 아닌 실시간 동기화 방식에 의해 데이터의 무결성을 확보 한다.

 

5.2 MariaDB의 Galera의 특징(장점)

  • 각 서버는 마스터(Master) / 슬레이브(Slave)로 명명되지 않고 서비스 노드로 명칭 된다.
  • Active-Active구성으로 모든 노드에서 Read/Write가 가능하여 읽기/변경이 가능하다.
  • 노드 장애시에도 데이터 유실 없는 서비스 가능(고가용성)
  • 노드간 트랜잭션 지원
  • 클러스터내 노드 자동 컨트롤(노드 장애시 자동으로 해당 노드 제거, 추가)

 

5.2 Galera의 동작 방식

  • Galera는 복제(Replication)을 wsrep API로 노드간 통신 수행 하며 MariaDB는 향상된 wsrep API를 지원함
  • MySQL-wsrep는 MySQL의 InnoDB 스토리지 엔진 내부에서 Write Set(기록집합 : 트랜잭션을 기록하는 모든 논리적 데이터 집합)을 추출하고 적용
  • 노드간 Write Set을 전송 및 통신을 위해서 별도의 어플리케이션 플러그인을 사용,
  • Replication 엔진은 wsrep에 정의된 Call/Callback 함수에 따라 동작

동작순서

1) Node1에서 변경(write/update) 커밋 동작

2) Cluster내 다른 Node2로 이벤트 전송

3) 이벤트를 받은 Node2가 유효성 체크 후 데이터 변경

4) Node1은 Node2의 처리 결과를 받아 물리적인 데이터 변경(커밋)

   

6. Galera 설정

 

6.1 Galera 설정 목표(Active-Active 상태의 MariaDB 이중화 서버 확보)

 

6.2 Galera 설정

6.2.1 사용되는 PORT

  • 3306 : mysql/mariaDB Client Connection을 위한 포트
  • 4567 : UDP와 TCP 둘 다 사용하는 Galera Cluster복제 트래픽, 다중 복제를 위한 포트
  • 4568 : Incremental State Transfer(변경된 상태 전송)를 위한 포트
  • 4444 : State Snapshort Transfer(전체 상태 전송)를 위한 포트

6.2.2 복제를 위해 사용되는 Application(지정 가능)

  • rsync : 기본 파일 동기화 프로토콜로 Donor의 blocking시간이 길어 병목이 발생할 수도 있다.
  • mysqldump : 느림
  • xtrabackup : 속도가 빠르지는 않지만 Doner의 blocking시간을 줄여줌

   * 테스트로 사용하는 것은 rsync를 사용할 것이며, 설치되어 있지 않다면 다음 명령으로 설치

//rsync 설치
$ sudo apt-get install rsync

//rsync 환경파일 수정
$ sudo nano /etc/default/rsync
~
RSYNC_ENABLE=false 라인을 찾고 아래와 같이 수정
RSYNC_ENABLE=true
~
//rsync 서비스 재시작
$ sudo /etc/init.d/rsync restart

# Rsync 기본 문법 및 옵션
rsync options source destination

-a : archive 모드로 타임스탬프, 심볼릭링크, 퍼미션, 그룹, 소유자, 장치 등의 파일 보존
-v : 상세 정보 출력
-r : 하위 디렉토리까지 복사
-z : 데이터를 압축해서 전송. 단 destination에서는 압축이 해제되어 들어감.

일반적으로 아래와 같이 많이 사용
$ rsync avz  소스디렉토리경로 목적지디렉토리경로




# 한 서버에서 디렉토리간 동기화 하기
만약 서버내 AAA라는 디렉토리의 files를 BBB라는 디렉토리에도 동일하게 만들어 주고 싶다면 아래와 같은 명령어를 사용.

$ rsync -avz  /AAA/files  /BBB



# 한 서버에서 다른 서버의 디렉토리 동기화 하기
1) ssh 또는 rsh를 사용하는 방법(데이터 전송시 암호화 적용)
$ rsync  -avz   root@호스트네임:/AAA/fies   /BBB
또는
$ rsync -avz    호스트아이피:/AAA/files    /BBB

2) rsync 데몬을 사용하는 방법(데이터 전송시 암호화 없음. inetd 서비스가 실행상태여야함)
$ rsync -avz   호스트아이피::/AAA/files    /BBB

만약 rsync를 사용해서 /AAA/files의 어떤 파일을 삭제했을 때 destination 디렉토리에서도 지워지길 원하는 경우 아래와 같은 명령어 사용.
$ rsync -av --delete  /AAA/files  /BBB


서버간 동기화를 해야 하는 경우 아래의 사항 참고

[Source 서버용]
1. rsync 설치
2. rsync 설정(/etc/default/rsync)
3. rsync.conf 생성 및 아래 구문 복사 후 붙여넣기
   $ sudo nano /etc/rsyncd.conf
  
log file = /var/log/rsync.log            # 로그 파일 경로
[source]                                         # 부르고 싶은 명칭
path = /var/www/omeka1/files       # 소스 디렉토리 설정
uid = root                                       # rsync 사용 가능한 사용자
gid = root                                       # rsync 사용 가능한 그룹
use chroot = yes                            # chroot 사용여부
host allow = x.x.x.x                        # 해당 호스트 아이피만 접근 가능
max connection = 100                   # 최대 연결 개수
timeout 300                                    # 타임아웃 시간 설정


[Destination 서버용]
1. rsync 설치
2. rsync 설정(/etc/default/rsync)
3. rsync 명령어 실행
    문법은 rsync -avz 소스서버아이피 또는 도메인주소::부르고싶은명칭  목적지경로
    아래와 같이 작성하고 엔터.
    
     $ rsync  -avz   소스서버아이피::source    /var/www/omeka2



# Crontab을 활용한 주기적이고 자동적인 파일 동기화
크론탭을 열고 아래의 명령어 예시와 같이 원하는 시점으로 작성
분/시/일/월/요일 순으로 작성
$ crontab -e

[명령어 입력 예시]
15 2 30 7 *   rsync -avz  /AAA/files  /BBB      # 7월 30일 2시 15분에  rsync 실행

15 2 * * 1     rsync -avz  /AAA/files  /BBB      #  매주 첫날 2시 15분에 rsync 실행

0 1 *  * *       rsync -avz  /AAA/files  /BBB      # 매일 1시 정각에 rsync 실행

0-59/1 * * * *   rsync  -avz   소스서버아이피::source    /var/www/omeka2   # 1분마다 rsync 실행

 

6.2.3 MariaDB 사용자 설정 권한 편집

* 구성할 3대중 1대를 Ubunto/MariaDB, Galera 설정을 완벽히 구성한 후 스냅샷 이미지를 이용해 나머지 2대를 구성하고 Galera 설정값만 변경해 주면 쉽게 구성 가능하다.

* 계정과 권한은 노드 3개가 모두 동일해야 하는 것은 당연

GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY 'rootpw123' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO cluster_user@'%' IDENTIFIED BY 'userpw123' WITH GRANT OPTION;

 

6.2.4 Node1 (Doner Node) 설정

MariaDB 10.4 이후 버전에는 /etc/mysql/my.cnf에 MariaDB(mySQL) 관련 모든 설정 정보가 들어 있다. 물론 [Galera] 섹션에서 Galera 설정을 변경해 줄 수 있다.

* Galera설정과 관련된 블로그를 보면 Node1/Node2/Node3에 한 번에 모든 노드 정보를 설정하도록 설명된 부분이 있는데 이렇게 하면 최초 Doner Node 실행시 오류가 발생 됨을 확인 하였다.

* Node1, Node2, Node3를 순차적으로  다음과 같이 설정한다.

 

[galera]
# Mandatory settings
# wsrep API를 활성화 시킨다
wsrep_on=ON
# wsrep API라이브러리 경로를 지정
wsrep_provider=/usr/lib/libgalera_smm.so
# 클러스터에 참여하는 모든 모드의 IP목록, 최초 설정시는 비어두고 진행하고, 모두 참여시키고 난 후에 이 
# 서버를 포함한 모든 참여 노드의 IP목록을 기재해 주도록 한다.
wsrep_cluster_address=gcomm://
binlog_format=row
# 스토리지 엔진 지정
default_storage_engine=InnoDB
# 자동증가형 Locking 모드
innodb_autoinc_lock_mode=2
#
# Allow server to accept connections on all interfaces.
# 이것을 해 주어야 외부에서 접근이 가능하다.
bind-address=0.0.0.0
#
# Optional setting
#wsrep_slave_threads=1
#innodb_flush_log_at_trx_commit=0

#추가 
wsrep_provider_options="gcache.size=512M"
# 설정하는 클러스터 명, 모든 노드의 클러스터명은 동일해야 한다.
wsrep_cluster_name=test_cluster
# 현재 설정하는 노드 이름
wsrep_node_name=server1
# 동기화 방식
wsrep_sst_method=rsync

6.2.5 Node1 (Doner Node) 최초 실행

Maria DB를 중지 시키고 다음과 같이 Doner노드로 클러스터링 모드로 재시작 시킨다.

sudo service mariadb stop

# --wsrep_cluster_new는 최초 1회실행시만 지정한다.
sudo service mariadb start --wsrep_cluster_new

 

6.2.6 Node2 (Joiner Node) 설정

Doner Node(Node1)의 설정 정보와 동일하지만 다음 부분만 수정한다.

wsrep_cluster_address="gcomm://192.168.0.1,192.168.0.2"
wsrep_node_name=server2
wsrep_sst_receive_address="192.160.0.1:4569"

 

6.2.7 Node3 (Joiner Node) 설정

Doner Node(Node1)의 설정 정보와 동일하지만 다음 부분만 수정한다.

wsrep_cluster_address="gcomm://192.168.0.1,192.168.0.2,192.168.0.3"
wsrep_node_name=server3
wsrep_sst_receive_address="192.160.0.2:4569"

 

6.2.8 Node2, Node3 (Joiner Node) MariaDB 재시작

sudo service mysql stop
sudo service mysql start //옵션필요없음

 

6.2.7 모든 노드(Doner/Joiner)의 my.cnf 파일에서 다음 부분을 재수정

wsrep_cluster_address="gcomm://192.168.0.1,192.168.0.2,192.168.0.3"

 

6.2.8  설정 정상 여부 확인

Doner Node인 Server1에서 다음과 같은 SQL 쿼리문을 날려 본다.

SHOW STATUS LIKE 'wsrep%';

다음과 같은 결과가 나오면 성공

Variable_name	            Value
wsrep_cluster_conf_id	    3
wsrep_cluster_size	        3
wsrep_cluster_state_uuid	00be20a6-28be-11e7-9400-678af9ffc349
wsrep_cluster_status	    Primary
wsrep_connected	            ON

 

6.2.9  오류가 발생 하는 경우 / 조치

# 오류
Apr 24 16:12:40 ubuntu1 mysqld[8844]: 2017-04-24 16:12:40 140660766763264 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave th
Apr 24 16:12:40 ubuntu1 mysqld[8844]: 2017-04-24 16:12:40 140660766763264 [ERROR] WSREP: wsrep::connect(gcomm://) failed: 7
Apr 24 16:12:40 ubuntu1 mysqld[8844]: 2017-04-24 16:12:40 140660766763264 [ERROR] Aborting

# 조치
sudo rm -rf galera.cache grastate.dat wsrep_sst_binlog.tar 




# 오류
Apr 24 16:40:15 ubuntu1 mysqld[10977]: 2017-04-24 16:40:15 139623460747520 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection ti
Apr 24 16:40:15 ubuntu1 mysqld[10977]:          at gcomm/src/pc.cpp:connect():158
Apr 24 16:40:15 ubuntu1 mysqld[10977]: 2017-04-24 16:40:15 139623460747520 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():208: Failed to open backend connection: -110 (Connection 
Apr 24 16:40:15 ubuntu1 mysqld[10977]: 2017-04-24 16:40:15 139623460747520 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1380: Failed to open channel 'test_cluster' at 'gcomm://192.168.0.4
Apr 24 16:40:15 ubuntu1 mysqld[10977]: 2017-04-24 16:40:15 139623460747520 [ERROR] WSREP: gcs connect failed: Connection timed out
Apr 24 16:40:15 ubuntu1 mysqld[10977]: 2017-04-24 16:40:15 139623460747520 [ERROR] WSREP: wsrep::connect(gcomm://192.168.0.40,192.168.0.41,192.168.0.42) failed: 7
Apr 24 16:40:15 ubuntu1 mysqld[10977]: 2017-04-24 16:40:15 139623460747520 [ERROR] Aborting

# 조치
sudo galera_new_cluster

 

7. 운영 테스트

Doner Node(Server1)에서 다음 쿼리 수행

CREATE TABLE TEST1
(
    ID int primary key,
    Description VARCHAR(100)
);

INSERT INTO TEST1 VALUES (1, 'TEST1');
INSERT INTO TEST1 VALUES (2, 'TEST2');

Joiner Node(Server2)에서 다음 쿼리 수행

INSERT INTO TEST1 VALUES (3, 'TEST3');
INSERT INTO TEST1 VALUES (4, 'TEST4');

Joiner Node(Server3)에서 다음 쿼리 수행

INSERT INTO TEST1 VALUES (5, 'TEST5');
INSERT INTO TEST1 VALUES (6, 'TEST6');

 

모든 노드에서 다음 쿼리 실행후 결과가 동일한지 확인

SELECT * FROM TEST1

result

ID    Description
1     TEST1
2     TEST2
3     TEST3
4     TEST4
5     TEST5
6     TEST6

 

 

8. Maxscale 설치

  위 과정을 거쳐 Galera를 모두 설정하고 나면 대부분 아무 문제 없이 Active-Active 상태의 고가용성을 유지한 MariaDB 운영 시스템을 확보하게 될 것이다. 그러나 중요한 문제는 아니지만 테이블내 자동 증가형 필드의 자동증가 값이 단일 시스템과 다르게 동작할 수 있다. 

예를 들어 자동증가형 필드가 있는 테이블에 하나의 ROW를 삽입 할 때마다 auto_increment 값이 +1 씩 증가하는 것이 아니라 건너 띄어 증가되는 모습을 볼 수 있는데 이런 현상을 방지하기 위하여 Maxscale 모듈을 추가 설치해 주도록 한다.

INCID     Description
1         AUTOINC TEST 1
3         AUTOINC TEST 2
8         AUTOINC TEST 3
13        AUTOINC TEST 3
18        AUTOINC TEST 5

 

  Maxscale 설치

sudo dpkg -i maxscale-2.0.5-1.ubuntu.xenial.x86_64.deb

  Maxscale 계정 및 권한 추가(각 노드별)

GRANT ALL PRIVILEGES ON *.* TO maxscale@'%' IDENTIFIED BY '1234' WITH GRANT OPTION;

  Maxscale 환경설정 파일 수정

[maxscale]
#threads=1
threads=4

# Server definitions
#
# Set the address of the server to the network
# address of a MySQL server.
#

[server1]
type=server
address=192.168.0.40
port=3306
protocol=MySQLBackend

[server2]
type=server
address=192.168.0.41
port=3306
protocol=MySQLBackend

[server3]
type=server
address=192.168.0.42
port=3306
protocol=MySQLBackend

# Monitor for the servers
#
# This will keep MaxScale aware of the state of the servers.

# MySQL Monitor documentation:
# https://github.com/mariadb-corporation/MaxScale/blob/master/Documentation/Monitors/MySQL-Monitor.md

#[MySQL Monitor]
#type=monitor
#module=mysqlmon
#servers=server1
#user=myuser
#passwd=mypwd
#monitor_interval=10000

[Splitter Service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=maxscale
passwd=1234


[Galera Monitor]
type=monitor
module=galeramon
servers=server1,server2,server3
#use_priority=true
user=maxscale
passwd=1234


# Service definitions
#
# Service Definition for a read-only service and
# a read/write splitting service.
#

[Splitter Listener]
type=listener
service=Splitter Service
protocol=MySQLClient
port=4040
socket=/tmp/ClusterMaster

[MaxAdmin Listener]
type=listener
service=MaxAdmin Service
protocol=maxscaled
socket=default


[CLI]
type=service
router=cli

[CLI Listener]
type=listener
service=CLI
protocol=maxscaled
address=localhost
port=6603

 

Maxscale 서비스 재실행

service maxscale start
저작자표시 비영리 동일조건

'프로그래밍 > MySQL' 카테고리의 다른 글

Ubuntu - MariaDB설치  (1) 2019.12.26
레드마인 업그레이드시 DB한글 깨짐 현상 해결  (2) 2013.03.29

'프로그래밍/MySQL' Related Articles

티스토리툴바