MySQL - InnoDB Cluster(클러스터) - (7) - Auto increment - 버전 Upgrade 업그레이드

Last Updated on 11월 1, 2023 by Jade(정현호)

안녕하세요 

이번 포스팅에서는 MySQL InnoDB Cluster에서의 Auto increment 동작 방식과 InnoDB Cluster 버전 Upgrade 에 대한 내용을 알아보도록 하겠습니다.   

아래 포스팅에서 이어지는 MySQL InnoDB Cluster 연재 글입니다.

MySQL - InnoDB Cluster(클러스터) - (6) - 인스턴스 숨기기(접속 라우팅 비활성화) 및 라우터 다중화 - Multi MySQL Router

MySQL Innodb Cluster에서 특정 멤버 인스턴스에 접속이 불가하도록 접속 라우팅 비활성화(숨기기) 와 Tag 기능 그리고 MySQL Router 다중화 등에 대해서 다뤄보도록 하겠습니다.

InnoDB Cluster Auto-increment

InnoDB Cluster에서는 auto_increment_increment 과 auto_increment_offset(그룹 복제에서 지원 - 최대 크기 9) 파라미터를 이용하여 다중 프라이머리(Multi Primary) 클러스터에 대한 Auto increment 값의 충돌 가능성을 방지하도록 구성됩니다.

이러한 파라미터 구성과 사용은 다음과 같은 조건으로 요약할 수 있습니다.

• single-primary mode에서 실행 중인 경우
  • auto_increment_increment를 1로 설정하고, auto_increment_offset 을 2로 설정
• multi-primary mode에서 실행 중인 경우
  • 클러스터에 7개 이하의 인스턴스가 있는 경우 auto_increment_increment를 7로 설정하고 auto_increment_offset을 1 + server_id % 7로 설정
  • 다중 기본 클러스터에 8개 이상의 인스턴스가 있는 경우 auto_increment_increment를 인스턴스 수로 설정하고 auto_increment_offset을 1 + server_id % 인스턴스 수로 설정

Single Primary Mode

InnoDB Cluster 8.0 버전 기준 Single Primary(싱글 프라이머리) 모드에서는 auto_increment_increment 와 auto_increment_offset의 기본값이 다음과 같습니다.

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 1     |
| auto_increment_offset    | 2     |
+--------------------------+-------+

auto_increment_offset 값이 auto_increment_increment 값보다 크면 auto_increment_offset 값이 무시됩니다.

그래서 Single Primary 모드에서는 일반적인 MySQL 인스턴스와 동일하게 Auto increment 값이 1씩 증가합니다.

mysql> use test;

mysql> create table t1
(id bigint unsigned not null auto_increment primary key);

mysql> insert into t1(id) values(NULL),(NULL),(NULL),(NULL);

mysql> select * from t1;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
+----+

mysql> insert into t1(id) values(NULL),(NULL),(NULL),(NULL);

mysql> select * from t1;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  7 |
|  8 |
|  9 |
| 10 |
+----+

Single Primary 모드를 사용하는 경우 Auto increment는 기존과 동일하다고 보시면 됩니다.

Multi Primary Mode

InnoDB Cluster(Group Replication)에서의 Auto increment에 대한 사용에 차이점은 Multi Primary 모드에서 동작입니다.

관련된 파라미터는 auto_increment_increment 와 auto_increment_offset 입니다.

auto_increment_increment

auto_increment_increment는 auto increment 값 사이의 간격을 제어합니다.

auto_increment_increment 및 auto_increment_offset은 원형(소스에서 소스로) 복제와 함께 사용하기 위해 고안된 파라미터로, AUTO_INCREMENT 컬럼의 작동을 제어하는 데 사용할 수 있습니다.

여기에서 원형복제, circular replication 개념은 여러 서버간에 서로 복제를 함을 의미하며 쉽게 Multi Primary 모드 환경을 의미합니다. 기본값은 1 입니다.

auto_increment_increment 또는 auto_increment_offset 값은 정수만 가능하며 정수가 아닌 값으로 설정하려고 시도하면 오류가 발생하며 파라미터 값은 변경되지 않습니다.

그룹 복제(Group Replication)를 시작하면 auto_increment_increment 값은 group_replication_auto_increment_increment 값(기본값 7)으로 변경되고, auto_increment_offset 값이 서버 ID로 변경됩니다.

MySQL 8.0부터는 그룹 복제가 하나의 서버에서 쓰기가 동작하는 single-primary mode인 경우 파라미터는 자동으로 변경되지 않습니다. 즉 single-primary 모드에서 기본 설정은 1 입니다.

auto_increment_increment 및 auto_increment_offset은 다음과 같이 AUTO_INCREMENT 컬럼의 동작에 영향을 미칩니다.

InnoDB Cluster의 Single Primary가 아닌 일반 MySQL 인스턴스에서 먼저 auto_increment_increment와 auto_increment_offset 설정에 따른 동작 방식을 알아보겠습니다.

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 1     |
| auto_increment_offset    | 1     |
+--------------------------+-------+

위와 같이 현재 설정은 2개 파라미터 모두 1 입니다.

다음과 같이 테이블을 생성 후에 auto_increment_increment 파라미터만 10으로 변경 후 데이터를 입력해보겠습니다.

mysql> CREATE TABLE autoinc_1
(col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);


mysql> SET @@auto_increment_increment=10;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 10    |
| auto_increment_offset    | 1     |
+--------------------------+-------+
2 rows in set (0.01 sec)

mysql> INSERT INTO autoinc_1 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> SELECT col FROM autoinc_1;
+-----+
| col |
+-----+
|   1 |
|  11 |
|  21 |
|  31 |
+-----+
4 rows in set (0.00 sec)

처음 시작 값은 1이지만 값의 간격이 10씩 차이가 나는 것을 확인할 수 있습니다.

auto_increment_offset

auto_increment_offset 파라미터는 AUTO_INCREMENT 컬럼 값의 시작점을 결정합니다.

위와 같은 세션에서 테이블을 초기화 하고 이번에는 auto_increment_offset 파라미터 변경해보도록 하겠습니다.

mysql> truncate table autoinc_1;

mysql> SET @@auto_increment_offset=5;

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 10    |
| auto_increment_offset    | 5     |
+--------------------------+-------+

이전에 변경한 auto_increment_increment는 10으로, 여기에서 변경한 auto_increment_offset 파라미터는 5인 것을 확인할 수 있습니다. 

이제 다시 데이터를 입력해보겠습니다.

mysql> INSERT INTO t1 VALUES (NULL), (NULL), (NULL), (NULL);

mysql> select * from t1;
+----+
| id |
+----+
|  5 |
| 15 |
| 25 |
| 35 |
+----+

auto_increment_offset값에 따라서 시작 값이 5에서 시작하였고, 값의 간격은 auto_increment_increment 설정에 따른 10씩 증가하는 것을 확인할 수 있습니다.

2개 파라미터 설정에서 auto_increment_offset 값이 auto_increment_increment 값보다 크면 auto_increment_offset 값이 무시됩니다.

이제 Multi Primary Mode 에서 확인해보도록 하겠습니다.
       

ic-server1 에서 조회 및 데이터 입력

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 7     |
| auto_increment_offset    | 1     |
+--------------------------+-------+

mysql> create table t1
(id bigint unsigned not null auto_increment primary key
);

mysql> INSERT INTO t1 VALUES (NULL), (NULL), (NULL), (NULL);

mysql> select * from t1;
+----+
| id |
+----+
|  1 |
|  8 |
| 15 |
| 22 |
+----+

ic-server2 에서 조회 및 데이터 입력

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 7     |
| auto_increment_offset    | 2     |
+--------------------------+-------+

mysql> truncate table t1;

mysql> INSERT INTO t1 VALUES (NULL), (NULL), (NULL), (NULL);

mysql> select * from t1;
+----+
| id |
+----+
|  2 |
|  9 |
| 16 |
| 23 |
+----+

ic-server3 에서 조회 및 데이터 입력

mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 7     |
| auto_increment_offset    | 3     |
+--------------------------+-------+

mysql> truncate table t1;

mysql> INSERT INTO t1 VALUES (NULL), (NULL), (NULL), (NULL);

mysql> select * from t1;
+----+
| id |
+----+
|  3 |
| 10 |
| 17 |
| 24 |
+----+

Group Replication의 Multi Primary Mode 환경에서는 동시에 쓰기가 가능함에 따라서 위의 테스트 예제 내용과 같이 Auto Increment 값 중복에 대비를 위해 사전에 자동으로 파라미터 설정이 되며 다음과 같은 조건으로 설정됩니다.

• 클러스터에 7개 이하의 인스턴스가 있는 경우 auto_increment_increment를 7로 설정하고 auto_increment_offset을 1 + server_id % 7로 설정
• 다중 기본 클러스터에 8개 이상의 인스턴스가 있는 경우 auto_increment_increment를 인스턴스 수로 설정하고 auto_increment_offset을 1 + server_id % 인스턴스 수로 설정

그래서 Multi Primary Mode 에서는 특히 Auto Increment 속성으로 PK를 사용시에 값의 증가가 커지는 만큼 unsigned 설정이 필요한 부분입니다.

Upgrade InnoDB Cluster

이번에는 MySQL InnoDB Cluster 업그레이드에 대해서 확인해보겠습니다.

InnoDB 클러스터 업그레이드 프로세스의 대부분은 그룹 복제 업그레이드와 동일한 방식으로 인스턴스를 업그레이드하는 것으로 구성됩니다.

포스팅 글의 환경은 MySQL Server, Router, Shell 모두 8.0.23 버전으로 구성된 상태이며, 8.0.34 버전으로 업그레이드를 진행하도록 하겠습니다.

MySQL InnoDB 클러스터를 업그레이드하려면 다음 단계로 수행합니다.

1. Upgrade MySQL Router.
2. Upgrade MySQL Shell.
3. Upgrade MySQL Server.
4. Post Upgrade Status Check.

[참고] 설치된 바이너리의 버전을 확인 방법
mysqlrouter --version: Checks the version of MySQL Router installed.
mysqlsh --version: Checks the version of MySQL Shell installed.
mysqld --version: Checks the version of MySQL Server installed.

Upgrade MySQL Router

MySQL Router를 업그레이드하기 위해서는 다음과 같은 절차로 진행합니다.

1. 다운로드 및 압축 해제

• 다운로드 사이트 링크

• 8.0.34 버전 wget으로 직접 다운로드

wget https://dev.mysql.com/get/Downloads/MySQL-Router/mysql-router-8.0.34-linux-glibc2.12-x86_64.tar.xz

• 압축해제

tar xvf mysql-router-8.0.34-linux-glibc2.12-x86_64.tar.xz \
-C /usr/local

참고로 이전에 MySQL Router에 관한 글은 아래 포스팅을 참조하시면 됩니다.

MySQL - InnoDB Cluster(클러스터) - (3) - MySQL Router - MySQL 라우터 구성

안녕하세요 이번 포스팅에서는 이전 포스팅에서 이어서 MySQL InnoDB Cluster 구성에 대해서 기술되어 있으며, 그 중에서도 MySQL Router 에 대해서 설명되어 있습니다.

2. Stop MySQL Router

사용중인 Router를 중지합니다. 중지하게 되면 클라이언트의 트래픽이 MySQL Server로 전달되지 않습니다.

Router 업그레이드 과정 동안에 다른 Router로의 Failover나 서비스 점검 등, Router 업그레이드 작업 과정에서의 해당 Router로의 접속 불가에 대한 적절한 준비가 필요합니다.

• Router 중지(부트스트랩)

cd /usr/local/mysql-router/{부트스트랩 디렉토리}
./stop.sh

• Router 중지 확인

$ ps -ef | grep mysqlrouter

3. 디렉토리 변경 작업

포스팅 글에서는 /usr/local/mysql-router 디렉토리 경로를 사용함에 따라 디렉토리 변경 작업을 진행하도록 하겠습니다.

• 기존 디렉토리명 변경

$ cd /usr/local

$ mv mysql-router mysql-router.old

• 새로운 버전 디렉토리명 변경 및 소유권 변경

$ cd /usr/local

$ mv mysql-router-8.0.34-linux-glibc2.12-x86_64 mysql-router

$ chown -R mysql:mysql mysql-router

• 사용중인 부트스트랩 디렉토리를 새로운 버전으로 복사

$ cd /usr/local

$ cp -rp ./mysql-router.old/{부트스트랩} ./mysql-router/

4. Router 시작

다음과 같이 라우터를 시작합니다.

$ cd /usr/local/mysql-router/{부트스트랩}

$ ./start.sh

새로운 Router 구성시 경로를 변경하여 구성을 하고자 할 경우 스크립트의 수정도 있지만 수정 범위가 많고 에러 발생 소지도 있어서 다시 한번 부트스트랩 배포를 하는 방법으로 진행해도 됩니다.

아래 예시와 같이 --force 옵션을 통해서 기존에 등록된 라우터 정보를 삭제하지 않고 다시 부트스트랩 배포를 할 수 있습니다.

$ cd /usr/local/mysql-router/bin

$ ./mysqlrouter --bootstrap clusteradm@ic-server1:3306 \
--name ic-router1 --directory /usr/local/mysql-router/myrouter \
--account myrouter --user mysql --force

MySQL Router 업그레이드 수행후에 기동을 완료하였다면 다음과 같이 라우터 리스트를 확인해봅니다.

var cluster = dba.getCluster()
cluster.listRouters()
{
    "clusterName": "JadeCluster",
    "routers": {
        "router-srv-1::ic-router-s1-i1": {
            "hostname": "router-srv-1",
            "lastCheckIn": "2023-xx-xx xx:52:32",
            "roPort": "6447",
            "roXPort": "6449",
            "rwPort": "6446",
            "rwXPort": "6448",
            "version": "8.0.34" <!!---
        },
        "router-srv-2::ic-router-s2-i1": {
            "hostname": "router-srv-2",
            "lastCheckIn": "2023-xx-xx xx:52:23",
            "roPort": "6447",
            "roXPort": "64470",
            "rwPort": "6446",
            "rwXPort": "64460",
            "version": "8.0.23"
        }
    }
}

포스팅 글은 다중 라우터 환경으로 2개의 라우터중에서 업그레이드가 완료된 ic-router-s1-i1 라우터의 버전이 8.0.34 임을 확인할 수 있습니다.

Router 업그레이드 이후 mysql client로는 접속이 잘되지만 mysqlsh 로 접속시 아래와 같이 2000 에러가 발생하는 경우 mysql shell도 같이 업그레이드를 하면 됩니다.

MySQL Error 2000 (HY000): Unknown MySQL error

Upgrade MySQL Shell

MySQL Shell은 클라이언트 툴인만큼 설치 바이너리를 변경(교체)하는 형태로 진행합니다.

1. 다운로드 및 압축 해제

• 다운로드 사이트 링크

• wget으로 직접 다운로드

wget https://dev.mysql.com/get/Downloads/MySQL-Shell/mysql-shell-8.0.34-linux-glibc2.12-x86-64bit.tar.gz

• 압축해제

tar zxvf mysql-shell-8.0.34-linux-glibc2.12-x86-64bit.tar.gz \
-C /usr/local

2. 경로 변경 및 소유권 변경

• 경로 변경 작업 진행

## 소유권 변경
cd /usr/local/
chown -R mysql:mysql mysql-shell-8.0.34-linux-glibc2.12-x86-64bit


## 심볼릭 링크 변경
unlink mysql-shell
ln -s mysql-shell-8.0.34-linux-glibc2.12-x86-64bit mysql-shell

3. 버전확인

$ mysqlsh --version
mysqlsh   Ver 8.0.34 for Linux on x86_64 - for MySQL 8.0.34 (MySQL Community Server (GPL))

4. Upgrade the InnoDB Cluster Metadata

Primary 인스턴스(Writer)에 접속하여 아래와 같은 명령어를 수행하여 메타데이터에 대한 업그레이드를 진행합니다.

js> dba.upgradeMetadata()

기존에 사용한 MySQL Shell 버전에 따라서 클러스터가 이미 최신 버전을 사용하는 경우 메타데이터 업그레이드는 아무 작업도 수행하지 않을 수 있습니다.

Upgrade MySQL Server

MySQL Server의 업그레이드는 Primary instance를 업그레이드하기 전에 모든 secondary 인스턴스를 업그레이드합니다.

InnoDB Cluster 업그레이드에서 MySQL 서버 업그레이드는 선택 사항하며 MySQL Shell 및 MySQL Router를 업그레이드하는 것보다 더 큰 영향을 미칠 수 있습니다.

서버가 최신 버전이 아니더라도 가급적 MySQL Shell과 MySQL Router를 최신 버전으로 유지하는 것이 좋습니다. 이는 InnoDB Cluster 및 ReplicaSet의 경우에도 마찬가지입니다.

MySQL Server 업그레이드는 다음과 같은 순서로 진행됩니다.

1. 다운로드 및 압축 해제

• 다운로드 사이트 링크

• wget으로 직접 다운로드

wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.34-linux-glibc2.12-x86_64.tar.xz

• 압축해제

tar xvf mysql-8.0.34-linux-glibc2.12-x86_64.tar.xz \
-C /usr/local

2. MySQL 서버 중지

MySQL 서버 업그레이드는 Secondary 인스턴스부터 진행을 완료 후에 Primary 인스턴스를 진행합니다.

systemctl stop mysqld

중지하는 방법은 MySQL Server를 구성한 방법에 따라서 조금씩 다를 수 있습니다.

3. 디렉토리 변경 작업

• 경로 변경 및 소유권 변경

cd /usr/local/
unlink mysql

## 소유권 변경
chown -R mysql:mysql mysql-8.0.34-linux-glibc2.12-x86_64

## 심볼릭 링크 설정
ln -s mysql-8.0.34-linux-glibc2.12-x86_64 mysql

• 기존 디렉토리에서 파일 이전

cd /usr/local/이전 디렉토리
cp -rp log data tmp /usr/local/mysql/

해당 과정은 사용중인 MySQL의 data나 log 디렉토리의 위치에 따라서 생략 가능한 부분입니다.

4. MySQL 서버 시작 및 버전확인

• MySQL 시작

systemctl start mysqld

업그레이드하는 버전과 이전 버전에 따라서 removed 된 파라미터가 존재할 경우 MySQL 시작에 에러가 발생할 수 있습니다.

이는 업그레이드할 대상 버전에 따라 수정해야 할 부분이 다르기 때문에 시작의 에러가 발생시에 mysqld 로그 확인이 필요합니다.

정상적으로 업그레이드 및 기동이 완료되었다면 로그 상에서 다음과 같은 메세지를 확인할 수 있습니다.

[System] [MY-013381] [Server] Server upgrade from '80023' to '80034' started.
[System] [MY-013381] [Server] Server upgrade from '80023' to '80034' completed.

기동이 완료되었다면 MySQL 서버에 접속하여 버전을 확인합니다.

mysql> select @@version;
+-----------+
| @@version |
+-----------+
| 8.0.34    |
+-----------+

3개 인스턴스 중에서 Secondary 인스턴스 1개만 진행을 완료된 상태입니다. 클러스터 status를 확인하면 다음과 같은 정보가확인됩니다다.

var cluster = dba.getCluster()
cluster.status()
{
    "clusterName": "JadeCluster",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "ic-server3:3306",
        "ssl": "REQUIRED",
        "status": "OK",
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
        "topology": {
            "ic-server1:3306": {
                "address": "ic-server1:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE",
                "version": "8.0.34" <!!----
            },
            "ic-server2:3306": {
                "address": "ic-server2:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE",
                "version": "8.0.23"
            },
            "ic-server3:3306": {
                "address": "ic-server3:3306",
                "memberRole": "PRIMARY",
                "mode": "R/W",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE",
                "version": "8.0.23"
            }
        },
        "topologyMode": "Single-Primary"
    },
    "groupInformationSourceMember": "ic-server3:3306"
}

ic-server1 인스턴스는 Secondary 인스턴스로 방금 업그레이드를 완료한 인스턴스입니다. 버전이 다른 인스턴스와 달리 8.0.34로 변경된 것을 확인할 수 있습니다.

동일한 방법으로 나머지 Secondary 인스턴스 업그레이드를 진행합니다.

모든 Secondary 인스턴스 업그레이드가 완료되었다면, 마지막으로 Primary 인스턴스를 진행합니다.

Post Upgrade Status Check

MySQL Router, MySQL Shell 및 MySQL Servers를 업그레이드한 후에는 다음과 같이 클러스터를 확인을 합니다.

var cluster = dba.getCluster()
cluster. Status()

클러스터 상태를 확인하여 반환되는 에러 및 statusText 를 해결해야 합니다.

포스팅 환경에서는 다음과 같이 Group communication protocol 버전 업그레이드를 해야 한다고 메세지가 확인되고 있습니다.

var cluster = dba.getCluster()
cluster.status()
{
    "clusterName": "JadeCluster",
    "defaultReplicaSet": {
        "clusterErrors": [
            "Group communication protocol in use is version 8.0.16 but it is possible to upgrade to 8.0.27. 
             Single Consensus Leader can only be enabled after upgrade. 
             Use Cluster.rescan({upgradeCommProtocol:true}) to upgrade."
        ],
        "name": "default",
        "primary": "ic-server1:3306",
<... 중략 ...>

기존에 사용하였던 버전에 따라서 해당 메세지는 확인되지 않을 수 있습니다.

이와 같이 Group communication protocol 버전 업그레이드 필요 메세지에 대해서는 rescan을 진행하면 됩니다.

다만 rescan을 진행하는 과정에서 다음과 같이 재시작 필요 메세지를 확인할 수 있습니다.

var cluster = dba.getCluster()
cluster.rescan({upgradeCommProtocol:true})

NOTE: The Cluster is not configured to use 'group_replication_view_change_uuid', 
which is required for InnoDB ClusterSet. 
Configuring it requires a full Cluster reboot.
Would you like 'group_replication_view_change_uuid' to be configured automatically? [Y/n]:

여기에서 y 를 누르면 다음과 같은 메세지가 표시되면서 진행됩니다.

NOTE: The Cluster's group_replication_view_change_uuid is not set.
Generating and setting a value for group_replication_view_change_uuid...

NOTE: The Cluster must be completely taken OFFLINE and restarted 
(dba.rebootClusterFromCompleteOutage()) for the settings to be effective

Updating group_replication_view_change_uuid in the Cluster's metadata...
NOTE: Upgrading Group Replication communication protocol to version 8.0.27

실제로 자동으로 재시작은 되지 않으나 재시작하기 전에는 rescan을 하면 계속 Note의 동일한 내용이 출력 되어서 재시작이 필요 합니다.

클러스터 재시작은 MySQL Shell 버전에 따라서 약간 다르게 수행되게 됩니다.

MySQL Shell 8.0.27/28의 경우

Primary 인스턴스에서 rescan()을 수행하여 group_replication_view_change_uuid 설정합니다.

\js
c=dba.getCluster()
c.rescan()

모든 Secondary 인스턴스에서 MySQL Shell 로 접속하여 다음과 같은 명령어를 통해서 group replication을 잠시 중지합니다.

\sql
stop group_replication;

Primary 인스턴스를 다시 시작하고 클러스터를 재부팅합니다.

\sql
RESTART;
\js
c=dba.rebootClusterFromCompleteOutage()
c.status()

다운타임은 RESTART명령어 수행에 따른 인스턴스 재시작 및 dba.rebootClusterFromCompleteOutage() 명령어 완료 시간까지입니다.

MySQL Shell 8.0.29+의 경우

Primary 인스턴스에서만 다음과 같은 명령어를 수행합니다.

\js
c=dba.getCluster()
c.rescan()
c.fenceAllTraffic()
c= dba.rebootClusterFromCompleteOutage()

c.status()
c.rescan()

다운타임은 fenceAllTraffic()으로 시작하여 rebootClusterFromCompleteOutage()가 완료된 시점까지입니다.

클러스터 재시작이 완료되면 rescan 시 이전의 warning의 note 메세지 없이 다음과 같은 정보가 출력됨을 확인할 수 있습니다.

js> c.rescan()

Rescanning the cluster...

Result of the rescanning operation for the 'JadeCluster' cluster:
{
    "name": "JadeCluster",
    "newTopologyMode": null,
    "newlyDiscoveredInstances": [],
    "unavailableInstances": [],
    "updatedInstances": []
}

Group communication protocol 버전 정보는 다음과 같이 확인할 수 있습니다.

mysql> SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.27                                         |
+------------------------------------------------+

이번 글은 InnoDB Cluster 환경에서의 Auto Increment 동작에 대한 내용과 클러스터 구성 버전의 업그레이드에 대해서 확인해보았습니다. 여기에서 글을 마무리하도록 하겠습니다.


• 이어지는 글: MySQL 8.2.0 Innovation Release 에서 Read/Write Splitting 라는 아주 좋은 기능이 추가되었습니다.

MySQL - InnoDB Cluster(클러스터) - (8) - Transparent Read/Write Splitting - Innovation Release

포스팅은 MySQL Router 8.2.0 Innovation 버전에서 추가된 Read/Write Splitting 기능에 대해서 다루고 있습니다.

Reference

Reference URL
• mysql.com/mysql-innodb-cluster-auto-increment
• mysql.com/auto_increment_offset
• mysql.com/auto_increment_increment
• mysql.com/group_replication_auto_increment_increment
• mysql.com/mysql-innodb-cluster-upgrade-rolling
• mysql.com/group-replication-communication-protocol


연관된 다른 글

MySQL - InnoDB Cluster(클러스터) - (1) - 아키텍처 - 그룹 복제(Group Replication)

안녕하세요 이번 포스팅에서는 InnoDB Cluster(클러스터) 에 대해서 InnoDB 의 아키텍처 및 구성 및 설정에 관해서 확인 해보도록 하겠습니다.

MySQL MHA(Master High Availability) 1 - MHA 기능 설명 및 아키텍처 설명

MySQL HA솔루션인 MHA에 관한 내용으로 MHA 기능 설명 및 아키텍처에 대한 설명을 합니다.

MySQL GTID 를 사용한 Replication(복제) 설정

GTID 는 Global Transaction IDentifier 약자로 MySQL 데이터베이스에서 커밋되는 각 트랜잭션과 함께 생성되고 트랜잭션에 연결되는 고유한 식별자입니다.

MySQL Replication(복제) 구성 및 설정 - Async - Semi Async

리플리케이션(Replication)은 DB의 내용을 복제함을 의미하며 복제 대상인 Master가 1개 또는 다수에 대해서 Slave(Standby)가 복제를 하여 사용하는 것을 의미합니다.

Jade(정현호)

Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중

Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io

hoing.io