Data Science Lab

[MCU] ESP32 WIFI 사용시 아날로그 GPIO 오류

SungWookKang — Thu, 6 Mar 2025 23:19:53 +0900

[MCU] ESP32 WIFI 사용시 아날로그 GPIO 오류

Board : ESP32-WROOM-DevKit

ESP 32 보드에서 TDS 센서를 사용하여 전기 전도도 값을 측정을 해야하는 작업이 있었다. 이때 샘플 코드로 작동하면 정상으로 작동하는데, WiFi를 활성화하면 정상적으로 센서의 값을 읽어오지 못하는 문제가 발생하였다. (정확히는 4095로 값이 고정되어 출력)

l 테스트 TDS 샘플 코드 : https://randomnerdtutorials.com/esp32-tds-water-quality-sensor/

해당 현상과 관련하여 검색해 보니, 일부 ESP32에서 WiFi를 활성화할 경우 일부 아날로그 GPIO핀이 정상적으로 동작하지 않는다고 한다. 이 문제를 해결하기 위해서는 동작가능한 다른 아날로그 GPIO 핀을 찾아서 사용하면 된다. 아래는 WiFi 활성화시 사용할 수 있는 핀번호이다. MCU 모델마다 다를 수 있으므로 참고 정도로만 생각하자.

l 사용 불가 Pin : 00, 02, 04, 12, 13, 14, 15, 25, 26

l 사용 가능 Pin : 32, 33, 34, 35, 36, 39

문제 원인을 알았을 때에는 해결방법이 매우 간단하였지만, 처음에는 소스코드의 오류인지, 센서 기계 자체의 오류인지, 아니면 출력하는 데에서 표시 오류인지 등 증상에 대한 원인을 파악하지 못해서 한참 동안 헤맸었다. (중국산 센서들의 불량이 많았던 터라.) 아두이노를 사용하여 제품을 구성할 경우, 소프트웨어 오류인지, 하드웨어 오류인지부터 확인이 필요하다.

[참고자료]

l ESP32 with TDS Sensor (Water Quality Sensor) : https://randomnerdtutorials.com/esp32-tds-water-quality-sensor/

l ESP32 WiFi initialization disrupting GPIO analog reading : https://stackoverflow.com/questions/69782306/esp32-wifi-initialization-disrupting-gpio-analog-reading

2025-03-06 / Sungwook Kang / http://sungwookkang.com

아두이노, ESP32, Arduino, MCU, ESP32 GPIO, ESP32 Pin Map, 핀맵, Pinout Diagram, TDS, 전기전도

[MCU] ESP32 핀맵 (Pinout Diagram) 정리

SungWookKang — Fri, 3 Jan 2025 22:47:08 +0900

[MCU] ESP32 핀맵 (Pinout Diagram) 정리

MCU(Micro Controller Unit)는 마이크로컨트롤러 유닛을 뜻하며, 전자기기의 조작이나 특정 시스템을 제어하는 역할을 하는 집적회로(IC)이다. 일반적으로 “보드”라고 불리기도 한다.

아두이노 보드의 경우 호환 보드가 많고 보드에 붙어있는 확장 디바이스 따라 기능이 추가되기 때문에, 비슷하게 생겼어도 일부 기능들이 조금씩 다르다. 예를들어 ESP32 모델만 하더라도 뒤에 붙는 숫자에 따라 WIFI만 되느냐, 블루투스도 되느냐, 싱글코어이냐 듀얼코어이냐 등이 나뉜다. 그렇기 때문에 MCU를 선택할 때에는 필요한 기능들이 지원되는지 확인할 수 있도록 한다. 물론 해당 기능이 없으면 추가 디바이스 연결로 가능하나 이왕이면 SOC(System On Chip)로 한 디바이스에 포함된 것을 구매하면 여러모로 편리하다.

이렇게 보드(MCU)를 구매하고 나면, 보드마다 핀맵(GPIO)이 다른 경우가 있다. 그래서 이번 포스트에서는 ESP32의 핀맵을 정리하였다.

ESP32 보드는 아래 그림과 같은 모습이다. 물론 모델 번호에 따라 보드의 칩 배열 및 생김새는 조금씩 다르게 생겼지만 ES32 계열의 경우 거의 비슷한 모습을 가지고 있으며 핀 개수 및 기능이 거의 동일하다.

개발 보드에 포함되어 있는 핀의 목록은 다음과 같다.

l 18개의 아날로그-디지털 변환기(ADC) 채널

l 3개의 SPI 통신 인터페이스

l 3개의 UART 통신 인터페이스

l 2개의 I2C 통신 인터페이스

l 16개의 PWM 출력

l 2개의 디지털-아날로그 컨버터(DAC)

l 2개의 I2S 인터페이스

l 10개의 정전 용량 감지 GPIO

아래는 핀맵이다. 일부 핀의 경우 이미 시스템에서 사용하고 있거나 디바이스에 포함된 기능들이 사용하고 있어, 현재 사용중이 아닌 핀을 선별해서 사용해야 한다.

[참고자료]

l A Comprehensive to ESP32 Pinout Diagram : https://www.xecor.com/blog/esp32-pinout-diagram

2025-01-03 / Sungwook Kang / http://sungwookkang.com

아두이노, ESP32, Arduino, MCU, ESP32 GPIO, ESP32 Pin Map, 핀맵, Pinout Diagram

SQL Server Four Part Name 정의 및 PARSERNAME을 활용하여 IP 대역 구하기

SungWookKang — Thu, 2 Jan 2025 22:30:01 +0900

SQL Server Four Part Name 정의 및 PARSERNAME을 활용하여 IP 대역 구하기

l Version : SQL Server 2008 later

SQL Server를 운영하다 보면 Four Part Name 또는 Three Part Name이라는 용어를 접하게 된다. 이러한 용어는 데이터베이스 시스템에서 여러 데이터베이스 간에 개체(테이블, 뷰)를 참조하는데 사용되는 명명 규칙을 의미한다.

l Three-Part Name : 데이터베이스 이름, 스키마, 개체 이름을 포함

ü 예: DatabaseName.dbo.Employee)

l Four-Part Name : 서버 이름을 포함하여 Three-Part Name부분을 확장

ü 예: ServerName.DatabaseName.dbo.Employee)

이렇게 Three-Part 또는 Four-Part를 사용하면 동일한 서버내의 여러 데이터베이스 또는 다른 서버에서 데이터를 쿼리 할 수 있다.

그렇다면 이렇게 구성되어 있는 Four-Part Name에서 특정 Part의 정보만 추출하려면 어떻게 해야 할까? 이럴 때 사용할 수 있는 함수가 PARSENAME이다.

PARSENAME은 Four-Part Name 이름에서 지정된 부분을 반환한다. 검색 가능한 개체의 부분은 서버 이름, 데이터베이스 이름, 스키마 이름, 테이블 이름이다. 함수에 사용되는 매개변수는 선택적으로 정규화된 개체 이름이다.

Value	Description
1	Object Name
2	Schema Name
3	Database Name
4	Server Name

참고로 Four-Part Name의 문자열은 총 길이 256 바이트를 넘을 수 없으며 256 바이트를 초과한 경우 유효한 sysname이 아니므로 NULL이 반환된다.

그러면 이제 PARSENAME를 어떻게 사용하는지 살펴보자. 아래와 같은 Four-Part Name이 있을 때, 매개변수에 따라 각 파트의 값이 반환된다.

DBServer.AdventureWorks2022.Person.Person

-- Uses AdventureWorks
SELECT PARSENAME('DBServer.AdventureWorks2022.Person.Person', 1) AS 'Object Name';
SELECT PARSENAME('DBServer.AdventureWorks2022.Person.Person', 2) AS 'Schema Name';
SELECT PARSENAME('DBServer.AdventureWorks2022.Person.Person', 3) AS 'Database Name';
SELECT PARSENAME('DBServer.AdventureWorks2022.Person.Person', 4) AS 'Server Name';
GO

그렇다면 Three-Part Name의 경우는 어떻게 결과 값이 반환될까? 서버 이름을 제외하고 함수를 실행해 본다.

-- Uses AdventureWorks
SELECT PARSENAME('AdventureWorks2022.Person.Person', 1) AS 'Object Name';
SELECT PARSENAME('AdventureWorks2022.Person.Person', 2) AS 'Schema Name';
SELECT PARSENAME('AdventureWorks2022.Person.Person', 3) AS 'Database Name';
SELECT PARSENAME('AdventureWorks2022.Person.Person', 4) AS 'Server Name';
GO

마지막 서버이름의 반환 값이 NULL인 것을 확인할 수 있다. PARSENAME의 경우 뒤에서부터 하나씩 값을 읽기 때문에, 중간에 다른 이름을 삭제하더라도, 순차적으로 읽어 파싱하기 때문에 자릿수가 부족할 경우 그 자리는NULL 값으로 대체한다. 그렇기 때문에 무조건 서버이름이 NULL을 반환한다고 볼 수는 없지만, 정규화된 이름의 경우 항상 그 규칙이 있기 때문에 준수해서 사용하면 엉뚱한 값을 얻을 일은 없다.

그럼 이제 PARSENAME을 활용해서 IP의 대역을 파싱 하는 작업을 진행해보자. IP의 경우에도 Four -Part Name으로 이루어져 있으며, 각 파트는 점(.)으로 구분한다. 그렇기 때문에 IP를 파싱하는 용도는 아니지만 유사한 구조를 활용하여, 쉽게 파싱해서 사용할 수 있다.

SELECT PARSENAME('192.168.0.1', 1) AS 'D Class';
SELECT PARSENAME('192.168.0.1', 2) AS 'C Class';
SELECT PARSENAME('192.168.0.1', 3) AS 'B Class';
SELECT PARSENAME('192.168.0.1', 4) AS 'A Class';
GO

PARSENAME으로 활용할 수 있는 부분은 IP외에도, 파싱 규칙이 점(.)으로 구분하기 때문에 Four-Part로 표현된 데이터라면 구분자를 점(.)으로 치환한다음 사용할 수 있다.

SELECT PARSENAME(REPLACE('A-B-C-D', '-', '.'), 1) AS 'D Class';
SELECT PARSENAME(REPLACE('A-B-C-D', '-', '.'), 2) AS 'C Class';
SELECT PARSENAME(REPLACE('A-B-C-D', '-', '.'), 3) AS 'B Class';
SELECT PARSENAME(REPLACE('A-B-C-D', '-', '.'), 4) AS 'A Class';

다양한 포맷의 데이터를 파싱 하려면 CHARINDEX 등을 활용하여 특정 문자열까지 자르고, 이후 자릿수를 계산해서 구하는 등 여러 함수를 조합하여 사용할 수 있지만, Four-Part 형식의 데이터라면 PARSENAME를 활용할 수 있다.

l 다양한 포맷의 이름 파싱 하기 : https://sungwookkang.com/entry/%EB%8B%A4%EC%96%91%ED%95%9C-%ED%8F%AC%EB%A7%B7%EC%9D%98-%EC%9D%B4%EB%A6%84-%ED%8C%8C%EC%8B%B1-%ED%95%98%EA%B8%B0

[참고자료]

l Transact-SQL syntax conventions : https://learn.microsoft.com/en-us/sql/t-sql/language-elements/transact-sql-syntax-conventions-transact-sql

l PARSENAME : https://learn.microsoft.com/en-us/sql/t-sql/functions/parsename-transact-sql

2025-01-02/ Sungwook Kang / http://sungwookkang.com

SQL Server, MS SQL, Four-Part Name, Three-Part Name, PARSENAME, FQDN, 포파트네임, 쓰리파트 네임, 파스네임, IP대역 구하기

[Kafka] ksqlDB를 사용하여, SQL 구문으로 쉽고 빠르게 카프카 데이터 조회하기

SungWookKang — Tue, 26 Mar 2024 10:42:03 +0900

[Kafka] ksqlDB를 사용하여, SQL 구문으로 쉽고 빠르게 카프카 데이터 조회하기

l Kafka 3.6.2, KsqlDB

Kafka(이하 “카프카”) 토픽에 저장되어 있는 데이터를 사용하기 위해서는 컨슈머라는 것이 필요하고, 컨슈머에는 각 비즈니스에 필요한 로직을 포함하여 원하는 데이터를 제공한다. 이렇게 시스템을 구성해 놓으면 빠르고 편리하게 메시징 처리를 할 수 있다. 그런데 실시간으로 카프카의 데이터를 조회(집계, 조인)하거나, 카프카 내부의 토픽 데이터를 조합해서 새로운 토픽 데이터 생성이 필요할 때가 있다. 이 경우 매번 컨슈머를 개발하거나 CLI를 통해 구축하는 것은 매우 번거롭고 익숙하지 않은 사용자에게는 어려운 작업일 수 있다. 이때 ksqlDB를 사용하면, 유사SQL문을 사용하여 데이터를 조회하거나, 스트림을 생성하거나, 실시간으로 다양한 작업을 할 수 있다.

이번 포스트에서는 ksqlDB가 무엇인지, 그리고 설치와 간단히 데이터를 조회하는 방법에 대해서 알아본다.

[ksqlDB 기능]

ksqlDB에서 제공하는 대표적인 기능은 다음과 같다.

l 저장된 데이터가 아닌 계속 움직이는 데이터를 처리하여 실시간 값 생성 : 비즈니스 전반에 걸쳐 생성된 데이터 스트림을 지속적으로 처리하여 데이터를 즉시 실행 가능하도록 한다.

l 스트림 처리 아키텍처 단순화 : ksqlDB는 데이터 스트림을 수집하고, 강화하며, 새롭게 파생된 스트림과 테이블에 대한 쿼리를 제공하기 위한 단일 솔루션을 제공한다.

l 간단한 SQL 구문으로 실시간 애플리케이션 구축 시작 : 친숙하고 가벼운 SQL 구문을 통해 관계형 데이터베이스에서 기존 애플리케이션을 구축하는 것과 마찬가지로 쉽고 친숙한 방식으로 실시간 애플리케이션을 구축할 수 있다.

ksqlDB에 대한 자세한 내용은 아래 링크를 참고한다.

l ksqlDB : https://ksqldb.io/

[ksqlDB 구성요소]

KsqlDB는 다음과 같은 요소로 구성되어 있다.

l ksqlDB 엔진: ksqlDB 엔진은 SQL 문과 쿼리를 실행한다. SQL 문을 작성하여 애플리케이션 논리를 정의하면 엔진이 사용 가능한 ksqlDB 서버에서 애플리케이션을 빌드하고 실행한다. 내부적으로 엔진은 SQL 문을 구문 분석하고 해당 Kafka Streams 토폴로지를 구축한다. ksqlDB 엔진은 KsqlEngine.java 클래스에서 구현된다.

l ksqlDB CLI: ksqlDB CLI는 ksqlDB 엔진용 명령줄 인터페이스가 포함된 콘솔을 제공한다. ksqlDB CLI를 사용하여 ksqlDB 서버 인스턴스와 상호 작용하고 스트리밍 애플리케이션을 개발한. ksqlDB CLI는 MySQL, Postgres 및 유사한 애플리케이션 사용자에게 친숙하도록 설계되었다. ksqlDB CLI는 io.confluent.ksql.cli 패키지에서 구현된다.

l REST 인터페이스: REST 서버 인터페이스를 사용하면 CLI, Confluent Control Center 또는 기타 REST 클라이언트에서 ksqlDB 엔진과 통신할 수 있다. ksqlDB REST 서버는 KsqlRestApplication.java 클래스에서 구현된다.

Ksql의 아키텍처 및 자세한 내용을 알고 싶다면 아래 링크를 참고한다.

l ksqlDB How it works : https://docs.ksqldb.io/en/latest/operate-and-deploy/how-it-works/

[ksqlDB 설치]

ksqlDB는 카프카에서 실행되므로 반드시 카프카가 실행되어 있어야 한다. 이번 포스트에서는 ksqlDB의 독립실행형 컨테이너로 설치한다.

도커 컴포즈 파일을 실행하여, 컨테이너를 실행한다.

docker-compose.yml

version: '3.8'
services:
ksqldb-server:
    image: confluentinc/ksqldb-server
    hostname: ksqldb-server
    container_name: ksqldb-server
    ports:
      - "8088:8088"
    environment:
      KSQL_LISTENERS: http://0.0.0.0:8088
      KSQL_BOOTSTRAP_SERVERS: 172.18.43.151:9092
      KSQL_KSQL_LOGGING_PROCESSING_STREAM_AUTO_CREATE: "true"
      KSQL_KSQL_LOGGING_PROCESSING_TOPIC_AUTO_CREATE: "true"

ksqldb-cli:
    image: confluentinc/ksqldb-cli
    container_name: ksqldb-cli
    entrypoint: /bin/sh
    tty: true

[ksqlDB로 카프카 데이터 조회]

컨테이너가 정상적으로 실행되었으면, 아래 명령어로 ksqlDB에 접속한다. (이 포스트에서 실습 환경은 카프카와 ksqlDB가 같은 서버에서 운영중이다.)

docker exec -it ksqldb-cli ksql http://ksqldb-server:8088

ksqlDB에서 사용할 수 있는 토픽 목록을 조회한다.

show topics;

토픽을 사용하여 카프카 스트림을 생성한다.

create stream swkang (
payload STRUCT<before STRUCT<num int, name varchar, email varchar>,
after STRUCT<num int, name varchar, email varchar>>
)
WITH (kafka_topic = 'server1.swkang_test.dbo.tbl_a', value_format='json');

생성된 스트림 목록을 확인한다.

show streams;

스트림의 데이터를 조회해 보자. 이때 조회 명령은 SQL문과 동일하다.

select * from swkang;

그런데 데이터를 살펴보니, 각 컬럼별로 나누어져 있지 않고, JSON 형태로 조회된 것을 볼 수 있다. 이러한 JSON 형태의 데이터를 각 컬럼 포맷으로 분리하기 위해서는 데이터 스트럭처를 제공해주어야 한다. 우선 데이터 스트럭처가 어떻게 되어 있는지 확인해 보자.

describe swkang;

이제 데이터를 조회할 때, 스트럭처 정보를 함께 제공하여 조회한다.

SELECT
    PAYLOAD->"BEFORE"->"NUM" as before_num,
    PAYLOAD->"BEFORE"->"NAME" as before_name,
    PAYLOAD->"BEFORE"->"EMAIL" as before_email,
    PAYLOAD->"AFTER"->"NUM" as after_num,
    PAYLOAD->"AFTER"->"NAME" as after_name,
    PAYLOAD->"AFTER"->"EMAIL" as after_email
FROM
    swkang;

지금까지 ksqlDB 기능 및, 설치 방법과 카프카의 데이터를 조회하는 방법에 대해서 알아보았다. 이처럼 ksqlDB를 사용하면 편리하게 SQL문을 사용하여 데이터 조회 및 스트림 생성, 스트림 테이블 생성 등 다양한 작업들을 진행할 수 있다. ksqlDB에서 제공하는 쿼리문이 다양하므로, 공식 문서를 참고할 수 있도록 한다.

[참고자료]

l ksqlDB : https://ksqldb.io/

l ksqlDB How it works : https://docs.ksqldb.io/en/latest/operate-and-deploy/how-it-works/

2024-03-26 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, ksqlDB, 카프카 조회, 토픽 조회, 카프카 스트림즈, 데이터 실시간 조회, 데이터 엔지니어

[Kafka] Kafka와 Debezium을 활용하여 SQL Server의 데이터를 실시간으로 PostgreSQL로 복제하기

SungWookKang — Mon, 26 Feb 2024 10:57:25 +0900

[Kafka] Kafka와 Debezium을 활용하여 SQL Server의 데이터를 실시간으로 PostgreSQL로 복제하기

l Kafka 3.6.2, Debezium 2.5, SQL Server 2019, PostgreSQL 12

Kafka(이하 “카프카”)와 카프카 커넥터인 Debezium을 활용하여 SQL Server에서 발생하는 실시간 DML을 캡처하여 PostgreSQL로 데이터를 복제하는 방법에 대해서 알아본다. 이번 포스트에서는 실시간 데이터 복제를 위한 구성 정도로만 다루고, 각 단계에서의 상세한 기술 내용은 추후 다른 포스팅에서 다룰 예정이다.

[Architecture]

이번에 구축하려는 시스템의 아키텍처는 아래와 같다. 어플리케이션에서 MS SQL Server의 데이터를 변경하면 SQL Server의 CDC 기능을 사용하여 변경 사항을 캡처한다. Debezium은 변경 사항을 확인하여 Kafka로 데이터를 입력한다. 그리고 카프카에서 PostgreSQL로 실시간 데이터를 복제한다.

시스템	버전
Kafka	3.6.2
Debezium	2.5.1
SQL Server	2019
PostgreSQL	12

[카프카 설치]

카프카 설치는 아래 링크를 참고한다.

l [Kafka] Kafka 클러스터 4노드 구성 - Controller, Broker 혼합해서 구성하기 : https://sungwookkang.com/entry/Kafka-Kafka-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-4%EB%85%B8%EB%93%9C-%EA%B5%AC%EC%84%B1-Controller-Broker-%ED%98%BC%ED%95%A9%ED%95%B4%EC%84%9C-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0

[Debezium 커넥터 설치]

카프카에서 MS SQL Server과PostgreSQL에 연결하기 위한 Debezium 커넥터를 다운로드하여 설치한다.

l Debezium : https://debezium.io/releases/2.5/#installation

다운로드 후 압축을 해제한다. 필자의 경우 카프카 디렉터리에 plugins라는 디렉토리를 생성하여 파일을 위치하였다. 사용자에 따라 파일 위치를 다르게 가능하며, 이후 카프카 커넥터 설정에서 해당 위치의 경로를 지정하여 사용하기 때문에 경로가 달라도 상관없다.

#SQL Server Connector
tar xvf debezium-connector-sqlserver-2.5.0.Final-plugin.tar.gz -C /usr/local/kafka/plugins/
#PostgreSQL Connector
tar -xvzf debezium-connector-jdbc-2.2.1.Final-plugin.tar.gz -C /usr/local/kafka/plugins/

[카프카에서 커넥터 설정 및 서비스 시작]

카프카에서 커넥터를 사용하기 위해 커넥터의 경로를 설정하고, 서비스를 시작한다. 카프카 디렉토리에서 connect-distributed.properties에서 아래 항목을 수정한다.

cd /usr/local/kafka

vi ./config/connect-distributed.properties

#Broker Node IP
bootstrap.servers=XXX.XXXX.XXX.XXX:9092

#Debezium path
plugin.path=/usr/local/kafka/plugins

커넥터 서비스를 시작한다.

cd /usr/local/kafka

./bin/connect-distributed.sh -daemon ./config/connect-distributed.properties

커넥터가 정상적으로 실행되면 8083포트를 통해서 정보를 확인할 수 있다.

curl localhost:8083/connector-plugins | jq

[SQL Server CDC 활성화]

SQL Server에서 데이터의 변경을 실시간으로 캡처하기 위해서는 CDC 기능을 활성화한다. SQL Server CDC에 대한 자세한 내용은 아래 링크를 참고한다.

l Enable and disable change data capture : https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-data-capture-sql-server?view=sql-server-ver16

실습을 위한 데이터베이스 및 테이블을 생성한다. 테이블에는 반드시 Primary key 컬럼이 필요하다.

CREATE DATABASE swkang_test
GO

USE swkang_test
GO

CREATE TABLE tbl_a(
num int primary key,
name nvarchar(50),
reg_date datetime
)
GO

CDC 기능을 활성화한다.

USE swkang_test
GO

-- CDC Enable Database
EXEC sys.sp_cdc_enable_db
GO
/*
EXEC sys.sp_cdc_disable_db
GO
*/

-- CDC Enable Table
EXEC sys.sp_cdc_enable_table
@source_schema = N'dbo',
@source_name = N'tbl_a',
@role_name = '',
@supports_net_changes = 1
GO
/*
EXEC sys.sp_cdc_disable_table
@source_schema = N'dbo',
@source_name = N'tbl_a',
@capture_instance = N'dbo_tbl_a'
*/

데이터베이스가 CDC 활성화가 되었는지 확인하는 방법은 아래 스크립트를 사용한다.

select name, is_cdc_enabled from sys.databases where is_cdc_enabled = 1

CDC 대상 테이블을 확인하는 방법은 아래 스크립트를 사용한다.

Select name, is_tracked_by_cdc from sys.tables;

[Source Connector 정보 등록 (SQL Server)]

Debezium API를 사용하여, 소스 커넥터 정보를 입력한다. 필자는 postman 툴을 사용하여 API를 호출하였다. (각 속성에 대한 설명은 이번 포스트에서는 다루지 않는다.)

http://kafka-ip:8083/connectors

{
    "name": "inventory-connector",
    "config": {
        "connector.class" : "io.debezium.connector.sqlserver.SqlServerConnector",
        "tasks.max": "1",
        "topic.prefix": "server1",
        "database.hostname" : "SQL Server IP",
        "database.server.name": "DB Name (Friendly name)",
        "database.port" : "1433",
        "database.user" : "swkang_cdc",
        "database.password" : "******",
        "database.names" : "swkang_test",
        "include.schema.changes": "true",
        "include.schema.comments" : "true",
        "tombstones.on.delete":"true",
        "schema.history.internal.kafka.bootstrap.servers" : "localhost:9092",
        "schema.history.internal.kafka.topic": "schema-changes.inventory1",
        "database.encrypt": "false"
    }
}

[Target Connector 정보 등록 (PostgreSQL)]

소스의 데이터를 타겟으로 복제하기 위해 타겟 데이터베이스인 PostgreSQL의 연결 정보를 등록한다. (각 속성에 대한 설명은 이번 포스트에서는 다루지 않는다.)

{
"name": "postgresql_target_sink",
"config": {
      "connector.class": "io.debezium.connector.jdbc.JdbcSinkConnector",
      "tasks.max": "1",
      "connection.url": "jdbc:postgresql://localhost/swkang_test",
      "connection.username": "cdc_user",
      "connection.password": "******",
      "insert.mode": "upsert",
      "delete.enabled": "true",
      "primary.key.mode": "record_key",
      "schema.evolution": "basic",
      "database.time_zone": "UTC",
      "topics": "server1.swkang_test.dbo.tbl_a"
}
}

[실시간 데이터 복제 실습]

SQL Server에서 데이터를 입력한 다음 PostgreSQL에서 데이터를 확인한다. 이때 PostgreSQL에서는 테이블을 생성하지 않아도 SQL Server의 스키마 정보를 읽고 테이블을 자동으로 생성하고, 데이터를 복제한다.

SQL Server에서 아래 스크립트를 실행하여 데이터를 입력한다.

insert into tbl_a values (1, 'a_skang1', 'skang1@nowcom.com')
insert into tbl_a values (2, 'a_skang2', 'skang2@nowcom.com')
insert into tbl_a values (3, 'a_skang3', 'skang2@nowcom.com')
insert into tbl_a values (4, 'a_skang4', 'skang4@nowcom.com')
insert into tbl_a values (5, 'a_skang5', 'skang5@nowcom.com')
insert into tbl_a values (6, 'a_skang6', 'skang6@nowcom.com')
insert into tbl_a values (7, 'a_skang6', 'skang6@nowcom.com')
insert into tbl_a values (8, 'a_skang8', 'skang8@nowcom.com')

PostgreSQL에서 데이터를 확인한다. 실시간으로 MS SQL Server의 데이터가 PostgreSQL로 복제된 것을 확인할 수 있다.

이번 포스트에서는 카프카의 Debezium을 활용하여 SQL Server에서 PostgreSQL로 복제를 진행하였다. Debezium 커넥터에서 제공하는 여러 커넥터를 활용하면 다양한 소스 데이터베이스에서 다양한 타겟 데이터베이스로 데이터를 실시간으로 복제할 수 있다.

[참고자료]

l Kafka Connect Elasticsearch Connector in Actio : https://www.confluent.io/blog/kafka-elasticsearch-connector-tutorial/

l How to Use Kafka Connect - Get Started : https://docs.confluent.io/platform/current/connect/userguide.html#connect-installing-plugins

l Debezium Release Series 2.5 : https://debezium.io/releases/2.5/

l Enable and disable change data capture : https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-data-capture-sql-server?view=sql-server-ver16

2024-02-26 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, 데비지움, Debezium, 데이터복제, Kafka CDC, 카프카 스트림즈, 데이터 실시간 복제, 데이터 엔지니어

[Kafka] Kafka 컨슈머(Consumer) 이해하기

SungWookKang — Tue, 23 Jan 2024 11:38:21 +0900

[Kafka] Kafka 컨슈머(Consumer) 이해하기

l Kafka

카프카는 메시지를 생산, 발송하는 프로듀서(producer)와 메시지를 수신, 소비하는 컨슈머(consumer)가 있으며, 프로듀서와 컨슈머 사이에서 메시지를 중개하는 브로커(broker)로 구성된다. 이번 포스트는 컨슈머에 대해서 알아본다.

프로듀서가 카프카의 토픽으로 메시지를 보내면 그 토픽의 메시지를 가져와 소비하는 역할을 하는 애플리케이션, 서버 등을 지칭해서 컨슈머(Consumer)라고 한다. 컨슈머의 주요 기능은 파티션 리더에게 메시지를 가져오기를 요청하는 것이다. 각 요청은 로그의 오프셋을 명시하고 그 위치로부터 로그 메시지를 수신한다. 그래서 컨슈머는 수신할 메시지의 위치를 조정할 수 있으며, 이미 수신한 메시지를 다시 수신할 수도 있다.

카프카 컨슈머의 또 하나 특징은 하나의 토픽에 서로 다른 컨슈머 애플리케이션이 동시에 구독할 수 있다는 것이다. 위 그림을 살펴보면, 각 토픽에 여러 컨슈머가 동시에 구독하는 것을 볼 수 있다. 단일 토픽에 대한 멀티 컨슈밍이 가능한 이유는 컨슈머가 메시지를 읽어도 브로커에서 메시지가 유지되기 때문이다. 대신에 각 컨슈머는 파티션의 어느 오프셋까지 읽었는지를 구분하기 위해 컨슈머 오프셋(_consumer_offset) 정보를 토픽에 저장한다. 그렇기 때문에 컨슈머는 오프셋에 저장된 정보를 통해 안정적으로 메시지를 읽어올 수 있다.

[컨슈머 그룹]

컨슈머를 실행할 때는 항상 컨슈머 그룹이라는 것이 필요하다. 만약 컨슈머를 실행할 때 옵션으로 그룹을 설정하지 않으면 자동적으로 console-consumer-xxxxx(숫자형태) 형식의 컨슈머 그룹이 생성된다. 컨슈머 그룹은 하나의 토픽에 여러 컨슈머 그룹이 동시에 접속해 메시지를 가져올 수 있다.

컨슈머 그륩은 확장도 가능하다. 만약 프로듀서가 토픽에 보내는 메시지 속도가 증가하여 컨슈머가 메시지를 가져가는 속도보다 빨라지면, 컨슈머가 처리하지 못한 메시지들이 점점 많아지기 때문에 컨슈머를 확장하여 이 문제를 해결해야 한다. 이때 단순히 컨슈머만 확장한다면 기존의 컨슈머어 오프셋 정보와 새로 추가된 컨슈머의 오프셋 정보가 뒤섞이면서 수신되는 메시지들이 엉망이 될 수 있다. 그래서 카프카에서는 동일한 토픽에 대해 여러 컨슈머가 메시지를 가져갈 수 있도록 컨슈머 그룹이라는 기능을 제공한다.

컨슈머 그룹안에서는 컨슈머들은 메시지를 가져오고 있는 토픽의 파티션에 대해 소유권을 공유한다. 위 그림을 보면, Consumer2를 추가함으로써 Partition1의 소유권이 Consumer2로 이동하는데 이렇게 소유권을 이동하는 것을 리밸런스(rebalance)라고 한다. 이러한 리밸런스를 통해 컨슈머 그룹에서는 컨슈머를 쉽고 안전하게 추가할 수 있다. 하지만 리밸런스를 하는 동안 일시적으로 컨슈머 그룹 전체는 메시지를 가져올 수 없다는것에 주의하자. 그 이유는 컨슈머 그룹 내에서 리밸런스가 일어나면 토픽의 각 파티션마다 하나의 컨슈머가 연결되기 때문이다.

그렇다면, 메시지 수가 많아 토픽에 메시지가 점점 쌓이는 상황일 때, 단순히 컨슈머만 추가하면 메시지 적체 현상이 해소될까? 정답은 “아니오” 이다. 위에서 설명할 때, 컨슈머는 하나의 파티션에 매핑 된다고 했다. 그렇기 때문에 파티션개수보다 컨슈머가 많을 경우 일부 컨슈머는 아무일도 하지 않고 대기하게 된다. 그래서 파티션 개수와 컨슈머의 개수를 함께 늘려줘야 한다. 이때 컨슈머의 노드ID는 중복되지 않도록 주의한다.

컨슈머는 일정한 주기로 하트비트를 보내는데, 이를 통해서 메시지를 잘 처리하고 있다는 것을 판단한다. 기존의 하트비트 방식은 컨슈머가 poll할 때와 가져간 메시지를 커밋할 때 보낸다. 만약 컨슈머가 오랫동안 하트비트를 보내지 않으면 세션은 타임아웃되고 해당 컨슈머가 문제가 있다고 판단하여 리밸런스를 시작한다. 이러한 상황을 지속되면 메시지를 늦게 가져오는 현상이 발생할 수 있기 때문에 모니터링을 통해 컨슈머의 장애 상황을 인지하고 새로운 컨슈머를 추가하여 정상적인 상태를 유지할 수 있도록 해야한다.

새로운 하트비트 방식 (KIP-62)에서는 백그라운드 스레드가 도입되어 사용자가 poll()을 호출하기를 기다리는 대신 이 스레드는 Kafka에 우리가 잘 작동하고 있음을 알리는 역할을 한다. 따라서 전체 프로세스가 하트비트 스레드와 함께 종료되면 Kafka는 이를 신속하게 발견하고 하트비트가 비동기식으로 더 자주 전송되기 때문에 레코드 처리에 소요되는 시간에 더 이상 영향을 받지 않는다.

[커밋과 오프셋]

컨슈머 그룹의 컨슈머들은 각각의 파티션에 자신이 가져가 메시지의 위치 정보(오프셋)을 기록한다. 이렇게 현재의 위치를 업데이트 하는 동작을 커밋(commit) 이라고 한다. 컨슈머에 장애가 발생하거나 새로운 컨슈머가 추가되었을 때 리밸런싱이 발생하고, 컨슈머는 새로운 파티션에 대해 가장 최근 커밋된 오프셋을 읽고 그 이후부터 메시지들을 가져온다. 만약 커밋된 오프셋이 컨슈머가 실제 마지막으로 처리한 오프셋보다 작으면 메시지는 중복으로 처리되고, 커밋된 오프셋이 컨슈머가 실제 마지막으로 처리한 오프셋 보다 크다면 마지막으로 처리된 오프셋과 커밋된 오프셋 사이의 모든 메시지는 누락된다. 이러한 동작방식 때문에 커밋은 매우 중요하다.

l 자동 커밋 : 기본값 5초마다 컨슈머가 poll()을 호출할 때마다 가장 마지막 오프셋 값을 커밋한다. Enable.atuo.commit=true로 설정이 가능하며, auto.commit.interval.ms 옵션을 통해 조정이 가능하다. 자동으로 오프셋을 커밋하는 방법은 매우 편리하지만 리밸런싱으로 인한 중복이 발생할 수 있기 때문에 동작에 대해 잘 이해하고 사용하는 것이 좋다.

l 수동 커밋 : 이 경우는 메시지 처리가 완료 될 때까지 메시지를 가져온 것으로 간주되어서는 안되는 경우에 사용한다. 컨슈머 객체의 commitAsync()혹은 commitSync()를 통해 직접 커밋해야 한다. 수동 커밋의 경우에도 중복은 발생할 수 있다.

[컨슈머 주요 옵션]

l bootstrap.servers : 카프카 클러스터에 처음 연결을 하기 위한 호스트와 포트 정보로 구성된 리스트 정보. 특정 호스트 정보만 사용시, 해당 호스트만 장애가 발생하는 경우에는 접속이 불가하기 때문에, 리스트 전체를 입력하는 방식을 권장한다.

l fetch.min.bytes : 한번에 가져올 수 있는 최소 데이터 사이즈로, 지정한 사이즈보다 작은 경우, 요청에 대해 응답하지 않고 데이터가 누적될때까지 기다린다.

l group.id : 컨슈머가 속한 컨슈머 그룹을 식별하는 식별자로, 그룹 아이디이다.

l enable.auto.commit : 백그라운드로 주기적으로 오프셋을 커밋한다.

l auto.offset.reset : 카프카에서 초기 오프셋이 없거나 현재 오프셋이 더이상 존재하지 않은 경우(데이터가 삭제)에 다음 옵션으로 리셋한다. (- earliest : 가장 초기의 오프셋값으로 설정 - lastest : 가장 마지막의 오프셋값으로 설정 - none : 이전 오프셋값을 찾지 못하면 에러를 리턴)

l fetch.max.bytes : 한번에 가져올 수 있는 최대 데이터 사이즈이다.

l request.timeout.ms : 요청에 대해 응답을 기다리는 최대 시간이다

l session.timeout.ms : 컨슈머와 브로커 사이의 세션 타임 아웃 시간(기본값 10초)으로 브로커가 컨슈머가 살아있는 것으로 판단하는 시간이다.

l heartbeat.interval.ms : 그룹 코디네이터에게 얼마나 자주 KafkaConsumer poll() 메소드로 하트비트를 보낼 것인지 조정 (기본값은 3초) 한다.

l max.poll.records : 단일 호출 poll()에 대한 최대 레코드 수를 조정한다. 이 옵션을 통해 애플리케이션이 폴링 루프에서 데이터 양을 조정할 수 있다.

l max.poll.interval.ms : 컨슈머가 살아있는지를 체크하기 위해 하트비트를 주기적으로 보내는데, 컨슈머가 계속해서 하트비트만 보내고 실제로 메시지를 가져가지 않는 경우가 있을 수도 있다. 이러한 경우 컨슈머가 무한정 해당 파티션을 점유할 수 없도록 주기적으로 poll을 호출하지 않으면 장애라고 판단하고 컨슈머 그룹에서 제외한 후 다른 컨슈머가 해당 파티션에서 메시지를 가져갈 수 있게 한다.

l auto.commit.interval.ms : 주기적으로 오프셋을 커밋하는 시간이다.

l fetch.max.wait.ms : fetch.min.bytes에 의해 설정된 데이터보다 적은 경우 요청에 응답을 기다리는 최대 시간이다.

[참고자료]

l Kafka Consumers : https://ibm-cloud-architecture.github.io/refarch-eda/technology/kafka-consumers/

l https://docs.confluent.io/kafka/design/consumer-design.html

l What does the heartbeat thread do in Kafka Consumer? : https://chrzaszcz.dev/2019/06/kafka-heartbeat-thread/

l KIP-62: Allow consumer to send heartbeats from a background thread : https://cwiki.apache.org/confluence/display/KAFKA/KIP-62%3A+Allow+consumer+to+send+heartbeats+from+a+background+thread

2024-01-23 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, 카프카 토픽, 카프카 파티션, Kafka Topic, Kafka Partition, 카프카 복제, Kafka Replication, 컨슈머, Consumer, Kafka Consumer, 카프카 컨슈머

[Kafka] Kafka 프로듀서(Producer) 이해하기

SungWookKang — Mon, 22 Jan 2024 15:00:06 +0900

[Kafka] Kafka 프로듀서(Producer) 이해하기

l Kafka

카프카는 메시지를 생산, 발송하는 프로듀서(producer)와 메시지를 수신, 소비하는 컨슈머(consumer)가 있으며, 프로듀서와 컨슈머 사이에서 메시지를 중개하는 브로커(broker)로 구성된다. 이번 포스트는 프로듀서에 대해서 알아본다.

메시지를 생산(producer)해서 카프카의 토픽으로 메시지를 보내는 역할을 하는 애플리케이션, 서버 등을 모두 프로듀서라고 한다. 프로듀서의 주요 기능은 각각의 메시지를 토픽 파티션에 매핑하고 파티션의 리더에 요청을 보내는 것이다. 이때 키 값을 정해 해당 키를 가진 모든 메시지를 동일한 파티션으로 전송할 수 있으며, 키를 지정하지 않으면 라운드 로빈 방식으로 파티션에 균등하게 배분한다.

프로듀서는 아래 과정을 통해서 메시지를 브로커로 전달한다.

1. Serialize

2. Partition

3. Compress

4. Accumulate records

5. Group by broker and send

[Serialize]

프로듀서 레코드가 프로듀서에게 전달된 직렬 변환기를 기반으로 직렬화된다. 키와 값은 모두 전달된 직렬 변환기를 기반으로 직렬화된다. 일부 직렬 변환기에는 문자열 직렬 변환기, byteArray 직렬 변환기 및 ByteBuffer 직렬 변환기가 포함된다.

[Partitioner]

프로듀서는 레코드를 기록해야하는 주제의 파티션을 결정한다. 기본적으로 murmur2 알고리즘이 파티셔닝에 사용된다. Murmur 2 알고리즘은 전달된 키를 기반으로 고유한 해시 코드를 생성하고 적절한 파티션이 결정된다. 키가 전달되지 않은 경우 라운드 로빈 방식으로 파티션이 선택된다.

동일한 키를 레코드 세트에 전달함으로써 Kafka는 주어진 수의 파티션에 대해 수신된 순서대로 동일한 파티션에 메시지가 기록되도록 보장한다는 점을 이해하는 것이 중요하다. 수신된 메시지의 순서를 유지하려면 메시지에 적절한 키를 사용하는 것이 중요하다. 사용자 정의 파티셔너를 프로듀서에게 전달하여 메시지를 써야 하는 파티션을 제어할 수도 있다.

[Compression]

프로듀서 레코드가 레코드 누산기에 기록되기 전에 압축된다. 기본적으로 Kafka 생산자에서는 압축이 활성화되어 있지 않다. 지원되는 압축 유형은 다음과 같다.

[Record Accumulator]

레코드가 주제의 파티션당 버퍼에 누적된다. 레코드는 프로듀서 배치 크기 속성에 따라 배치로 그룹화된다. 주제의 각 파티션은 별도의 누산기/버퍼를 갖는다.

[Sender thread]

레코드 누산기의 파티션 배치가 전송될 브로커별로 그룹화된다. 배치의 레코드는 batch.size 및 linger.ms 속성을 기반으로 브로커로 전송된다. 레코드는 정의된 배치 크기에 도달하거나 정의된 지연 시간에 도달한 경우로 두 가지 조건에 따라 프로듀서가 전송한다.

[Duplicate message detection]

Kafka에서 메시지를 커밋했지만 네트워크 오류 및 기타 문제로 인해 프로듀서가 승인을 받지 못한 경우 프로듀서는 중복된 메시지를 보낼 수 있다. 이 경우 중복 메시지를 피하기 위해 Kafka는 생산자 ID 및 시퀀스 번호를 기반으로 각 메시지를 추적한다. 동일한 생산자 ID 및 시퀀스 번호를 가진 커밋된 메시지에 대해 중복 메시지가 수신되면 Kafka는 해당 메시지를 중복 메시지로 처리하고 프로듀서가 메시지를 처리할 수 있도록 승인을 프로듀서에게 다시 보낸다.

[프로듀서의 주요 설정]

l bootstrap.servers : 카프카 클러스터는 마스터라는 개념이 없기 때문에 클러스터 내 모든 서버가 클라이언트 요청을 받을 수 있다. 그래서 전체 카프카 호스트 정보를 입력한다. 특정 노드의 정보만 사용해도 되지만 해당 노드가 장애시 접속이 불가능하기 때문에 전체 노드 정보를 입력하는 것을 추천한다.

l key.serializer : 메시지의 키를 직렬화 할 때 사용할 클래스를 설정한다. 직렬화 클래스의 경로를 입력한다.

l value.serializer : 메시지의 값을 직렬화 할 때 사용할 클래스 설정한다. 직렬화 클래스의 경로를 입력한다.

l partitioner.class : 파티셔너로 사용할 클래스 설정한다. 해당 클래스 경로를 넣으며, 기본 값은 카프카에서 제공하는 DefaultPartitioner 클래스에 대한 경로이다.

l compression.type : 압축 타입에 관한 설정으로 어떤 타입으로 압축할 것인지 정할 수 있다.

l buffer.memory : Record Accumulator에서 사용할 메모리의 총 양에 관한 설정으로 해당 설정 값을 초과하면 프로듀서가 정상 동작하지 않는다.

l batch.size : 레코드 배치의 크기에 관한 설정(bytes)으로 프로듀서가 카프카 서버로 데이터를 보내기 위하 잠시 대기(배치 전송이나 딜레이)할 수 있는 전체 메모리 바이트 이다. 레코드 배치가 해당 설정 값에 다다르면 메시지를 전송한다.

l linger.ms : 레코드 배치의 최대 전송 대기 시간 설정(ms)으로, batch.size에 만족하지 않더라도 레코드 배치는 이 설정에 따라 전송된다. 기본값은 0이며 즉시 전송한다. 0 보다 큰 경우 해당 시간만큼 지연되어 처리된다.

l retires : 일시적인 오류로 인해 전송에 실패한 데이터를 재전송 하는 횟수에 관한 설정이다.

l max.in.flight.requests.per.connection : 프로듀서가 응답 여부에 상관없이 한 번에 보낼 수 있는 요청 횟수에 관한 설정. 2 이상이면 한 번의 연결에서 2개 이상의 메시지 전송 요청을 보낼 수 있다.

l acks : 프로듀서가 전송 후 브로커의 응답을 기다리는 설정이다. 해당 옵션의 값이 작으면 성능이 좋지만, 메시지 손실 가능상이 있고, 반대로 크면 성능이 좋지 않지만 메시지 손실 가능성이 적어진다.

ü Acks=0 : 프로듀서는 서버로부터 어떠한 응답을 기다리지 않는다. 이 경우 서버가 데이터를 받았는지 보장하지 않고, 클라이언트는 전송 실패에 대한 결과를 알지 못하게 때문에 재요청 설정도 적용되지 않는다. 서버로부터 ack에 대한 응답을 기다리지 않기 때문에 매우 빠르게 메시지를 보낼 수 있어 높은 처리량을 얻을 수 있다.

ü Acks=1 : 리더는 데이터를 기록하지만 모든 팔로워는 확인하지 않는다. 이 경우 일부 데이터의 손실이 발생할 수 있다.

ü Acks=all 또는 -1 : 만약 all 또는 -1로 설정하는 경우 리더는 ISR 팔로워로부터 데이터에 대한 복제가 완료될 때까지 ack를 기다린다. 하나 이상의 팔로워가 있는 한 데이터는 손실되지 않으며 데이터 무손실에 대해 가장 강력하게 보장한다.

[3개의 브로커 노드 구성에서 메시지 손실을 방지하기 위한 프로듀서의 acks 설정과 브로커의 min.insync.replicas 설정]

l acks=all과 브로커의 min.insync.replicas=1 : 메시지 손실을 허용하지 않도록 프로듀서의 acks 설정은 all로 지정한다. 이때 브로커의 min.insync.replicas 팩터 값을 1로 설정할 경우 리더에 메시지가 저장되면 ack 값을 보내기 때문에 acks=all로 설정했지만 acks=1과 동일하게 작동한다. 카프카에서는 프로듀서만 acks=all로 메시지를 보낸다고 해서 손실 없는 메시지를 보장해주지 않는다.

l acks=all과 브로커의 min.insync.replicas=2 : 메시지 손실을 허용하지 않도록 프로듀서의 acks 설정은 all로 지정한다. 이때 브로커의 min.insync.replicas 팩터 값을 2로 설정한다. 팔로워는 리더로부터 변경사항이 있는지 주기적으로 확인하며 데이터를 복제한다. 그리고 리더는 min.insync.replicas=2로 설정되어 있기 때문에 acks를 보내기전 최소 2개의 리플리케이션을 유지하는지 확인한다. 만약 리더가 acks를 보내자마자 리더 선출작업이 발생해도 그 메시지를 가지고 있는 팔로워가 있기 때문에 메시지 손실은 발생하지 않는다. 아파치 카프카 문서에서는 손실 없는 메시지 전송을 위한 조건으로 프로듀서는 acks=all, 브로커의 min.insync.replicas=2, 토픽의 리플리케이션 팩터는 3으로 권장하고 있다.

l acks=all과 브로커의 min.insync.replicas=3 : 리플리케이션 팩터3에서, min.insync.replicas=3으로 설정된 경우, 리더, 팔로워 합쳐 3개의 복제본이 유지되어야만 acks를 응답한다. 따라서 하나의 노드라도 장애가 발생하면 옵션값을 만족하지 못하기 때문에 오류가 발생한다.

[참고자료]

https://www.linkedin.com/pulse/kafka-producer-overview-sylvester-daniel/

2024-01-22 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, 카프카 토픽, 카프카 파티션, Kafka Topic, Kafka Partition, 카프카 복제, Kafka Replication, 프로듀서, Producer, Kafka Producer, 카프카 프로듀서

[Kafka] Kafka 리더, 팔로워, 복제 및 복구 이해하기

SungWookKang — Fri, 19 Jan 2024 17:46:13 +0900

[Kafka] Kafka 리더, 팔로워, 복제 및 복구 이해하기

l Kafka

Kafka (이하”카프카”)는 분산 처리 시스템으로 서버에 물리적인 장애가 발생하여도 높은 가용성을 보장하도록 구성할 수 있다. 그리고 가용성을 보장하기 위해 데이터를 여러 노드로 분산해서 운영한다. 메시지를 여러 개로 복사해서 카프카 클러스터의 여러 브로커들에게 분산시키는데 이러한 작업을 “리플리케이션”이라 한다. 이때 실제로 리플리케이션되는 정보는 토픽이 아닌 토픽의 파티션이다. 토픽에 대한 자세한 내용은 아래 글을 참고한다.

l Kafka 데이터 모델인 Topic과 Partition 이해하기 : https://sungwookkang.com/entry/Kafka-Kafka-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EC%9D%B8-Topic%EA%B3%BC-Partition-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

카프카는 내부적으로 클러스터내에서 동일한 리플리케이션들에 대해서 리더와 팔로워로 구분하여 역할을 분담하고 있다. 그리고 리더는 리플리케이션중에 하나가 선정되며, 모든 읽기와 쓰기는 리더를 통해서만 수행된다. 프로듀서는 모든 브로커들에게 메시지를 보내는 것이 아닌 리더에게만 메시지를 전송한다. 또한 컨슈머도 리더에게만 메시지를 가져온다. 그리고 팔로워들은 리더에서 토픽 파티션을 복제한다. 즉, 팔로워는 리더가 새로운 메시지를 받았는지 확인하고 새로운 메시지가 있으면 해당 메시지를 리더 파티션으로부터 복제한다. 이러한 과정을 통해 리더를 담당하는 브로커에 장애가 발생하더라도 복제되고 있는 팔로워들이 언제든 리더로 대체될 수 있다.

그림을 보면 프로듀서가 broker1의 topic1로 메시지를 보내는 것을 확인할 수 있는데, 이 상태는 topic1에 대한 리더는 broker1이 담당하고 있다는 뜻이다. 그리고 팔로워인 broker2, broker3에서 데이터를 복제한다. 그리고 한 가지 주의해야 할 사항이 모든 토픽에 대한 리더가 broker1이 아니라는 것이다. 그림에서 각 리더가 토픽별로 각 브로커에 분산된 것을 볼 수 있는데, 토픽 생성시 여러 브로커에 토픽을 생성하며 이때 리더를 선출하기 때문에 모두 같은 브로커에서 리더가 되는 것은 아니다. 이러한 구조 때문에 프로듀서와 컨슈머에 대한 부분도 부하 분산이 가능한 구조로 되어 있다.

아래 명령어를 사용하면 토픽별로 어느 브로커에서 리더로 선출되어 있는지 확인할 수 있다.

kafka-topics.sh --bootstrap-server=XXX.XXX.XXX.XXX:9092 --describe topic1

l Topic : 토픽의 이름을 나타낸다.

l ReplicationFactor : 원본을 포함한 리플리케이션 개수를 나타낸다.

l Leader : 해당 토픽의 리더 브로커를 나타낸다.

l Replicas : 해당 토픽이 복제되어 있는 브로커를 나타낸다.

l Isr : in sync replica로 파티션 리더 브로커와 함께 현재 동기화되고 있는 최신 상태의 복제본을 나타낸다.

[복제 유지와 커밋, 복구 과정]

카프카에서 복제와, 커밋, 그리고 브로커가 다운된 후 리더와 팔로우의 역할 변경 이후 데이터가 복구되는 과정을 살펴본다.

1. 프로듀서가 리더를 통해 Message1을 입력한다. 그리고 팔로워는 Message1에 대해서 복제를 완료한 상태이다.

2. 프로듀서가 리더로 Message2를 입력한다. 그리고 아직 팔로워로는 Message2가 복제되지 않은 상태이다.

3. Message2가 팔로워로 복제되기 전에 현재 리더 역할을 하는 Broker1이 다운되었다.

4. 기존에 팔로워 역할을 하던 Broker2가 리더로 역할이 변경되고, 프로듀서는 리더로 Message3을 입력한다.

5. 다운되었던 Broker1이 복구되고, 팔로워 역할로 수행된다. 그런데 이때, 새로운 리더(Broker2)와 팔로워(Broker1)의 데이터가 불일치하는 부분이 있음이 확인된다.

6. 팔로워는 리더에 포크 요청을 하고, 불일치하는 과거 데이터 Message2는 삭제하고, 최신의 데이터 Message3를 복제하고 최신의 데이터가 유지된다.

카프카는 분산처리 시스템이기 때문에 높은 가용성을 제공하지만, 예상하지 못한 시스템 장애가 발생하였을 경우에 시점에 따라 데이터 불일치가 발생하는 부분이 발생할 수 있으며 이때 복구 과정에서의 데이터 유실 또는 불일치 부분이 발생할 수 있다. 이와 같은 카프카의 특징을 알고 있으면, 장애상황에 대한 대처 및 장애조치 후 사이드 이펙트에 대해서도 예상할 수 있게 된다.

[참고자료]

https://www.confluent.io/blog/hands-free-kafka-replication-a-lesson-in-operational-simplicity/

https://www.conduktor.io/kafka/kafka-topic-replication/

2024-01-19 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, 카프카 토픽, 카프카 파티션, Kafka Topic, Kafka Partition, 카프카 복제, Kafka Replication

[Kafka] Kafka 데이터 모델인 Topic과 Partition 이해하기

SungWookKang — Thu, 18 Jan 2024 16:12:45 +0900

[Kafka] Kafka 데이터 모델인 Topic과 Partition 이해하기

l Kafka

Kafka(이하 “카프카”)에는 토픽(Topic)과 파티션(Partition)이라는 데이터 모델이 있다. 간단히 정리하면 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이고, 파티션은 토픽을 구성하는 물리적 데이터 저장소이며 수평 확장이 가능한 단위이다.

카프카 클러스터는 토픽에 데이터를 저장한다. 토픽의 이름은 249자 미만으로 영문, 숫자, ‘.’, ‘_’, ‘-‘를 조합하여 만들 수 있다.

토픽은 1개 이상의 파티션으로 구성되어 있다. 파티션은 append-only로 동작하며 새 메시지는 파티션 맨 뒤에 추가된다. 그리고 각 메시지의 저장 위치를 offset이라고 한다. 오프셋은 파티션 내에서 메시지를 식별하는 유니크한 값이며 순차적으로 증가하는 64비트 정수 형태로 되어 있으며, 0부터 시작한다.

아래 그림을 보면 토픽에 대한 파티션이 3개가 있고, 메시지는 각 파티션별로 분산되어 저장된다. (그림에서 숫자는 오프셋 위치이다.)

토픽 기준으로 보면, 각 파티션마다 오프셋이 동일하게 존재하지만, 파티션별로 보면 오프셋은 유일하다. 카프카에서는 이 오프셋을 이용하여 메시지의 순서를 보장한다. 그렇기 때문에 파티션 내에서는 순서를 보장하지만 파티션 간에는 데이터 순서를 보장하지 않는다. 그렇기 때문에 순서를 보장해야 하는 메시지의 경우 파티션 설정에 주의해야 한다.

브로커는 하나 이상의 노드들로 이루어지는데, 여러 브로커에 파티션을 수평확장 하였을 경우 아래와 같은 이점이 있다.

l 카프카의 성능은 브로커의 I/O 처리량에 영향을 받는데, 토픽의 모든 파티션을 하나의 브로커에 넣는 것 보다, 분산하였을 경우 I/O 오버헤드도 분산할 수 있다.

l 모든 파티션을 단일 브로커에서 제공하면 지원할 수 있는 Consumer 수가 제한되는데, 여러 브로커에서 파티션을 나누어 제공함으로써 더 많은 Consumer 들이 동시에 토픽의 메시지를 처리할 수 있다.

l 동일한 Consumer의 여러 인스턴스가 서로 다른 브로커에 있는 파티션에 접속함으로써 매우 높은 메시지 처리가 가능하다.

기본적으로 파티션 키는 해시함수를 사용하기 때문에, 동일한 키를 갖는 모든 레코드들이 동일한 파티션에 도착하는 것을 보장한다. 파티션 키를 지정할 경우에는, 관련된 이벤트를 동일한 파티션에 유지함으로써 전달된 순서가 그대로 유지되는 것을 보장할 수 있다. 파티션 키를 사용한 방법이 이벤트의 순서를 보장할 수 있다는 장점을 가진 반면, 키가 제대로 분산되지 않는 경우 특정 브로커만 메시지를 받는 단점도 존재한다.

Producer 가 레코드를 생성할 때 파티션 키를 명시하지 않으면, 카프카는 Round-Robin 방식을 사용해 파티션을 분산한다. 이 경우, 레코드들은 해당 토픽의 파티션들에 균등하게 분배된다. 그러나 파티션 키를 사용하지 않았기 때문에 레코드들의 순서는 보장되지 않는다.

아래 스크립트는 토픽을 생성한다. 이때 복제 수와 파티션 수를 설정할 수 있다.

bin/kafka-topics.sh --bootstrap-server <host:port> --create --topic <topic-name> \
--partitions 20 --replication-factor 3 --config <configName>=<configValue>

l Replication-factor : 메시지가 기록될 서버 수를 지정한다. 데이터 컨슘을 중단하지 않고 시스템을 투명하게 서비스할 수 있도록 복제 인수를 2 또는 3으로 사용해야 한다. 예를 들어, 복제 인수를 3으로 지정하면 최대 2개의 서버에 오류가 발생하면 데이터에 대한 액세스가 손실될 수 있다.

l Partitions : 파티션은 토픽을 샤딩의 수를 제어한다. 파티션 수는 여러 가지 영향을 미친다. 각 파티션은 단일 서버에 완전히 맞아야 한다. 따라서 20개의 파티션이 있는 경우 전체 데이터 세트와 읽기 및 쓰기 로드는 20개 이하의 서버 (복제본 제외)에서 처리된다. 마지막으로 파티션 수는 소비자의 최대 병렬 처리에 영향을 미친다.

[참고자료]

https://www.cloudkarafka.com/blog/part1-kafka-for-beginners-what-is-apache-kafka.html

https://docs.confluent.io/kafka/operations-tools/topic-operations.html#topic-operations

2024-01-18 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, 카프카 토픽, 카프카 파티션, Kafka Topic, Kafka Partition

[Kafka] Kafka 클러스터 4노드 구성 - Controller, Broker 혼합해서 구성하기

SungWookKang — Wed, 17 Jan 2024 11:49:48 +0900

[Kafka] Kafka 클러스터 4노드 구성 - Controller, Broker 혼합해서 구성하기

l Kafka 3.6.1 with KRaft

지난 포스트에서는 카프카를 단일 노드에 구성한 뒤 간단히 PUB/SUB를 테스트하는 방법에 대해서 알아보았다.

l Kafka 설치 (with KRaft) 및 PUB/SUB 테스트 코드 (with Python) 실습 :

https://sungwookkang.com/entry/Kafka-Kafka-%EC%84%A4%EC%B9%98-with-KRaft-%EB%B0%8F-PUBSUB-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-with-Python-%EC%8B%A4%EC%8A%B5

이번 포스트는 4 node의 카프카 서버를 클러스터로 구성하는 방법에 대해서 알아본다. 그리고 이번 구성에서는 각 노드마다 Controller와 Broker를 함께 배치하였다. 전체적인 구성은 아래와 같다.

실습을 위해 아래와 같이 4개의 VM 서버를 준비했다.

	Kafka-1	Kafka-2	Kafka-3	Kafka-4
IP	XXX.XXX.XXX.4	XXX.XXX.XXX.5	XXX.XXX.XXX.6	XXX.XXX.XXX.7

기존에 IP로 설정했다가 쿼럼을 찾지 못하여 호스트 파일을 설정하여 호스트 파일에 IP를 등록하여 사용하였다. (추후 IP로 다시 설정해 볼 예정이다.)

vi /etc/hosts

XXX.XXX.XXX.4 kafka-1
XXX.XXX.XXX.5 kafka-2
XXX.XXX.XXX.6 kafka-3
XXX.XXX.XXX.7 kafka-4

카프카를 설치하기 위해서는 JDK 11 버전 이상 필요하다. 이번 실습에서는 JDK 17 버전을 설치 및 아파치 카프카 3.6.1을 설치하였다.

	Kafka-1	Kafka-2	Kafka-3	Kafka-4
Install Open Jdk 17	apt-get install openjdk-17-jdk
Download Kafka	wget https://downloads.apache.org/kafka/3.6.1/kafka_2.13-3.6.1.tgz
Unpack Kafka	tar xvf kafka_2.13-3.6.1.tgz -C /usr/local
Create symbol link	cd /usr/local ln -s kafka_2.13-3.6.1/ kafka
Create log directory	mkdir -p /usr/local/kafka/kraft-combined-logs

카프카 디렉토리를 포맷한다. 이때, Kafka-1에서 생성한 UUID를 사용하여 모든 노드의 디렉터리를 포맷한다.

	Kafka-1	Kafka-2	Kafka-3	Kafka-4
Create UUID	cd /usr/local/kafka ./bin/kafka-storage.sh random-uuid
Format Directory	cd /usr/local/kafka ./bin/kafka-storage.sh format -t J9wwo7p2RHe9-4PiP4KbBw -c ./config/kraft/server.properties

Kafka-1에서 UUID를 생성한다. 이때 출력되는 결과를 복사해 놓는다.

복사해 놓은 UUID를 사용하여 Kafka-1 ~ Kafka-4 노드의 디렉토리를 포맷한다.

카프카 서버를 시작하기 전 설정 파일을 수정한다. 설정 파일은 아래 경로에 있다.

cd /usr/local/kafka
vi ./config/kraft/server.properties

	Kfaka-1	Kfaka-2	Kfaka-3	Kfaka-4
process.roles	broker,controller
node.id	1	2	3	4
controller.quorum.voters	1@kafka-1:9093,2@kafka-2:9093,3@kafka-3:9093,4@kafka-4:9093
listeners	PLAINTEXT://kafka-1:9092,CONTROLLER://kafka-1:9093	PLAINTEXT://kafka-2:9092,CONTROLLER://kafka-2:9093	PLAINTEXT://kafka-3:9092,CONTROLLER://kafka-3:9093	PLAINTEXT://kafka-4:9092,CONTROLLER://kafka-4:9093
inter.broker.listener.name	PLAINTEXT
advertised.listeners	PLAINTEXT://XXX.XXX.XXX.4:9092	PLAINTEXT://XXX.XXX.XXX.5:9092	PLAINTEXT://XXX.XXX.XXX.6:9092	PLAINTEXT://XXX.XXX.XXX.7:9092
controller.listener.names	CONTROLLER
listener.security.protocol.map	CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
log.dirs	/usr/local/kafka/kraft-combined-logs
num.partitions	1	1	1	1
transaction.state.log.replication.factor	4	4	4	4
transaction.state.log.min.isr	4	4	4	4

각 노드의 카프카 서버를 시작한다.

	Kfaka-1	Kfaka-2	Kfaka-3	Kfaka-4
Start Kafka	cd /usr/local/kafka ./bin/kafka-server-start.sh -daemon ./config/kraft/server.properties
Check Service	netstat -antp \| grep 9092 netstat -antp \| grep 9093

Kafka-1 노드에서 토픽을 생성한다. 실습에서는 topic1 이라는 이름으로 생성했다.

cd /usr/local/kafka
./bin/kafka-topics.sh --create --topic topic1 --bootstrap-server XXX.XXX.XXX.4:9092 --replication-factor 4 --partitions 1

Kafka-1에서 토픽을 생성했지만, Kafka-1 ~ Kafka-4 노드까지 토픽이 복제된 것을 확인할 수 있다.

	Kfaka-1	Kfaka-2	Kfaka-3	Kfaka-4
Topic List	./bin/kafka-topics.sh --bootstrap-server=10.211.55.4:9092 --list ./bin/kafka-topics.sh --bootstrap-server=10.211.55.5:9092 --list ./bin/kafka-topics.sh --bootstrap-server=10.211.55.6:9092 --list ./bin/kafka-topics.sh --bootstrap-server=10.211.55.7:9092 --list

프로듀서에서 Kafka-1노드에 메시지를 입력한다. 그리고 각 노드에서 데이터를 확인해 보면 복제된 데이터를 확인할 수 있다. 이때, 데이터가 전체 노드로 복제되기 까지의 시간이 필요하므로 입력 즉시 컨슈머로 확인해보면, 일부 노드에서는 데이터가 보이지 않을 수도 있다. 하지만 시간이 지나면 전체 노드에서 데이터를 확인할 수 있다.

	Kfaka-1	Kfaka-2	Kfaka-3	Kfaka-4
Consumer check	./bin/kafka-console-consumer.sh --bootstrap-server XXX.XXX.XXX.4:9092 --topic topic1 --from-beginning ./bin/kafka-console-consumer.sh --bootstrap-server XXX.XXX.XXX.5:9092 --topic topic1 --from-beginning ./bin/kafka-console-consumer.sh --bootstrap-server XXX.XXX.XXX.6:9092 --topic topic1 --from-beginning ./bin/kafka-console-consumer.sh --bootstrap-server XXX.XXX.XXX.7:9092 --topic topic1 --from-beginning

이번 포스트에서는 Controller와 Broker를 각 노드에 함께 실행하였지만, 트래픽이 헤비한 서버에서는 Controller와 Broker를 분리해서 사용할 것을 권장한다. 그래서 다음 포스트에서는 분리하여 클러스터를 구성하는 방법에 대해서 알아볼 예정이다.

2024-01-17 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, KRaft, 크래프트

[Kafka] KRaft 설정 파일 및 기본 속성 정의 알아보기

SungWookKang — Thu, 11 Jan 2024 16:43:19 +0900

[Kafka] KRaft 설정 파일 및 기본 속성 정의 알아보기

l Kafka 3.6.1 with KRaft

Apache Kafka Raft(KRaft)는 메타데이터 관리를 위해 ZooKeeper에 대한 Apache Kafka의 종속성을 제거하기 위해 KIP-500에 도입된 합의 프로토콜이다. 이는 메타데이터에 대한 책임을 ZooKeeper와 Kafka라는 두 개의 다른 시스템으로 분할하는 대신 Kafka 자체에 통합함으로써 Kafka의 아키텍처를 크게 단순화한다. KRaft 모드는 이전 컨트롤러를 대체하고 Raft 합의 프로토콜의 이벤트 기반 변형을 사용하는 Kafka의 새로운 쿼럼 컨트롤러 서비스를 사용한다.

Kafka의 새로운 쿼럼 컨트롤러의 이점은 아래와 같다.

1. KRaft는 적절한 크기의 클러스터를 지원한다. 즉, 적절한 수의 브로커로 크기가 조정되고 사용 사례의 처리량 및 대기 시간 요구 사항을 충족하도록 컴퓨팅되는 클러스터를 의미하며 수백만 개의 파티션까지 확장할 수 있는 가능성이 있다.

2. 안정성을 향상시키고 소프트웨어를 단순화하며 Kafka를 보다 쉽게 모니터링, 관리 및 지원할 수 있다.

3. Kafka가 전체 시스템에 대해 단일 보안 모델을 가질 수 있도록 한다.

4. 구성, 네트워킹 설정, 통신 프로토콜에 대한 통합 관리 모델을 제공한다.

5. Kafka를 시작하기 위한 경량의 단일 프로세스 방법을 제공한다.

6. 컨트롤러 장애 조치를 거의 즉각적으로 수행한다.

쿼럼 컨트롤러는 새로운 KRaft 프로토콜을 사용하여 메타데이터가 쿼럼 전체에 정확하게 복제되도록 한다. 쿼럼 컨트롤러는 이벤트 소스 저장소 모델을 사용하여 상태를 저장하므로 내부 상태 머신이 항상 정확하게 다시 생성될 수 있다. 이 상태를 저장하는 데 사용되는 이벤트 로그(메타데이터 주제라고도 함)는 로그가 무한정 커지지 않도록 정기적으로 스냅샷으로 요약된다. 쿼럼 내의 다른 컨트롤러는 활성 컨트롤러가 생성하고 해당 로그에 저장하는 이벤트에 응답하여 활성 컨트롤러를 따른다. 따라서 분할 이벤트로 인해 한 노드가 일시 중지되면 다시 참여할 때 로그에 액세스하여 놓친 이벤트를 빠르게 따라잡을 수 있다.

KRaft 프로토콜의 이벤트 중심 특성은 ZooKeeper 기반 컨트롤러와 달리 쿼럼 컨트롤러가 활성화되기 전에 ZooKeeper에서 상태를 로드할 필요가 없음을 의미한다. 리더십이 변경되면 새 활성 컨트롤러에는 이미 커밋된 모든 메타데이터 레코드가 메모리에 있다. 게다가 KRaft 프로토콜에 사용되는 것과 동일한 이벤트 중심 메커니즘이 클러스터 전체의 메타데이터를 추적하는 데 사용된다. 이전에 RPC로 처리되었던 작업은 이제 통신을 위해 실제 로그를 사용하는 것뿐만 아니라 이벤트 중심으로 처리되는 이점도 있다.

	WITH ZOOKEEPER	WITH KRAFT (NO ZOOKEEPER)
Configuring Clients and Services	zookeeper.connect=zookeeper:2181	bootstrap.servers=broker:9092
Configuring Schema Registry	kafkastore.connection.url=zookeeper:2181	kafkastore.bootstrap.servers=broker:9092
Kafka administrative tools	kafka-topics --zookeeper zookeeper:2181	kafka-topics --bootstrap-server broker:9092 ... --command-config properties to connect to brokers
REST Proxy API	v1	v2 or v3
Getting the Kafka Cluster ID	zookeeper-shell zookeeper:2181 get/cluster/id	kafka-metadata-quorum or view metadata.properties or confluent cluster describe --url http://broker:8090 --output json

KRaft의 구성 파일 내용은 서버가 브로커인지 컨트롤러인지 또는 둘 다인지에 따라 다르다. 서버를 실행할 때, 어떤 구성 파일을 로드하여 사용하느냐에 따라 서버의 역할을 정의할 수 있다. 일반적으로 구성 파일은 아래 경로에 있다.

/kafka/config/kraft/

모든 파일에 대해 서버 기본 섹션의 설정이 포함되어야 한다. 추가 설정은 서버가 브로커인지, 컨트롤러인지, 아니면 둘 다인지에 따라 달라진다.

l broker.properties- 서버가 브로커 전용일 때 사용하는 설정파일

l controller.properties- 서버가 컨트롤러일 때 사용하는 설정파일

l server.properties- 서버가 브로커이자 컨트롤러인 경우에 사용하는 설정 파일이며, 프로덕션에서는 가급적 용도를 분리하여 사용하는 것을 권장

각 파일에서 사용되는 기본 속성과 정의에 대해서 알아보자.

[#####Server basics#####]

[process.roles = {broker | controller | broker, controller}]

이 속성은 서버가 컨트롤러, 브로커 또는 둘 다의 역할을 하는지 여부를 지정한다. KRaft 모드에서는 특정 Kafka 서버가 컨트롤러로 선택되어 클러스터에 대한 메타데이터를 메타데이터 로그에 저장하고 다른 서버는 브로커로 선택된다. 컨트롤러로 선택된 서버는 메타데이터 쿼럼에 참여하게 된다. 각 컨트롤러는 현재 활성 컨트롤러에 대한 활성 또는 상시 대기 상태이다.

프로덕션 환경에서는 컨트롤러 쿼럼이 여러 노드에 배포된다. 이것을 앙상블이라고한다. 앙상블은 2n + 1 컨트롤러 세트이다. 여기서 n은 0보다 큰 임의의 숫자이며, 홀수 개의 컨트롤러를 사용하면 컨트롤러 쿼럼이 리더십에 대한 다수 선거를 수행할 수 있다. 언제든지 앙상블에는 최대 n개의 실패한 서버가 있을 수 있으며 클러스터는 쿼럼을 유지한다. 예를 들어 컨트롤러가 3개인 경우 클러스터는 하나의 컨트롤러 오류를 허용할 수 있다. 5개의 컨트롤러를 사용하면 클러스터는 2개의 컨트롤러 오류를 허용할 수 있다. 전체 쿼럼이 손실되면 클러스터가 다운된다.

[node.id ]

서버의 고유 식별자로, 각 노드 ID는 특정 클러스터의 모든 서버에서 고유해야 한다.

[controller.quorum.voters=1@localhost:9093]

쿼럼 투표자 목록으로, 다수의 서버일 경우 쉼표로 구분한다. Kafka 클러스터의 모든 서버(컨트롤러 및 브로커)는 이 속성을 사용하여 쿼럼 투표자를 검색하며 속성에 제공하는 목록에 컨트롤러를 포함하여 모든 컨트롤러를 식별해야 한다.

각 컨트롤러는 {id}@{host}:{port} 형식을 사용하며, 여러 항목을 사용할 경우 쉼표로 구분한다.

controller.quorum.voters=1@host1:port1,2@host2:port2,3@host3:port3

속성에 제공된 노드 ID는 controller.quorum.voters컨트롤러 서버의 해당 ID와 일치해야 한다. 예를 들어, 컨트롤러1에서는 node.id를 반드시 1 로 설정해야 한다. 서버가 브로커 전용인 경우 해당 노드 ID가 목록에 표시되어서는 안 된다.

[#####Socket server settings#####]

[listeners]

소켓 서버가 수신하는 주소 목록으로 쉼표로 구분한다. 서버가 격리 모드의 컨트롤러 역할(process.roles=controller)인 경우, 이 목록에는 컨트롤러 리스너만 허용되며 이 리스너는 controller.quorum.voters 값과 일치해야 한다.

호스트 이름이 java.net.InetAddress.getCanonicalHostName()구성파일과 같을 경우 호스트 이름은 리스너 이름 및 포트 값과 동일하다.

listeners=PLAINTEXT://your.host.name:9092

결합 모드의 컨트롤러의 경우 컨트롤러 수신기와 브로커 수신기를 나열해야 합니다.

[controller.listener.names]

컨트롤러에서 listener_name에 사용하는 목록은 쉼표로 구분한다. process.roles=broker목록의 첫 번째 리스너만 브로커에서 사용된다. ZooKeeper 기반 브로커는 이 값을 설정하면 안 된다. 격리 모드 또는 결합 모드의 KRaft 컨트롤러의 경우 노드는 이 속성에 대해 나열된 모든 리스너에서 KRaft 컨트롤러로 수신하며 각각은 listeners 속성에 나타나야 한다. ZooKeeper 모드에서는 advertised.listeners 속성이 사용되지 않는다.

[#####Log settings#####]

[log.dirs]

로그 파일을 저장할 디렉터리의 이며, 여러 디렉터리를 사용할 경우 쉼표로 구분한다. KRaft 컨트롤러를 사용할 때 메타데이터 로그에 대해 이 속성을 재정의하려면 메타데이터 보존 설정을 참조한다. KRaft 모드의 경우 JBOD가 지원되지 않으므로 현재 하나의 로그 디렉터리만 나열해야 한다.

[num.partitions]

주제당 기본 로그 파티션 개수이다. 파티션이 많을수록 더 많은 병렬 처리가 가능하지만 이로 인해 브로커 전체에 더 많은 파일이 생성된다. 브로커에 대해서만 이 구성을 설정이 적용되며, KRaft 컨트롤러에서 무시된다.

[참고자료]

l https://developer.confluent.io/learn/kraft/

l Configure KRaft in Production : https://docs.confluent.io/platform/current/kafka-metadata/config-kraft.html

2024-01-11 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, Apache Kafka, KRaft, 크래프트

[Kafka] Kafka 설치 (with KRaft) 및 PUB/SUB 테스트 코드 (with Python) 실습

SungWookKang — Tue, 9 Jan 2024 11:19:26 +0900

[Kafka] Kafka 설치 (with KRaft) 및 PUB/SUB 테스트 코드 (with Python) 실습

l Kafka 3.6.1 with KRaft

Apache Kafka(이하 “카프카”)는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산형 데이터 스트리밍 플랫폼이다. 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었다. 간단히 말해 A지점에서 B지점까지 이동하는 것뿐만 아니라 A지점에서 Z지점을 비롯해 필요한 모든 곳에서 대규모 데이터를 동시에 이동할 수 있다. 카프카는 현재 여러 마이크로서비스 개발 환경에서 많이 사용되고 있다.

카프카는 3.5.2 버전까지는 분산 코디네이션으로 주키퍼(Zookeeper)를 사용하였지만, 3.6.0 버전 부터는 분산 코디네이션에 KRaft를 도입하였다. 현재 이 글을 쓰는 시점의 최신 버전인 3.6.1 버전에도 주키퍼와 KRaft를 모두 지원하고 있어 사용자가 선택하여 사용할 수 있다. 하지만 4.0 버전부터는 주키퍼는 지원하지 않는다고 이후에는 KRaft만 사용될 예정이라고 한다.

Kraft의 장점 및 자세한 설명은 아래 링크를 참고한다.

l KRaft: Apache Kafka Without ZooKeeper : https://developer.confluent.io/learn/kraft/

이번 포스트는 카프카 3.6.1 버전을 설치하고, 주키퍼가 아닌 KRaft를 사용하며, 간단히 파이썬 코드로 데이터를 게시(Producer)하고, 구독(Consumer)하는 프로그램을 만들어 본다.

[테스트 환경]

OS	Ubuntu 22.04.3 LTS
CPU	2 Core
Memory	2 GB
Kafka	Kafka 3.6.1

카프카를 설치 및 운영하기 위해서는 JDK가 설치되어 있어야 한다. JDK는 11버전이상 사용해야 하며, 이번 실습에서는 17버전을 설치하였다.

apt-get install openjdk-17-jdk

카프카 다운로드 페이지에서 원하는 버전을 다운로드 한 후 압축을 해제한다.

l Kafka Download : https://kafka.apache.org/downloads

카프카의 경우 설치형이 아닌 압축을 해제 후 서비스를 실행하여 바로 사용할 수 있다. 실습에서는 3.6.1 버전을 설치한다. 파일을 다운로드 하고, /usr/local 경로에 압축을 해제한다.

wget https://downloads.apache.org/kafka/3.6.1/kafka_2.13-3.6.1.tgz

tar xvf kafka_2.13-3.6.1.tgz -C /usr/local

관리 및 사용자 편의성을 위해 심볼링크를 생성한다.

cd /usr/local

ln -s kafka_2.13-3.6.1/ kafka

[server.properties 세팅]

카프카를 실행하기 전에 server.properties를 설정해야 한다. 아래 단계를 따라 설정한다. Properties 파일의 경로는 아래와 같다.

cd /usr/local/kafka/config/kraft/

vi 또는 편집기를 실행하여 server.properties 파일의 내용을 수정한다.

vi server.properties

외부 통신을 위해서는 advertised.listeners의 localhost 주소를 카프카 서버 IP로 반드시 변경해야 한다. (필자도 이 부분을 놓쳐서 거의 이틀동안 삽질했다.)

############################# Socket Server Settings #############################
#advertised.listeners=PLAINTEXT://localhost:9092 <-주석처리
advertised.listeners=PLAINTEXT://XXX.XXXX.XXXX:9092 <- localhost 대신 카프카 서버의 IP 입력

log.dirs은 로그 파일의 경로이다 . 기본값은 /tmp/kraft-combined-logs로 되어 있지만 사용자 편의에 따라 경로를 변경할 수 있다. 필자는 /usr/local/kafka/kraft-combined-logs 경로에 디렉터리를 생성하고, 변경하였다.

############################# Log Basics #############################
log.dirs=/usr/local/kafka/kraft-combined-logs

여기까지 server.properties 수정이 완료 되었으면, 저장하고 편집기를 빠져나온다.

[Kafka 클러스터 ID 생성 및 포맷]

카프카 서버를 시작하기전 클러스터 ID를 생성하고, 스토리지(위에서 지정한 로그 경로의 디렉터리)를 포맷해야 한다.

클러스터 ID는 아래 명령으로 생성할 수 있다.

cd /usr/local/kafka

./bin/kafka-storage.sh random-uuid

랜덤한 UUID로 클러스터 ID가 생성되면 해당 ID를 사용하여 스토리지 디렉터리를 포맷한다.

cd /usr/local/kafka

./bin/kafka-storage.sh format -t J9wwo7p2RHe9-4PiP4KbBw -c ./config/kraft/server.properties

[카프카 서버 시작 / 중지]

위 단계까지 완료되었으면 이제 카프카 서버를 시작한다. 카프카 서버의 시작 및 중지는 아래 명령을 사용할 수 있다.

#Start Service
cd /usr/local/kafka
./bin/kafka-server-start.sh -daemon ./config/kraft/server.properties

#Stop Service
cd cd /usr/local/kafka
./bin/kafka-server-stop.sh -daemon ./config/kraft/server.properties

서비스가 정상적으로 실행되었는지 확인하려면 아래 스크립트를 사용하여 데몬 활성화 상태 및 포트 오픈 여부를 확인할 수 있다.

ps -ef | grep java | grep kraft/server.properties

netstat -antp | grep 9092

netstat -antp | grep 9093

[Producer / Consumer Test]

카프카 서비스가 정상적으로 실행되었으면, 간단히 토픽을 하나 생성하고, 프로듀서, 컨슈머 테스트를 진행한다.

토픽 생성은 아래 스크립트를 사용한다. 실습에서는 토픽의 이름을 topic1 이라고 생성하였다.

#Create Topic
cd /usr/local/kafka
./bin/kafka-topics.sh --create --topic topic1 --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1

#Delete Topic
./bin/kafka-topics.sh --delete --topic topic1 --bootstrap-server localhost:9092

현재 생성되어 있는 토픽을 확인하는 명령은 아래와 같다.

cd /usr/local/kafka
./bin/kafka-topics.sh --bootstrap-server=localhost:9092 --list

카프카에 topic1 메시지를 게시한다.

cd /usr/local/kafka
./bin/kafka-console-producer.sh --broker-list localhost:9092 --topic topic1
> Input message
> Input another message

#End Input
Ctrl+C

카프카의 topic1의 메시지를 구독한다.

cd /usr/local/kafka
./bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topic1 --from-beginning

[파이썬으로 Producer, Consumer 테스트]

파이썬으로 간단한 Producer, Consumer 테스트 코드를 작성해 본다. 우선 카프카 커넥터를 설치해야 한다. 다양한 커넥터가 있지만 실습에서는 kafka-python 커넥터를 사용한다.

pip3 install kafka-python

아래 코드는 producer 코드로 1 ~ 10까지 반복하며 topic1에 메시지를 입력한다. (파이썬 코드에 관한 설명은 생략한다.)

from kafka import KafkaProducer
from json import dumps
import time
import traceback

producer = KafkaProducer(
    acks=0,
    compression_type='gzip',
    bootstrap_servers=['XXX.XXX.XXX.XXXX:9092'],
    value_serializer=lambda x:dumps(x).encode('utf-8')
    )

start = time.time()

try:
    for i in range(10):
        data = {'str' : 'result'+str(i)}
        producer.send('topic1', value=data)
        producer.flush()
    producer.close()
    print('[Done]', time.time() - start)
except:
    traceback.print_exc()

아래 코드는 Consumer 코드로 topic1에 있는 메시지를 처음부터 구독한다.

from kafka import KafkaConsumer
from json import loads

consumer = KafkaConsumer(
    'topic1',
    bootstrap_servers=['XXX.XXX.XXX.XXX:9092'],
    auto_offset_reset='earliest',
    enable_auto_commit=True,
    group_id='1',
    value_deserializer=lambda x: loads(x.decode('utf-8')),
    consumer_timeout_ms=1000
)

print('[Start] get consumer')

for message in consumer:
    print(f'Topic : {message.topic}, Partition : {message.partition}, Offset : {message.offset}, Key : {message.key}, value : {message.value}')

print('[End] get consumer')

지금까지 카프카 설치 및 간단하게 프로슈머, 컨슈머 사용법에 대해서 알아보았다. 카프카는 대규모 메시징 시스템에서 많이 사용된다. 그렇기 때문에 단독 서버가 아닌 클러스터로 구성하여 사용하는 경우가 많다. 카프카의 특성을 잘 이해하고, 토픽 및 파티션 최적화 설계로 안정적인 서비스 구성이 될 수 있도록 반드시 추가 학습을 진행할 것을 권장한다.

[참고자료]

KRaft: Apache Kafka Without ZooKeeper : https://developer.confluent.io/learn/kraft/

Mark KRaft as Production Ready : https://cwiki.apache.org/confluence/display/KAFKA/KIP-833%3A+Mark+KRaft+as+Production+Ready

2024-01-09 / Sungwook Kang / https://sungwookkang.com

KAFKA, 아파치 카프카, 카프카 설치, Install Kafka, Apache Kafka, Kraft, 카프카 스트림, producer, consumer

[Linux] 리눅스에서 TCP DUMP로 패킷헤더 출력하기

SungWookKang — Tue, 2 Jan 2024 11:53:06 +0900

[Linux] 리눅스에서 TCP DUMP로 패킷헤더 출력하기

l Linux

일반적으로 어플리케이션간 통신이 되지 않을 때 어플리케이션의 로그도 확인하겠지만, 가장 먼저 확인하는 부분이 OS 방화벽 > 시스템 방화벽(보안프로그램) > 네트워크 방화벽 순이지 않을까 한다. 이때 사용자가 모든 권한을 가지고 있으면 각 단계별로 방화벽 로그나 기타 로그를 보면서 통신이 되는지 (접근이 되는지)등의 문제를 확인할 수 있지만, 사실상 대부분의 업무는 역할이 정해져 있고, 역할마다 접근 권한이 다르기 때문에 빠르게 모든 구간을 확인할 수 없다. 가끔은 필요한 단계에서 각 방화벽의 포트가 오픈되어 있는데, 통신이 되지 않는 경우(대부분은 오해로 발생)도 있다.

이럴 때 쉽게 패킷이 호출되는지 통신 여부를 확인할 수 있는 명령이 TCP DUMP이다. TCP DUMP 명령은 주어진 조건식을 만족하는 네트워크 인터페이스를 거치는 모든 패킷을 캡처하여 헤더를 출력해준다.

우선 아래와 같은 명령으로 TCP DUMP를 실행해본다. 모든 내용을 출력하기 때문에 사실상 정보를 확인하기에는 많이 불편할 것이다.

tcpdump -i eth0

사용자가 필요한 패킷의 정보만 표시할 수 있도록 TCP DUMP 명령의 기본 옵션을 살펴보자.

l tcpdump -i eth0 : 인터페이스 eth0의 전체 패킷 출력

l tcpdump -i eth0 -c 10 : 10개의 내용만 출력

l tcpdump -i eth0 tcp : TCP 패킷만 출력

l tcpdump -i eth0 udp : UDP 패킷만 출력

l tcpdump -i eth0 tcp port 80 : TCP 80 포트로 통신하는 패킷 출력

l tcpdump -i eth0 udp port 80 : UDP 80 포트로 통신하는 패킷 출력

l tcpdump -i eth0 src X.X.X.X : source ip가 X.X.X.X인 패킷 출력

l tcpdump -i eth0 dst X.X.X.X : destination ip가 X.X.X.X인 패킷 출력

l tcpdump -i eth0 src port 3306 : source port가 3306인 패킷 출력

l tcpdump -i eth0 dst port 3306 : destination port가 3306인 패킷 출력

l tcpdump net 192.168.0.1/24 : CIDR 형식으로 캡처할 IP 범위 지정하여 패킷 출력

l tcpdump -w tcpdump.log : 캡처된 내용을 tcpdump.log라는 파일에 저장하며 txt 형식이 아닌, bin 형식으로 저장. 저장된 파일을 wireshark 등에서 분석 가능.

l tcpdump -r tcpdump.log : tcpdump.log 파일의 내용을 보여줌

다양한 연산자 &&(AND), ||(OR), !(NOT)을 사용하여 여러 조건을 조합해서도 사용할 수 있다.

l Source IP가 X.X.X.X이면서 TCP PORT가 80인것만 출력한다.

tcpdump -i eth0 src X.X.X.X and tcp and port 80

l Destination IP가 X.X.X.X 이면서 UDP 3306 포트의 패킷을 tcpdump.log라는 파일에 저장한다.

tcpdump -w tcpdump.log -i eth0 dst X.X.X.X and udp and port 3306

l Source IP가 X.X.X.X 이고 Destination PORT가 22가 아닌 것만 출력한다.

tcpdump src X.X.X.X and not dst port 22

l Source IP가 X.X.X.X 이고 Destination PORT가 22 또는 3389인것만 출력한다. 이때 조건에 연산자 우선순위를 사용할 수 있도록 싱글쿼테이션(‘)으로 구분한다.

tcpdump ‘src X.X.X.X and (dst port 3389 or 22)’

지금까지 TCPDUMP의 다양한 활용법에 대해서 알아보았다. 기본적인 명령어만 알고 있어도, 사용자가 관여하는 서버에서 패킷이 호출되는지 정도까지는 직접 확인할 수 있어, 유관부서에 협업을 요청하거나, 문제를 해결하기 위한 포인트를 좀 더 빠르게 접근할 수 있지 않을까 한다.

2024-01-02 / Sungwook Kang / https://sungwookkang.com

리눅스, TCPDUMP, 패킷덤프, 패킷출력, 통신확인

[ProxySQL] CONNECTING_CLIENT_STATE_SERVER_HANDSHAKE 오류

SungWookKang — Mon, 11 Dec 2023 09:47:55 +0900

[ProxySQL] CONNECTING_CLIENT_STATE_SERVER_HANDSHAKE 오류

l Version : ProxySQL 2.4.2

ProxySQL에서 백엔드 어플리케이션이 접속하는 포트로 로그인이 안되는 문제가 발생하였다. ProxySQL의 로그를 확인해 보니 아래와 같은 로그가 기록되어 있다.

MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)
MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)
MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)
MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)
MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)
MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)
MySQL_Session.cpp:5094:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE():[ERROR] ProxySQL Error: Access denied for user 'user'@'ip' (using password: YES)

현재 시스템 구성은 MySQL PXC 환경으로 3개의 노드(Primary 1, Secondary 2)와 클러스터 상단에 쿼리 종류에 따라 로드 밸런서 및 커넥션 매지니지먼트를 위한 ProxySQL이 구성되어 있다. 문제는 관리자 포트인 6032로 접속하면 정상적으로 접속이 되며, 백엔드 포트인 6033 포트로 접속하면 오류 로그와 함께 접속이 되지 않는 것이다. 사실상 위 오류 로그만으로는 문제의 원인을 찾기가 쉽지 않았다. 단순히 사용자 패스워드 오류 메시지로만 표시되기 때문이다. 하지만 해당 문제가 발생할 때 패턴을 살펴보면, 신규 사용자를 생성한 경우에 가끔 발생한다는 것이었다. 그리고 여러 검색을 해본결과, 해당 문제는 특정 버전이 아닌, 오래전부터 다양한 버전에서 발생하는 문제였다.

ProxySQL은 SQLite를 기본 데이터 저장소로 사용하며 디스크로 데이터를 저장하면 SQLite로 저장이 된다. 이때 간혹 데이터 불일치가 발생하여 이와 같은 문제가 발생할 수 있다.

l ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까? : https://sungwookkang.com/entry/ProxySQL-%EC%9D%80-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%97%90-%ED%95%84%EC%9A%94%ED%95%9C-%EC%84%A4%EC%A0%95%EA%B0%92%EC%9D%84-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B3%A0-%EC%9E%AC%EC%82%AC%EC%9A%A9%ED%95%A0%EA%B9%8C

이 문제는 아래 순서로 재현이 가능하다.

#ProxySQL 관리자 모드 접속
mysql -uadmin -padmin -P6032 -h127.0.0.1

#신규 사용자 추가
insert into mysql_users (username, password,default_hostgroup) values ('admin','admin',0);

#변경 사항 메모리 로드 및 디스크에 변경 사항 저장
load mysql users to runtime; save mysql users to disk;

#관리자 모드로 재접속
mysql -uadmin -padmin -P6032 -h127.0.0.1

#반환되는 오류 메시지
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): ProxySQL Error: Access denied for user 'admin'@'127.0.0.1' (using password: YES)

#ProxySQL 오류 로그 확인
tail -1 /var/lib/proxysql/proxysql.log

MySQL_Session.cpp:5439:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE(): [ERROR] ProxySQL Error: Access denied for user 'admin'@'127.0.0.1' (using password: YES)

이 문제를 해결하기 위서는 ProxySQL에서 사용하는 SQLite의 데이터를 직접 수정해서 해결할 수 있다.

# Stop ProxySQL
systemctl stop proxysql

# Backup the db file
cd /var/lib/proxysql/
cp proxysql.db proxysql.db.1

# Open db file with sqlite3
sqlite3 proxysql.db

sqlite> select * from mysql_users;
admin|*4ACFE3202A5FF5CF467898FC58AAB1D615029441|1|0|10|test|0|1|0|1|1|10000||

# Delete the user we created and verify it is gone
sqlite> delete from mysql_users where username='admin';

sqlite> .quit

# Start ProxySQL
systemctl start proxysql

위 방식은 직접 SQLite에 접속하여 문제의 계정을 삭제하고 서비스를 재시작 후 새롭게 계정을 또 다시 등록하고 해야한다. 하지만 SQLite를 직접 수정하는 것은 최대한 피하는 것이 좋다. 엉뚱한 데이터를 삭제하는 문제가 발생하면 더 큰 서비스 문제로 이어질 수 있기 때문이다. 또한, ProxySQL을 여러대 사용할 경우 매번 접속해서 계정을 삭제하고 만드는 일이 매우 불편할 수 있다.

다른 방법으로는 ProxySQL을 초기화 하고 미리 만들어둔 사용자 및 서버, 호스트 그룹등을 설정하는 스크립트를 재실행하여 새롭게 구성하거나 백업해둔 SQLite를 복원해서 사용하는 것이다.

#ProxySQL 초기화
proxysql –initial

하지만 이 방법 또한 재구성 후 이니셜 작업을 해주어야 하는 불편함이 있기 때문에 나의 경우에는 proxysql.cnf 파일에 사용자, 서버, 호스트그룹, 쿼리룰 등 모두 세팅하여 서비스가 시작될 때 proxysql.cnf 파일의 정보를 사용하도록 하였다.

지금까지 설명한 방법중 어떠한 것을 도입하더라도 서비스 다운타임은 피할 수 없다. 그래서 설정 파일로 모두 관리한 다음 문제가 생겼을 때 빠르게 서비스를 재시작하거나, ProxySQL 클러스터 그룹을 생성하여 문제가 되는 노드는 빠르게 제거하고 다시 세팅할 수 있는 환경을 만들어 서비스 다운타임을 최화 하는 것이 중요할 듯 하다.

[참고자료]

l https://kedar.nitty-witty.com/blog/can-not-connect-to-proxysql-reasons-and-fixtures

2023-12-11 / Sungwook Kang / http://sungwookkang.com

MySQL, ProxySQL, 프록시 SQL, 커넥션 오류, CONNECTING_CLIENT_STATE_SERVER_HANDSHAKE

[MySQL] Galera 클러스터 이름 길이 초과로 인한 클러스터 조인 오류

SungWookKang — Fri, 8 Dec 2023 13:33:44 +0900

[MySQL] Galera 클러스터 이름 길이 초과로 인한 클러스터 조인 오류

l Version : MySQL Percona Cluster, Galera Cluster

MySQL Percona 클러스터를 구성하고, Primary 서비스를 정상적으로 구동한 후 Secondary 서버를 클러스터에 조인하려고 할 때 아래와 같은 오류와 함께 클러스터 조인에 실패하였다. Secondary의 경우 서비스가 시작될 때 my.cnf에 정의되어 있는 정보에 따라 클러스터 조인을 자동으로 시도하고 클러스터 조인에 실패할 경우 MySQL이 정상적으로 실행되지 않는다.

2023-12-06T10:02:52.460279Z 0 [ERROR] [MY-000000] [Galera] failed to open gcomm backend connection: 110: failed to reach primary view (pc.wait_prim_timeout): 110 (Connection timed out)
at /mnt/jenkins/workspace/pxc80-autobuild-RELEASE/test/percona-xtradb-cluster-8.0.34-26/percona-xtradb-cluster-galera/gcomm/src/pc.cpp:connect():176
2023-12-06T10:02:52.460299Z 0 [ERROR] [MY-000000] [Galera] /mnt/jenkins/workspace/pxc80-autobuild-RELEASE/test/percona-xtradb-cluster-8.0.34-26/percona-xtradb-cluster-galera/gcs/src/gcs_core.cpp:gcs_core_open():219: Failed to open backend connection: -110 (Connection timed out)
2023-12-06T10:02:53.460513Z 0 [Note] [MY-000000] [Galera] gcomm: terminating thread
2023-12-06T10:02:53.460616Z 0 [Note] [MY-000000] [Galera] gcomm: joining thread
2023-12-06T10:02:53.460932Z 0 [ERROR] [MY-000000] [Galera] /mnt/jenkins/workspace/pxc80-autobuild-RELEASE/test/percona-xtradb-cluster-8.0.34-26/percona-xtradb-cluster-galera/gcs/src/gcs.cpp:gcs_open():1876: Failed to open channel 'XXXXXXXXXX-XXX-XX-XXXX-XXXXXXX-XXX' at 'gcomm://192.168.0.1,192.168.0.2': -110 (Connection timed out)
2023-12-06T10:02:53.460972Z 0 [ERROR] [MY-000000] [Galera] gcs connect failed: Connection timed out
2023-12-06T10:02:53.460988Z 0 [ERROR] [MY-000000] [WSREP] Provider/Node (gcomm://192.168.0.1,192.168.0.2) failed to establish connection with cluster (reason: 7)
2023-12-06T10:02:53.461001Z 0 [ERROR] [MY-010119] [Server] Aborting
2023-12-06T10:02:53.461456Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.34-26.1) Percona XtraDB Cluster (GPL), Release rel26, Revision 0988772, WSREP version 26.1.4.3.
2023-12-06T10:02:53.464279Z 0 [ERROR] [MY-010065] [Server] Failed to shutdown components infrastructure.

문제의 원인을 조사해보니, 클러스터 이름 길이 초과로 인해서, 클러스터 조인시 발생하는 오류였다. 해당 오류 사례가 이슈로 제기된 깃헙을 확인할 수 있었고 오래된 이슈였는데 아직 픽스 되지는 않은것 같다. (버그가 아니기에 픽스할 이유는 없을듯 하기도 하다.) 클러스터의 이름을 32자 이내로 설정해야 한다고 한다.

l https://github.com/bloomberg/chef-bcpc/issues/649

클러스터의 이름을 32자 이내로 수정하고 실행한 결과 정상적으로 클러스터에 조인하는 것을 확인할 수 있었다. 여기에서 한가지 의심(?)스러운 것은, Primary 노드를 시작할 때에는 클러스터 이름의 길이가 32자가 초과해도 문제없이 실행된다는 점이다. 만약에 처음 Primary 세팅 때부터 해당 문제로 서비스가 정상적으로 실행되지 않았으면 빠르게 알 수 있었을 텐데, Primary는 전혀 영향이 없고, Secondary 노드부터 조인을 시도할 때 문제가 된다.

개인적으로는 Primary 시작부터 클러스터 이름 길이에 대한 유효성 검사를 하는 부분을 추가하여 PR을 하고 싶지만, MySQL 및 Galera Cluster에 대한 전체 소스를 파악하지 못한 상태에서 섣불리 수정할 수 없기에 우선은 마음에만 담아 두기로 했다.

[참고자료]

l https://github.com/bloomberg/chef-bcpc/issues/649

2023-12-08 / Sungwook Kang / http://sungwookkang.com

MySQL, Percona, Galera Cluster, 퍼코나, 갈레라 클러스터, 클러스터 이름 길이 초과, wsrep_cluster_name

[MySQL] SHOW PROCESSLIST로 현재 실행중인 스레드 목록 확인하기

SungWookKang — Mon, 4 Dec 2023 10:28:44 +0900

[MySQL] SHOW PROCESSLIST로 현재 실행중인 스레드 목록 확인하기

l Version : MySQL

MySQL에서 현재 실행중인 스레드 목록을 확인하기 위해서는 SHOW PROCESSLIST 명령어를 사용할 수 있다. PROCESS 권한이 있으면 다른 사용자에게 속한 스레드까지 포함하여 모든 스레드를 볼 수 있다. 그렇지 않으면 익명이 아닌 사용자는 자신의 스레드에 대한 정보에만 액세스할 수 있어 다른 사용자의 스레드 정보는 확인할 수 없다.

SHOW PROCESSLIST 명령문은 정보 필드에 각 문의 처음 100자만 표시한다. info 컬럼에 현재 실행중인 SQL문 전체를 표시하고 싶을 경우 SHOW FULL PROCESSLIST 명령을 사용한다.

아래 명령어를 사용하여 실행중인 스레드의 목록을 살펴본다.

mysql> show processlist;

컬럼명	정보
Id	프로세스 ID ( = INFORMATION_SCHEMA PROCESSLIST테이블의 ID컬럼값과 동일)
User	MySQL에 접속하고 있는 User 명
Host	User가 접속하고 있는 Client 호스트 명 (IP 주소)
db	스레드의 기본 데이터베이스 (default: NULL)
Command	실행중인 스레드 명령 타입
Time	스레드가 현재 상태에 있었던 시간 (초)
State	스레드가 수행중인 작업을 나타내는 이벤트, 상태
Info	스레드가 실행중인 명령문 (실행하지 않을경우 : NULL)
Time_ms	스레드가 현재 상태에 있었던 시간 (밀리초)
Rows_sent	스레드에서 보낸 ROWS 수
Rows_examined	프로세스가 검사한 행 수

조회 결과에서 Command 컬럼은, 현재 스레드의 명령 타입을 보여주는데, 이때 다양한 명령 타입이 있으므로 각 상태의 정보를 알고 있으면 운영에 많은 도움이 된다.

상태타입	정보
Binlog Dump	바이너리 로그 내용을 복제본으로 보내기 위한 복제 소스의 스레드
Change user	스레드가 사용자 변경 작업을 실행 중
Close stmt	스레드가 준비된 명령문을 닫는 중
Connect	소스에 연결된 복제 수신기 스레드와 복제 작업자 스레드에서 사용
Connect Out	복제본이 소스에 연결 중
Create DB	스레드가 데이터베이스 생성 작업을 실행 중
Daemon	클라이언트 연결을 서비스하는 스레드가 아닌 서버 내부 스레드
Debug	스레드가 디버깅 정보 생성 중
Delayed insert	지연된 삽입 처리기
Drop DB	스레드가 데이터베이스 삭제 작업을 실행 중
Error
Execute	스레드가 준비된 명령문을 실행하고 있음
Fetch	스레드가 준비된 명령문을 실행하여 결과를 가져오는 중
Field List	스레드가 테이블 열에 대한 정보를 검색 중
Init DB	스레드가 기본 데이터베이스를 선택
Kill	스레드가 다른 스레드를 강제 종료시킴
Long Data	스레드는 준비된 명령문을 실행한 결과 긴 데이터를 검색
Ping	스레드가 서버 핑 요청 처리
Prepare	스레드가 준비된 명령문을 준비 중
Processlist	스레드가 서버 스레드에 대한 정보를 생성
Query	클라이언트의 쿼리 실행
Quit	스레드가 종료되고 있음
Refresh	스레드가 테이블, 로그 또는 캐시를 플러시하거나 상태 변수 또는 서버정보 재설정
Register Slave	스레드가 복제 서버를 등록
Reset stmt	스레드가 준비된 명령문을 재설정 중
Set option	스레드가 클라이언트 문 실행 옵션을 설정하거나 재설정하는 중
Shutdown	스레드가 서버 종료하고 있음
Sleep	클라이언트가 새로운 명령을 보내기를 기다림
Statistics	스레드가 서버 상태 정보를 생성
Statistics	스레드가 서버 상태 정보를 생성

일반적으로 SHOW PROCESSLIST 문은 "연결이 너무 많습니다" 오류 메시지가 표시되고 무슨 일이 일어나고 있는지 확인하려는 경우 매우 유용하게 사용할 수 있다. MySQL은 관리자가 항상 연결하고 시스템을 확인할 수 있도록 하기 위해 CONNECTION_ADMIN 권한(또는 더 이상 사용되지 않는 SUPER 권한)이 있는 계정이 사용할 추가 연결을 미리 예약한다. 데이터베이스에서 특정 사용자가 오랫동안 쿼리를 실행하고 있거나, 현재 실행중인 스레드에 문제점을 찾고 싶을 경우에도 유용하게 활용할 수 있다.

[참고자료]

l SHOW PROCESSLIST Statement : https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html

l Thread Command Values : https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html

2023-12-04 / Sungwook Kang / http://sungwookkang.com

MySQL, SHOW PROCESSLiST, 스레드 목록 확인, 실행중인 쿼리 확인, 마이에스큐엘, 프로세스리스트. 스레드리스트, 롱쿼리, 슬로우쿼리, 연결상태확인

[MySQL] Stopping Purge/Resuming Purge in Error Logs

SungWookKang — Fri, 1 Dec 2023 10:03:43 +0900

[MySQL] Stopping Purge/Resuming Purge in Error Logs

l Version : MySQL 5.7 X

MySQL 5.7.X 운영환경에서 아래와 같은 로그가 잔뜩 기록되어 있었다. 계속해서 반복되는 Stoppoing purge과 Resuming purge는 오류로 기록되고 있지는 않았지만, 반복해서 남는 로그에 원인이 궁금했다.

023-11-22T15:27:13.249813Z 4 [Note] InnoDB: Stopping purge
2023-11-22T15:27:13.363487Z 4 [Note] InnoDB: Resuming purge
2023-11-22T15:27:13.462275Z 4 [Note] InnoDB: Stopping purge
2023-11-22T15:27:13.548486Z 4 [Note] InnoDB: Resuming purge

해당 로그에 관한 내용을 살펴보니 해당 로그는 테이블에서 TRUNCATE가 발생할 때 마다 기록되었다. 로그를 재현해 보기 위해 간단히 테이블을 생성하고 TRUNCATE 구문을 실행해 보았다. 해당 로그가 기록되기 위해서는 Vervos log 수준이 3으로 설정되어 있어야 한다.

show variables like 'log_error_verbosity%';

로그를 재현하기 위해 빈 테이블을 하나 생성하고, TRUNCATE 명령을 반복적으로 실행하였다.

mysql> create table t(id int primary key);

mysql> truncate table t;

mysql> truncate table t;

mysql> truncate table t;

mysql> truncate table t;

실행 결과 후 로그를 살펴보니 아래와 같이 로그가 기록된 것을 확인할 수 있었다.

자료를 찾다보니 이러한 상황은 이미 알려진 Bug로 리포팅이 되었다고 한다. 그리고 MySQL 8.0에서는 해결이 되었다고 한다. 아마도 MySQL 5.7.X는 2023년 10월부터 EOL(End of Life)되었므로 아마도 기존 버전에는 더 이상 fix가 될것 같지 않은 개인적인 생각이 들며, 이 문제를 해결하기 위해서는 MySQL 8.0으로 업그레이드 또는 MySQL 5.7에서는 불필요하게 로그가 남지 않도록 verbos 로그 수준을 2로 조정하여 사용해야 할 듯하다.

[참고자료]

l https://www.percona.com/blog/bug-stopping-purge-resuming-purge-in-error-logs

2023-12-01 / Sungwook Kang / http://sungwookkang.com

MySQL, Percona, InnoDB purge, TRUNCATE TABLE,

[MySQL] 삭제 마킹된 데이터를 물리적으로 제거하는 purge thread 와 설정을 위한 innodb_purge_threads 변수 알아보기

SungWookKang — Fri, 24 Nov 2023 11:28:12 +0900

[MySQL] 삭제 마킹된 데이터를 물리적으로 제거하는 purge thread 와 설정을 위한 innodb_purge_threads 변수 알아보기

l Version : MySQL 5.5 later

MySQL purge thread는 삭제 표시된 레코드를 물리적으로 제거하는 작업을 하는 스레드이다. 쉽게 설명하면 가비지 컬렉션과 같은 역할이다. DELETE 쿼리 등에 의해 삭제되었다고 마킹된 데이터에 대해서 물리적으로 삭제 작업을 한다.

MySQL의 innodb_purge_threads 변수는 InnoDB 스토리지 엔진에서 제거 작업 전용 스레드 수를 제어하는 데 사용된다. Purge thread는 더 이상 필요하지 않은 행을 삭제하는 프로세스이다. 일반적으로 이러한 상황은 해당 행이 삭제 또는 업데이트되었으며 최신 버전의 행이 존재하기 때문이다.

데이터베이스, 특히 데이터 수정(업데이트 및 삭제) 수준이 높은 데이터베이스에서는 이전 버전의 행이 누적될 수 있다. 이로 인해 스토리지 사용량이 증가하고 성능이 저하되며 데이터베이스 복구와 같은 특정 작업에 소요되는 시간이 길어질 수 있다. Purge thread를 2이상 값으로 설정하여 스레드를 사용하면 잠재적으로 이러한 오래된 행을 정리하는 프로세스 속도를 높일 수 있다. 이는 많은 데이터가 정기적으로 수정되는 처리량이 많은 데이터베이스에 특히 유용할 수 있다.

MySQL, Percona, MariaDB의 purge 스레드에 대한 설정 정의는 아래와 같다.

Name	MySQL	Percona	MariaDB
Variable	Innodb_purge_threads	Innodb_purge_threads	Innodb_purge_threads
Configuration	Supported	Supported	Supported
Scope	Global, Session	Global, Session	Global, Session
Dynamic	No	No	No
Data Type	Integer	Integer	INT UNSIGNED
Default Value	4	4	4
Minium Value	1	1	1
Maximum Value	32	32	32

현재 설정된 innodb_purge_threads 값을 확인하는 방법은 아래 스크립트를 사용하여 확인할 수 있다.

show variables like '%innodb_purge_threads%';

innodb_purge_threads 변수 설정은 시작 시 사용되는 구성 파일을 사용하여 구성할 수 있다. value를 데이터베이스 요구 사항에 맞는 값으로 수정하여 사용한다. 적용된 변경 사항을 보려면 MySQL 서버를 다시 시작해야 한다.

[mysqld]
innodb_purge_threads variable = value

많은 데이터베이스 구성 설정과 마찬가지로 innodb_purge_threads의 최적 값은 워크로드 및 하드웨어의 세부 사항에 따라 크게 달라질 수 있다. 따라서 일률적인 권장사항을 제공하기는 어렵다. MySQL에서 innodb_purge_threads 변수를 설정하거나 조정할 때 다음 사항을 고려할 수 있도록 한다.

l 작업 부하 특성 – 제거 스레드 수 증가의 영향은 작업 부하에 따라 크게 달라질 수 있다. 데이터베이스의 데이터 수정(삭제 및 업데이트) 비율이 높은 경우 이 값을 늘리면 불필요한 오래된 행 버전을 더 빠르게 제거하여 성능을 향상시킬 수 있다. 그러나 작업 부하가 수정 횟수가 적고 읽기 작업이 많은 경우 이 변수를 늘리면 이점이 줄어들 수 있다.

l 시스템 리소스 – 각 추가 제거 스레드는 더 많은 CPU 및 기타 시스템 리소스를 소비한다. 전체 시스템 성능에 부정적인 영향을 주지 않으면서 서버에 추가 스레드를 처리할 수 있는 충분한 용량이 있는지 확인해야 한다.

l 복구 시간에 대한 영향 – 제거 작업은 실행 취소 로그가 너무 커지는 것을 방지하여 충돌 발생 시 데이터베이스 복구 시간을 단축할 수 있다. 시스템이 행 수정 속도를 따라잡을 수 없는 경우 제거 스레드 수를 늘리면 잠재적으로 복구 시간이 줄어들 수 있다.

[참고자료]

l https://releem.com/docs/mysql-performance-tuning/innodb_purge_threads

l https://www.alibabacloud.com/blog/mysql-engine-features-innodb-based-physical-replication_65220

2023-11-24 / Sungwook Kang / http://sungwookkang.com

MySQL, Percona, purge thread, innodb_purge_threads, 퍼지스레드

[Grafana] Grafana에서 이메일 알림 보내기

SungWookKang — Fri, 17 Nov 2023 15:02:23 +0900

[Grafana] Grafana에서 이메일 알림 보내기

l Grafana, PMM

Grafana(“그라파나”)에서는 이상 징후를 감지했을 때, 대시보드 패널에서 알림 규칙을 추가하여 다양한 방식으로 알림을 받을 수 있다. 이번 포스트에서는 그라파나에서 이메일로 알람을 보낼 수 있도록 설정하는 방법에 대해서 알아본다.

알람을 이메일로 보내기 위해서는 그라파나에서 SMTP 설정을 해야한다. 물론 SMTP 로 사용할 이메일 서버에서는 SMTP 서비스가 허용되어 있어야 한다. 그라파나가 설치된 서버에서 Grafana.ini 설정파일을 수정하여 SMTP 정보를 등록한다.

vi /etc/Grafana/Grafana.ini

설정파일에서 아래 내용을 참고하여 추가하도록 한다.

[smtp]
enabled = true
host = smtp.office365.com:587
user = <o365 username>
password = <o365 Password>
;cert_file =
;key_file =
skip_verify = false
from_address = <o365 username>
;from_name = Grafana
;EHLO identity in SMTP dialog (defaults to instance_name)
;ehlo_identity = dashboard.example.com
[emails]
;welcome_email_on_sign_up = false

이번 포스트에서는 네이버 메일로 SMTP를 설정하였다.

[smtp]
enabled = true
host = smtp.naver.com587
user = email@naver.com
password = your_passwrod
;cert_file =
;key_file =
skip_verify = false
from_address = email@naver.com
;from_name = Grafana
;EHLO identity in SMTP dialog (defaults to instance_name)
;ehlo_identity = dashboard.example.com
[emails]
;welcome_email_on_sign_up = false

네이버 메일의 SMTP를 사용하려면 네이버에 로그인한 다음 사용자 이메일 설정에서 SMTP를 사용가능하도록 설정이 필요하다. 해당 설정 부분은 다른 글을 참고한다.

grafana.ini 설정이 완료 되었으면 Grafana 서비스를 재시작하여 변경된 설정을 적용한다.

supervisorctl restart grafana

컨테이너로 그라파나를 운영하는 경우 아래와 같은 명령으로 컨테이너 내부에서 수정할 수 있다,

→$sudo docker exec -it pmm-server bash
→##cd /etc/grafana
→## vi grafana.ini

또는 컨테이너 실행시 환경변수로 대입하여 설정할 수 있다.

# Docker run -d -p 80:80 -p 443:443 --volumes-from pmm-data --name pmm-server \
--restart always \
-e GF_SMTP_ENABLED=true \
-e GF_SMTP_HOST=smtp.gmail.com:587 \
-e GF_SMTP_USER=<gmail username> \
-e GF_SMTP_PASSWORD=<gmail password> \
-e GF_SMTP_SKIP_VERIFY=false \
-e GF_SMTP_FROM_ADDRESS=<gmail email address> \
-e GF_SMTP_FROM_NAME=Grafana \
percona/pmm-server:2

SMTP 설정이 완료되었으면 Grafana 대시보드의 좌측 메뉴에서 Alerting – Contact point를 클릭 한다.

Alerting 페이지의 Contact point 탭 화면에서 [New contact point]를 클릭한다.

발지자에 사용할 이름과 수신자의 이메일을 등록한다. [Test] 버튼을 클릭하면 이메일을 보내어 정상적으로 발신이 되는지 확인할 수 있다. 설정이 완료되었으면 [Save contact point]를 클릭한다.

메일함을 열어 확인해보면 Grafana가 Test 단계에서 보낸 이메일을 확인할 수 있다.

이메일 세팅이 완료되었으므로, 사용자 환경에 맞게 템플릿을 활용하거나 직접 코드를 작성하여 대시보드에서 이상징후가 감지되었을 때 이메일로 받을 수 있다. 이메일로 알람을 받을 때에는 해당 알람의 관련 그래프나 기타 정보를 함께 포함하여 발송할 수 있다.

2023-11-16 / Sungwook Kang / https://sungwookkang.com

그라파나, Grafana, 알림설정, Alert, email notification, 이메일 설정, 그라파나SMTP, Grafana.ini

[PMM] PMM Client 실행시 사용되는 동적 포트 변경하기

SungWookKang — Wed, 15 Nov 2023 15:20:19 +0900

[PMM] PMM Client 실행시 사용되는 동적 포트 변경하기

l Version : PMM 2.X

이번 포스트는 PMM Client의 설정 파일을 수정하여 동적 포트의 범위를 제한하는 방법에 대해서 알아본다.

PMM은 Percona Monitoring and Management의 약자로 PostgreSQL 및 MySQL, MongoDB를 위한 오픈소스 데이터베이스 모니터링 및 관리 솔루션이다. 이를 통해 데이터베이스 시스템의 상태를 관찰하고, 동작의 새로운 패턴을 탐색하고, 문제를 해결하고, 온프레미스나 클라우드 어디에 있든 데이터베이스 관리 작업을 수행할 수 있다. PMM은 데이터베이스와 해당 호스트로부터 수천 개의 기본 성능 지표를 수집한다. 그리고 웹 UI 대시보드를 제공하여 데이터를 시각화 한다. 추가 기능에는 데이터베이스 상태 평가를 위한 조언을 제공하기도 한다. PMM에 대한 자세한 내용은 아래 링크를 참고한다.

l MySQL PMM(Percona Monitoring and Management) 소개 및 설치 : https://sungwookkang.com/entry/MySQL-PMMPercona-Monitoring-and-Management-%EC%86%8C%EA%B0%9C-%EB%B0%8F-%EC%84%A4%EC%B9%98

PMM Client는 PMM Server와 통신을 할 때 다양한 포트를 사용한다. PMM에서 사용되는 네트워크 포트 정보는 아래 공식 문서를 참고한다.

l PMM Network : https://docs.percona.com/percona-monitoring-and-management/setting-up/server/network.html#ports

문서를 살펴보면 PMM Server로의 연결은 443 포트를 사용하지만, PMM Client에서는 동적포트를 사용하여 아웃바운드를 시도한다. 그 이유는 PMM Client Agent가 실행되는 서버에 혹시나 이미 다른 서비스가 해당 포트를 점유해서 사용하고 있을 수 있기 때문에 설정파일에서 지정한 범위에서 랜덤하게 포트를 할당해서 사용한다.

그런데 이와 같이 넓은 범위의 랜덤한 동적포트를 사용하게 되면, 사용자 환경에 따라 아웃바운드까지 제어하는 환경에서는 많은 범위의 포트를 열어야 하기에 보안에 취약해질 수 있다. PMM Client의 설정 파일을 수정하여 동적 포트의 범위를 제한하는 방법에 대해서 알아본다.

PMM Client가 실행되면 파일에 기록된 설정 값을 읽어 사용한다. 파일은 기본적으로 아래와 같은 경로에 위치한다. 여기에서 min, max의 범위를 설정하여 사용할 수 있다.

/usr/local/percona/pmm2/config/pmm-agent.yaml

PMM Client가 실행될 때, 기본 경로의 pmm-agent.yaml 파일을 사용할 수도 있지만, 사용자가 별도의 설정 파일을 만들어 사용할 수도 있다. 자세한 사용법은 아래 링크를 참고 한다.

l pmm-agent - PMM Client agent : https://docs.percona.com/percona-monitoring-and-management/details/commands/pmm-agent.html#options-and-environment

공식문서를 요약해보면, 커스텀한 설정 파일을 만들고 PMM Client를 실행할 때, paths-base 옵션을 사용하여 커스텀한 설정 파일을 사용하게 한다.

pmm-agent setup --paths-base=/home/user/custom/pmm2 --config-file=pmm-agent-dev.yaml --server-insecure-tls --server-address=127.0.0.1:443 --server-username=admin --server-password=admin

2023-11-15 / Sungwook Kang / http://sungwookkang.com

MySQL, PMM, Percona, DB Monitoring, PMM Port change, PMM 포트변경,

[MySQL] MySQL에서 caching_sha2_password 특징 및 mysql_native_password 사용하기

SungWookKang — Mon, 13 Nov 2023 13:59:56 +0900

[MySQL] MySQL에서 caching_sha2_password 특징 및 mysql_native_password 사용하기

l Version : MySQL 8.0

MySQL은 다양한 계정 인증 플러그인 방식을 지원하고 있다. 현재 공식 매뉴얼에 따르면 13개의 인증 방식을 제공하고 있다.

l https://dev.mysql.com/doc/refman/8.0/en/authentication-plugins.html

이번 포스트에서는 다양한 플러그인 중에 MySQL 8버전부터 변경된 인증 방식인 caching sha2_password에 대해서 알아보고 MySQL 8버전에서 이전 버전의 mysql_native_password를 사용하는 방법에 대해서 알아본다.

MySQL 5.7버전까지는 기본 인증 방식이 mysql_native_password이다. MySQL 8버전 부터는 기본 인증방식이 caching_sha2_password 방식으로 변경되었다. mysql_native_password는 계정 비밀번호에 SHA-1 알고리즘을 사용하여 해시된 값을 저장해두고 사용자가 로그인시 입력한 비밀번호의 해시 값을 비교하는 방식이었다. 즉, 해시 값을 저장하여 비교하기 때문에 다른 계정에서 동일한 비밀번호를 사용한다면 MySQL에서는 동일한 해시값을 가지고 있다. 그래서 해시값에 따라 비밀번호를 유추할 가능성이 있는 취약점이 존재한다.

MySQL 8 버전부터 caching_sha2_password를 사용하는데, 이 방식은 비밀번호를 해시하여 저장할 때, salt 키를 사용하여 동일한 비밀번호에 대해서도 서로 다른 해시 값이 생성되도록 하였고, 기존의 암호화 방식보다 강화된 256비트 알고리즘을 사용하였다. 그래서 동일한 비밀번호를 사용하더라도 저장된 해시값이 다르기 때문에 유추의 어렵도록 보안이 강화되었다. 하지만 로그인시 해시값을 비교하기 위한 리소스가 증가하게 되어 빈번한 로그인시 오버헤드에 따른 성능 저하가 발생할 수 있어 이러한 부분을 개선하고자 로그인한 해시값을 서버측 메모리에 캐싱하여 재사용하는 방식으로 연결에 대한 인증 성능을 높였다.

아래 스크립트를 사용하면 현재 운영중인 MySQL의 기본 인증방식을 확인할 수 있다.

mysql> show variables like 'default_authentication_plugin';

기본 인증 방식이 변경하려면 my.cnf에서 mysqld에서 기본 인증으로 사용할 플러그인을 명시하여 변경할 수 있다.

[mysqld]
default_authentication_plugin=caching_sha2_password

아래 스크립트는 기본 인증 방식을 변경하는 것은 아니며 MySQL8에서 mysql_native_password를 사용할 수 있도록 플러그인을 추가한 것이다.

authentication-policy=mysql_native_password

계정을 생성할 때, 사용할 플러그인을 명시하면 해당 플러그인을 사용할 수 있다.

--caching_sha2_password
mysql> CREATE USER 'user'@'%' IDENTIFIED WITH caching_sha2_password BY 'password';

--mysql_native_password
mysql> CREATE USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

생성된 계정의 plugin 타입을 조회해 보면 사용된 비밀번호 암호화시 사용된 플러그인을 확인할 수 있다.

mysql> select user, plugin from mysql.user;

2023-11-13 / Sungwook Kang / http://sungwookkang.com

MySQL, MySQL Authentication Plugin, MySQL Password, 마이에스큐엘, 인증방식 변경, caching_sha2_password, mysql_native_password

[MySQL] MySQL에서 SSL 인증서 사용하기

SungWookKang — Thu, 9 Nov 2023 14:55:27 +0900

[MySQL] MySQL에서 SSL 인증서 사용하기

l Version : MySQL 8.0

MySQL에서 SSL 통신을 위해서는 인증서를 사용하게 되는데, 이때 인증서는 MySQL을 시작할 때 자동으로 생성되기도 하며, 수동으로 생성할 경우 openssl 등을 사용하여 생성할 수 있다. 또한 타사 서비스와 연동이 필요한 경우 타사의 인증서를 등록해서 사용할 경우가 있는데, 이때 pem 확장자 형식으로 인증서를 변환해서 사용할 수 있다.

MySQL 시작 시 생성되는 인증서는 보통 데이터 디렉토리(data directory)에 생성되며 아래와 같은 인증서 파일이 생성된다.

l ca.pem : self-signed CA cetificate

l ca-key.pem : CA private key

l private_key.pem

l public_key.pem

l server-cert.pem : Server certificate

l server-key.pem : Server private key

l client-cert.pem : Client certificate

l client-key.pem : Client private key

현재 서버의 인증서를 다른 서버에 등록하여 사용할 때에는 ca.pem, server-cert.pem, server-key.pem 파일을 복사하여 다른 MySQL 서버에 등록하여 사용할 수 있다. 파일을 복사하였으면, my.cnf에서 인증서의 위치를 설정하여 서비스에 사용할 수 있도록 해야한다.

[my.cnf]

[mysqld]
ssl-ca=/var/lib/mysql/ca.pem
ssl-cert=/var/lib/mysql/server-cert.pem
ssl-key=/var/lib/mysql/server-key.pem

my.cnf 수정이 완료되었으면 mysql을 재시작 한다. mysql에 접속하여 SSL과 관련된 상태를 살펴보면 현재 인증서 작동 유무를 확인할 수 있다. have_openssl, have_ssl이 YES로 표시되면 인증서가 정상적으로 등록되어 사용중인것으로 확인할 수 있다.

MySQL 접근을 위한 사용자 계정 생성시 SSL을 사용한 권한을 생성할 때에는 require SSL을 명시하여 생성한다.

grant all privileges on *.* to 'app_user'@'%' identified by 'password' require SSL;

CLI에서 SSL을 사용한 접속은 아래 스크립트처럼 클라이언트의 인증서키를 명시하고 접속한다.

mysql -uapp_user -p -h172.0.0.1 --ssl --ssl-ca=cert.pem

2023-11-09 / Sungwook Kang / http://sungwookkang.com

MySQL, SSL, 인증서통신, 인증서등록

[MySQL] [InnoDB] Failed to create check sector file, errno:13 Please confirm O_DIRECT is supported 오류 및 해결

SungWookKang — Thu, 2 Nov 2023 15:16:59 +0900

[MySQL] [InnoDB] Failed to create check sector file, errno:13 Please confirm O_DIRECT is supported 오류 및 해결

l Version : MySQL 8.0

MySQL을 시작할 때, 정상적으로 서비스가 시작되지 않았으며 아래와 같은 오류 로그를 확인할 수 있었다.

[ERROR] [MY-012655] [InnoDB] Failed to create check sector file, errno:13 Please confirm O_DIRECT is supported and remove the file /var/lib/check_sector_size if it exists.

Error 13에 대해서 찾아보면 공식 매뉴얼에는 퍼미션에 관련된 내용으로 안내 되어 있다.

l https://dev.mysql.com/doc/mysql-installation-excerpt/8.0/en/starting-server-troubleshooting.html

If you get Errcode 13 (which means Permission denied) when starting mysqld, this means that the privileges of the data directory or its contents do not permit server access. In this case, you change the permissions for the involved files and directories so that the server has the right to use them. You can also start the server as root, but this raises security issues and should be avoided.

하지만 해당 이슈는 mysql.cnf에 설정된 innodb_data_home_dir 파라메터에 설정된 경로에서 마지막 슬래시(/)가 누락되어 발생한 오류이다. 해결 방법은 경로 마지막에 슬래시(/)만 추가하면 된다.

my.cnf

innodb_data_home_dir = /var/lib/mysql/

2023-11-02 / Sungwook Kang / http://sungwookkang.com

MySQL, innodb, o_direct, error13

[MySQL] MySQL 저장 프로시저 - 소개

SungWookKang — Mon, 23 Oct 2023 15:51:33 +0900

[MySQL] MySQL 저장 프로시저 - 소개

l Version : MySQL

MySQL 저장 프로시저와 장, 단점에 대해서 알아본다.

아래 스크립트는 테이블에 있는 데이터를 조회한다.

SELECT
           customer_id,
    first_name,
    last_name,
    email
FROM customer
ORDER BY first_name;

MySQL Workbench 또는 mysql 셸을 사용하여 MySQL Server에 쿼리를 실행하면 MySQL은 쿼리를 처리하고 결과 집합을 반환한다. 나중에 실행하기 위해 이러한 쿼리를 데이터베이스 서버에 저장하기 위해 저장 프로시저를 사용할 수 있다.

아래 스크립트에서 CREATE PROCEDURE 문은 위의 쿼리를 래핑하여 새 저장 프로시저를 만든다.

DELIMITER $$

CREATE PROCEDURE GetCustomers()
BEGIN
           SELECT
           customer_id,
    first_name,
    last_name,
    email
FROM customer
ORDER BY first_name;
END$$
DELIMITER ;

정의에 따르면 저장 프로시저는 MySQL 서버 내에 저장된 선언적 SQL 문의 세그먼트이다. 이 예에서는 GetCustomers()라는 이름으로 생성하였다. 저장프로시저의 호출은 CALL 명령문을 사용한다.

CALL GetCustomers();

저장 프로시저를 호출하면 동일한 결과가 나타난다. 저장 프로시저를 처음 호출하면 MySQL은 다음을 수행한다.

l 첫째, 데이터베이스 카탈로그에서 이름으로 저장 프로시저를 찾는다.

l 둘째, 저장 프로시저의 코드를 컴파일 한다.

l 셋째, 컴파일된 저장 프로시저를 캐시라고 알려진 메모리 영역에 배치한다.

l 넷째, 저장 프로시저를 실행한다.

동일한 세션에서 동일한 저장 프로시저를 다시 호출하면 MySQL은 다시 컴파일할 필요 없이 캐시에서 저장 프로시저를 실행한다.

저장 프로시저에는 매개 변수가 있어서 값을 전달하고 결과를 다시 가져올 수 있다. 예를 들어 국가 및 도시별로 고객을 반환하는 저장 프로시저가 있을 수 있다. 이 경우 국가와 도시는 저장 프로시저의 매개변수이다. 저장 프로시저에는 IF, CASE, LOOP와 같은 제어문이 포함될 수 있다. 저장 프로시저는 다른 저장 프로시저나 저장 함수를 호출할 수 있으므로 코드를 보다 효과적으로 구성할 수 있다.

저장 프로시저의 장점은 다음과 같다.

l 네트워크 트래픽 감소 : 저장 프로시저는 애플리케이션과 MySQL 서버간의 네트워크 트래픽을 줄이는 데 도움이 된다. 왜냐하면 애플리케이션은 긴 SQL문을 여러 개 보내는 대신, 저장 프로시저의 이름과 매개변수만 보내면 되기 때문이다.

l 데이터베이스에 비즈니스 논리 중앙 집중화 : 저장 프로시저를 사용하여 여러 애플리케이션에서 재사용할 수 있는 비즈니스 논리를 구현할 수 있다. 저장 프로시저는 많은 애플리케이션에서 동일한 논리를 복제하는 노력을 줄이고 데이터베이스의 일관성을 높이는데 도움이 된다.

l 데이터베이스 보안 강화 : 데이터베이스 관리자는 기본 테이블에 대한 권한을 부여하지 않고 특정 저장 프로시저에만 액세스하는 애플리케이션에 적절한 권한을 부여할 수 있다.

저장 프로시저의 단점은 다음과 같다.

l 리소스 사용량 : 저장 프로시저를 많이 사용하는 모든 연결의 메모리 사용이 크게 늘어난다. 게다가 저장 프로시저에서 많은 수의 논리적 작업을 과도하게 사용하면 MySQL이 논리 작업에 적합하게 설계되지 않았기 때문에 CPU 사용량이 증가한다.

l 문제 해결 : 저장 프로시저를 디버깅하기가 어렵다. MySQL은 다른 데이터베이스 제품과 다르게 저장 프로시저를 디버깅하는 기능을 제공하지 않는다.

l 유지 관리 : 저장 프로시저를 개발하고 유지 관리하려면 모든 응용 프로그램 개발자가 보유하지 않은 전문 기술이 필요한 경우가 많다. 이로 인해 애플리케이션 개발 및 유지 관리 모두에 문제가 발생할 수 있다.

2023-10-23 / Sungwook Kang / http://sungwookkang.com

MySQL, Stored Procedure, 저장프로시저

[MySQL] MySQL에서 기본키로 UUID를 선택했을 때의 장단점 및 특징

SungWookKang — Fri, 20 Oct 2023 15:18:02 +0900

[MySQL] MySQL에서 기본키로 UUID를 선택했을 때의 장단점 및 특징

l Version : MySQL PXC 8.0.X

MySQL UUID에 대해서 알아보고 테이블의 기본키로 사용하는 방법 및 UUID를 기본키로 했을 때의 장단점에 대해서 알아본다.

UUID는 universally unique Identifier의 약자로 RFC 4122를 기반으로 정의된다. UUID는 공간과 시간에 있어서 전 세계적으로 고유한 숫자로 설계되었다. 두 개의 UUID 값은 두개의 독립적인 서버에 생성되더라도 서로 구별되어야 한다.

MySQL에서 UUID값은 다음 형식의 5개의 16진수 숫자로 구성된 utf8 문자열로 표시되는 128비트 숫자이다.

aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

UUID 값을 생성하려면 UUID() 함수를 사용하며, RFC 4122에 설명된 UUID 버전1에 따라 UUID 값을 반환한다.

SELECT UUID()

기본키에 UUID를 사용하면 다음과 같은 이점이 있다.

l UUID 값은 테이블, 데이터베이스, 심지어 다른 데이터베이스의 행을 병합하거나 서버 간에 데이터베이스를 배포할 수 있는 서버에서도 고유하다.

l UUID 값은 데이터에 대한 정보를 노출하지 않으므로 URL에서 사용하는 것이 더 안전하다. 예를 들어 ID가 10인 고객이 http://www.example.com/customers/10/URL을 통해 자신의 계정에 접속하면 고객 11, 12 등이 있다고 쉽게 추측할 수 있으며 이것이 공격 대상이 될 수 있다.

l UUID 값은 데이터베이스 서버로의 왕복을 피하는 어디에서나 생성될 수 있다. 또한 애플리케이션의 논리를 단순화한다. 예를 들어 상위 테이블과 하위 테이블에 데이터를 삽입하려면 먼저 상위 테이블에 삽입하고 생성된 ID를 가져온 다음 하위 테이블에 데이터를 삽입해야 한다. UUID를 사용하면 상위 테이블의 기본 키 값을 미리 생성하고 트랜잭션 내에서 동시에 상위 테이블과 하위 테이블 모두에 행을 삽입할 수 있다.

하지만 아래와 같은 단점도 존재한다.

l UUID 값(16바이트)을 저장하려면 정수(4바이트) 또는 큰 정수(8바이트)보다 더 많은 저장 공간이 필요하다.

l WHERE id = 'df3b7cb7-6a95-11e7-8846-b05adad3f0ae'처럼 사용해야 해서 디버깅이 어려울 수 있다.

l UUID 값을 사용하면 크기 및 정렬 불가 문제로 인해 성능 문제가 발생할 수 있다.

MySQL에서는 UUID 값을 간단한 형식(BINARY)으로 저장하고 다음 기능을 사용하여 사람이 읽을 수 있는 형식(VARCHAR)으로 표시할 수 있다. 다만 해당 함수는 MySQL 8.0이상에서만 사용할 수 있다.

l UUID_TO_BIN

l BIN_TO_UUID

l IS_UUID

UUID_TO_BIN() 함수는 UUID를 사람이 읽을 수 있는 형식(VARCHAR)에서 압축 포맷(BINARY) 형식으로 변환하여 저장하고, BIN_TO_UUID()는 UUID를 압축 포맷(BINARY) 형식에서 사람이 읽을 수 있는 형식(VARCHAR)으로 변환하여 표시한다.

IS_UUID() 함수는 유효한 문자열 형식 UUID인 경우 함수는 1을 반환한다. 인수가 유효한 문자열 형식 UUID가 아닌 경우 함수는 0을 반환한다. IS_UUID인수가 NULL, IS_UUID()인 경우 함수는 NULL를 반환한다.

다음은 MySQL의 유효한 문자열 형식 UUID이다.

aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
aaaaaaaabbbbccccddddeeeeeeeeeeee
{aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee}

아래 스크립트는 UUID를 기본키로 사용하는 테이블 생성 스크립트이다.

CREATE TABLE customers (
id BINARY(16) PRIMARY KEY,
name VARCHAR(255)
);

id열에 UUID 값을 삽입하려면 다음과 같이 UUID() 및 UUID_TO_BIN()함수를 사용한다.

INSERT INTO customers(id, name)
VALUES(UUID_TO_BIN(UUID()),'John Doe'),
(UUID_TO_BIN(UUID()),'Will Smith'),
(UUID_TO_BIN(UUID()),'Mary Jane');

UUID 열에서 데이터를 쿼리하려면 BIN_TO_UUID()함수를 사용하여 이진 형식을 사람이 읽을 수 있는 형식으로 변환한다.

SELECT
    BIN_TO_UUID(id) id,
    name
FROM
    customers;

[참고자료]

l https://www.mysqltutorial.org/mysql-uuid/

2023-10-19 / Sungwook Kang / http://sungwookkang.com

MySQL, MySQL UUID

[MySQL] MySQL PXC (Percona XtraDB Cluster) 5.7에서 8.0 업그레이드시 timeout 문제 및 해결 방법

SungWookKang — Thu, 19 Oct 2023 11:26:37 +0900

[MySQL] MySQL PXC (Percona XtraDB Cluster) 5.7에서 8.0 업그레이드시 timeout 문제 및 해결 방법

l Version : MySQL PXC 8.0.X

MySQL PXC (Percona XtraDB Cluster) 5.7환경에서 8.0으로 업그레이드 진행중에 발생한 이슈가 있어, 문제 및 해결 방법에 대해서 정리한다.

[Problem]

기존에 운영중이던 MySQL PXC 5.7.X 버전에서 MySQL 8.0.X로 업그레이드 작업이 필요 했으며, 업그레이드를 위해 여러 상황을 검토한 결과 XtraBackup을 사용하여 백업(5.7) 및 복원(8.0)으로 진행하였다. 복원 과정 (리스토어 및 서비스 시작)에서 timeout 오류가 발생하였다. 해당 데이터베이스는 테이블이 약 70만개 존재한다.

root@mysqlpxc:/etc/default# systemctl start mysql@bootstrap.service
Job for mysql@bootstrap.service failed because a timeout was exceeded.
See "systemctl status mysql@bootstrap.service" and "journalctl -xeu mysql@bootstrap.service" for details.

저널로그를 확인해보면 타임아웃으로 인해 실패한 것을 확인할 수 있다.

Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1537 (n/a) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1540 (n/a) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1541 (n/a) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1542 (n/a) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1543 (n/a) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1544 (boot) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Killing process 1545 (n/a) with signal SIGKILL.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Failed with result 'timeout'.
Oct 17 23:54:06 coveredcare02lv systemd[1]: Failed to start Percona XtraDB Cluster with config /etc/default/mysql.bootstrap.
Oct 17 23:54:06 coveredcare02lv systemd[1]: mysql@bootstrap.service: Consumed 1min 15.669s CPU time.

[Solutions]

MySQL 부트스트랩 설정에서 서비스 시작에 대한 타임아웃을 기본 1분40초로 되어 있던 것을 무제한(TimeoutStartSec=0)으로 변경한다.

부트스트랩 위치

vi /usr/lib/systemd/system/'mysql@.service'

수정 코드 부분

[Service]
TimeoutStartSec=0

부트스트랩을 수정하고, 서비스를 시작한다.

systemctl start mysql@bootstrap.service

2023-10-19 / Sungwook Kang / http://sungwookkang.com

MySQL upgrade, MySQL 업그레이드, MySQL PXC upgrade, MySQL Percona, MySQL Galera Cluster, MySQL 복원, MySQL 마이그레이션

[MySQL] MySQL의 다양한 주석(comment) 방법 살펴보기

SungWookKang — Wed, 18 Oct 2023 16:42:13 +0900

[MySQL] MySQL의 다양한 주석(comment) 방법 살펴보기

l Version : MySQL

MySQL 주석은 데이터베이스 스키마, SQL 쿼리 및 저장 프로시저를 문서화하는데 필수적이다. 특히 주석의 작성은 다른 개발자가 코드의 목적을 이해하는데 도움이 된다.

[한 줄 주석]

한 줄 주석은 한 줄에 주석을 추가하는데 사용된다. MySQL은 두가지 유형의 한 줄 주석을 지원한다.

-- (하이픈 두개) : 두개의 하이픈 뒤에 텍스트는 주석으로 사용되며, 같은 줄에 이어지는 모든 텍스트는 주석으로 처리 된다.

-- This is a single-line comment
SELECT * FROM employees;

# (해시) : 해시 기호를 사용하여 한 줄 주석을 추가할 수 있다. 같은 줄에 이어지는 모든 텍스트는 추석으로 처리된다.

# This is another single-line comment
SELECT * FROM customers;

[여러 줄 주석]

여러 줄 주석을 사용하면 여러 줄에 걸쳐 주석을 추가할 수 있다. MySQL은 두 가지 유형의 여러 줄 주석을 지원한다. 여러 줄 주석은 /* … */ 기호를 사용하며, 열기(/*)와 닫기(*/) 사이의 모든 내용은 주석으로 처리 된다.

/* This is a
multi-line comment */
SELECT * FROM orders;

[실행 가능한 주석]

MySQL에서 실행 가능한 주석은 다른 데이터베이스 간의 이식성을 지원한다. 이러한 주석을 사용하면 MySQL에서만 실행되고 다른 데이터베이스에서는 실행되지 않는 SQL 코드를 포함할 수 있다. 아래는 실행 가능한 주석 구문을 작성하는 규칙이다.

/*! MySQL-specific code */

예를들어 아래 구문은 실행 가능한 주석을 사용하여 결과가 1이 아닌 2가 반환된다. 그러나 다른 데이터베이스 시스템에서 실행하면 1이 반환된다.

SELECT 1 /*! +1 */

특정 버전의 MySQL에서만 주석을 실행하려면 아래 구문을 사용한다. ##### 문자열은 해당 주석을 실행할 수 있는 MySQL의 최소 버전을 나타낸다.

/*!##### MySQL-specific code */

첫번째 #은 주 버전을 나타내며(예 : 5 또는 8), 두 번째 2개의 ##은 부 버전이다. 그리고 마지막 2개 ##은 패치 수준이다. 아래 스크립트는 MySQL 8.0.33-25.1에서 실행하였으며, 주석에 기입되어 있는 최소버전에 따라 실행 여부가 달라지는 것을 확인할 수 있다.

SELECT 1 /*!80110 +1 */;

SELECT 1 /*!80010 +1 */;

2023-10-18 / Sungwook Kang / http://sungwookkang.com

MySQL Comment, MySQL 주석, 데이터베이스 주석, MySQL 실행 가능한 주석, MySQL 버전에 따른 주석 처리

[MySQL] MySQL(mariadb) Galera Cluster 장애 시나리오에 따른 다양한 복구 방법

SungWookKang — Tue, 17 Oct 2023 09:27:01 +0900

[MySQL] MySQL(mariadb) Galera Cluster 장애 시나리오에 따른 다양한 복구 방법

l Version : MySQL(mariadb) Galera Cluster

Galera Cluster는 동기 복제를 사용하여 데이터를 복제하는 MySQL, MariaDB용 다중 마스터 클러스터이다. Galera Cluster를 사용하면 클러스터의 모든 노드가 마스터 역할을 하고 한 번에 모든 노드에 쓸 수 있다. Galera Cluster의 Active-Active 구성은 장애 조치가 없기 때문에 더 많은 로드 밸런싱과 내결함성을 제공한다.

l MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기 : https://sungwookkang.com/entry/MySQLMariaDB-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-%EB%8B%A4%EC%A4%91-%EB%A7%88%EC%8A%A4%ED%84%B0-%EB%B3%B5%EC%A0%9C%EB%A5%BC-%EC%A7%80%EC%9B%90%ED%95%98%EB%8A%94-Galera-Cluster-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

일단 구성되면 Galera Cluster는 큰 문제없이 작동할 수 있지만 여러 노드 오류로 인해 클러스터가 비정상적인 상황이 발생할 수 있다. 노드가 클러스터와의 통신이 되지 않으면 실패한 노드로 간주되는데, 하드웨어, 네트워크, 소프트웨어 오류 및 일반적인 사용자 실수로도 클러스터가 중단될 수 있다. 그래도 다행인 것은 하나라도 정상적인 노드가 있으면 클러스터 서비스의 연속성이 유지되어 데이터 손실이 발생하지 않는다. 이번 포스트에서는 Galera Cluster에서 장애가 발생하였을 때 클러스터를 복구하는 방법에 대해서 다뤄 본다.

클러스터 장애는 크게 세 가지 시나리오로 분류할 수 있다.

l 단일 노드 오류 (Single node failure)

l 다중 노드 오류 (Multi-node failure)

l 전체 클러스터 오류 (Full cluster failure)

이 중에 전체 클러스터 장애는 데이터베이스 연결이 완전히 끊어진 것으로 실제 장애 상황일수도 있으며, 일반 상황으로는 의도적으로 업데이트 및 정기 유지 관리로 인해 노드를 다시 시작하는 경우이다. 일반적인 상황에서는 노드가 정상적으로 재부팅 되면 클러스터에 다시 참여하고 클러스터의 나머지 부분과 동기화 된다. 노드가 재부팅 되는 동안 클러스터 상태에서 특정 노드가 누락되는 것은 정상적인 현상이고 이런 경우에는 클러스터 장애로 간주되지 않는다.

[정상 클러스터 확인]

장애가 발생했을 때 클러스터 상태를 신속하게 확인할 수 있도록 Galera Cluster가 정상인지 확인하는 방법을 아는 것이 중요하다. 아래 스크립트를 실행하면 현재 클러스터에 연결된 노드의 IP를 확인할 수 있다. 3개 노드로 구성된 정상 Galera Cluster는 데이터베이스 셸에서 다음과 같이 3개의 IP 목록이 표시된다.

show status like 'wsrep_incoming_addresses';

현재 클러스터 구성의 총 노드 수를 확인하려면 아래 스크립트를 실행한다. 전체 노드수와 현재 활성중인 노드수가 다르다면 일부 서버가 클러스터에서 제외된 상태로 확인이 필요하다.

show status like 'wsrep_cluster_size';

클러스터의 UUID를 검색하려면 아래 스크립트를 실행한다.

show status like 'wsrep_cluster_state_uuid';

멤버 노드가 클러스터와 동기화되었는지 확인하려면 아래 스크립트를 실행한다. Synced 라고 표시되면 정상이다.

show status like 'wsrep_local_state_comment';

[단일 노드 오류 복구]

이 시나리오에서는 클러스터의 노드 중 하나의 노드만 실패한 경우로, 데이터가 손실되거나 데이터베이스 연결이 중단되지는 않는다. 아래 스크립트를 실행하여 클러스터 정보를 조회하면 실패한 노드의 정보가 제외되고 활성중인 노드의 목록이 출력된다.

show status like 'wsrep_incoming_addresses';

mysql> show status like 'wsrep_incoming_addresses';
+--------------------------+-------------------------------+
| Variable_name | Value |
+--------------------------+-------------------------------+
| wsrep_incoming_addresses | 10.0.0.51:3306,10.0.0.52:3306 |
+--------------------------+-------------------------------+

클러스터에 참여한 노드 수에도 현재 장애가 발생한 노드 수를 제외하고 표시된다.

show status like 'wsrep_cluster_size';

mysql> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 2 |
+--------------------+-------+

실패한 노드를 복구하는 방법은 문제 해결 후 다시 클러스터에 조인하는 것이다. 간단한 문제의 경우 서비스 재시작으로 해결된다. MySQL 서비스를 시작하여 클러스터에 다시 조인되었는지 확인한다. 어떤 이유로든 다시 참여하지 못한 경우 MySQL(MariaDB)를 다시 시작한다.

$ systemctl restart mysql

[다중 노드 오류 복구]

이 시나리오에서는 하나를 제외한 모든 노드가 실패하여 쿼럼이 손실된 상태이다. 이 단계에서는 Galera Cluster가 더 이상 SQL 요청을 처리할 수 없다. 하지만 하나의 노드가 계속 실행 중이므로 데이터가 손실되지는 않는다. 그러나 실패한 노드가 다시 온라인 상태가 되면 클러스터가 존재하지 않기 때문에 클러스터에 다시 참여할 수 없다. 살아남은 노드에서 클러스터 크기 및 클러스터 상태 명령을 사용하여 이를 확인할 수 있다.

show status like 'wsrep_cluster_size';

+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 1 |
+--------------------+-------+

show status like 'wsrep_cluster_status';

+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+

드문 경우지만 클러스터 상태 값이 non-Primary 로 표시될 수 있다. 이러한 오류는 쿼럼 손실뿐 아니라 네트워크 연결 손실일 수도 있다. 쿼럼 달성을 진행하기 전에 노드 클러스터 상태가 기본 값을 반환하는지 확인한다.

쿼럼 달성을 진행하기 전에 살아남은 노드에 실제로 최신 커밋이 있는지 확인해야 한다. 다른 노드가 클러스터에 다시 참여할 수 있도록 쿼럼을 재설정할 수 있는데, 자동과 수동으로 2가지 방법이 있다.

Automatic Bootstrap

쿼럼을 재설정하는 가장 간단한 방법은 자동 부트스트랩을 사용하는 것이다. 데이터베이스 셸에서 다음 명령을 실행하여 노드를 자동 부트스트랩 할 수 있다. 그러면 살아남은 노드가 기본 시작 노드가 되도록 부트스트랩 되므로 실패한 다른 노드가 클러스터에 다시 참여할 수 있다.

set global wsrep_provider_options='pc.bootstrap=YES';

Manual Bootstrap

다음 명령을 실행하여 노드를 수동으로 부트스트랩 한다. 기본 노드가 실행되면 나머지 모든 노드에서 한 번에 하나씩MySQL(mariadb) 서비스를 다시 시작한다.

$ systemctl stop mysql
$ galera_new_cluster
$ systemctl restart mysql

[전체 클러스터 장애 복구]

이 시나리오에서는 모든 노드가 실패했거나 정상적으로 종료되지 않은 경우이다. 전체 쿼럼 손실이 발생했으며 클러스터가 SQL 요청을 수락하지 않는다. 이와 같은 심각한 장애가 발생한 후 모든 노드가 다시 온라인 상태가 되더라도 MySQL(mariadb) 서비스를 시작할 수 없다. 이는 비정상적으로 종료되어 어떤 노드도 마지막 커밋을 수행할 수 없었기 때문이다. Galera Cluster는 다양한 방식으로 장애가 발생될 수 있으며 이로 인해 전체 장애를 복구하는 방법도 다양하다.

가장 높은 seqno 값을 기반으로 한 복구

이 방법은 클러스터 중에 하나 이상의 노드가 정상적으로 종료될 가능성이 약간이라도 있는 경우 사용할 수 있다. 최신 데이터를 가진 노드는 장애가 발생한 클러스터의 모든 노드 중에서 가장 높은 seqno 값을 갖게 된다. /var/lib/mysql/grastate.datseqno의 내용을 확인해보면 seqno 값을 보여주는 내용에서 단서를 찾을 수 있다. 장애 성격에 따라 모든 노드가 동일한 음수의 seqno 값을 갖거나 노드 중 하나가 가장 높은 양수의 seqno 값을 갖게 된다.

다음은 노드3의 grastate.dat 내용이다. 이 노드에는 음수의 seqno가 있고 그룹 ID(uuid)정보가가 없다. DDL(데이터 정의 언어) 처리 중에 노드 장애가 발생한 경우이다.

$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 00000000-0000-0000-0000-000000000000
seqno: -1
safe_to_bootstrap: 0

다음은 노드2의 grastate.dat 내용이다. 이 노드는 트랜잭션 처리 중에 장애가 발생하여 seqno가 음수이지만 그룹 ID(uud) 정보를 가지고 있다.

$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 886dd8da-3d07-11e8-a109-8a3c80cebab4
seqno: -1
safe_to_bootstrap: 0

다음은 노드1의 grastate.dat 내용이다. seqno 값이 가장 높은 것을 확인할 수 있다. (물론 사용자 노드마다 가장 높은 seqno의 노드는 다를 것이다.) 노드가 정상적으로 종료될 수 있을 때 노드는 양수로 가장 높은 seqno 값을 갖게 된다. 이 경우 먼저 복구해야 할 노드이다.

$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 886dd8da-3d07-11e8-a109-8a3c80cebab4
seqno: 31929
safe_to_bootstrap: 1

모든 노드의 seqno 값이 -1, safe_to_bootstrap 값이 0으로 되어 있는 경우전체 클러스터 장애가 발생했음을 나타낸다. 이 시점에서 galera_new_cluster 명령을 사용하여 클러스터를 새로 생성하여 시작할 수 있다. 그러나 각 노드가 동일한 데이터베이스 데이터 복사본을 가지고 있는지 알 수 있는 방법이 없으므로 권장하지 않는다.

노드 1을 다시 시작하기 전에 클러스터 구성 파일 (/etc/my.cnf.d/server.cnf)를 변경하여 클러스터 노드의 IP에 대한 정보를 제거해야 한다. 다음은 변경 전 구성의 [galera] 섹션 내용이다.

[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.0.0.51,10.0.0.52,10.0.0.53"
wsrep_cluster_name='galeraCluster01'
wsrep_node_address='10.0.0.51'
wsrep_node_name='galera-01'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

wsrep_cluster_address모든 구성원 노드의 IP가 표시된다. 다음과 같이 주소를 제거해야 한다.

wsrep_cluster_address="gcomm://"

이제 이 노드에서 MySQL(mariadb) 서비스를 다시 시작할 수 있다.

$ systemctl restart mysql

서비스가 성공적으로 시작되었는지 확인되었으면, 다른 노드에서 한 번에 하나씩 서비스를 다시 시작할 수 있도록 한다. 모든 노드가 성공적으로 실행되었으면 노드1의 클러스터 구성을 편집하여 모든 구성원 노드의 IP 주소를 추가하고 서비스를 다시 시작한다.

wsrep_cluster_address="gcomm://10.8.8.53,10.8.8.54,10.8.8.55"

이 시점에서는 Galera Cluster가 실행 중이어야 하며 모든 노드는 활성중인 노드와 동기화 되어야 한다.

마지막 커밋을 기준으로 복구

이는 모든 노드가 완전히 중단되어 seqno 값이 -1이 되는 Galera Cluster 장애의 최악의 시나리오이다. 이 경우에는 앞서 언급한 것처럼 노드에서 galera_new_cluster 명령을 실행한 다음 나머지 노드를 클러스터에 다시 연결하는 방식을 실행할 경우, 새로운 ID 세트로 새 클러스터가 생성되고 다른 모든 노드가 여기에 합류하여 완전한 동기화를 시작하기 때문에 데이터가 손실될 수 있다.

마지막 커밋이 있는 노드를 확인하려면 각 노드에서 wsrep_last_commit 값을 개별적으로 확인할 수 있다. 가장 높은 값을 가진 노드는 가장 최근에 커밋된 노드이다. 가장 높은 커밋 값을 가진 노드를 부트스트랩하여 클러스터를 시작한 다음 다른 구성원들은 클러스터 노드에 합류할 수 있다. 이 프로세스는 이전 섹션에서 본 것처럼 가장 높은 seqno를 가진 노드를 부트스트래핑하는 것과 유사하다.

모든 노드의 MySQL(mariadb) 서비스를 중지한다.

$ systemctl stop mariadb

/etc/my.cnf.d/server.cnf의 [galera] 섹션에서 wsrep_cluster_address를 편집하여 멤버 노드에 대한 정보를 제거한다.

wsrep_cluster_address="gcomm://"

MySQL(mariadb) 서비스를 시작한다.

$ systemctl start mariadb

데이터베이스 셸에서 마지막으로 커밋된 값을 확인한다.

mysql> show status like 'wsrep_last_committed';
+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| wsrep_last_committed | 319589 |
+----------------------+---------+

모든 노드에서 마지막으로 커밋된 값을 확인한다. 최신 데이터를 가진 노드가 가장 높은 값을 갖게 된다. 커밋된 값이 가장 높은 노드에서 새 클러스터를 만든다.

$ galera_new_cluster

wsrep_cluster_address 나머지 노드의 값을 변경하여 IP 주소를 추가한 다음 한 번에 한 노드씩 MySQL(mariadb) 서비스를 다시 시작한다. 클러스터가 실행 중이어야 하며 데이터 동기화가 모든 변경 사항을 커밋해야 한다. 잠시 후 모든 노드에서 마지막으로 커밋된 값을 확인하여 노드가 현재 동기화되어 있는지 확인한다.

[참고자료]

l How To Recover MariaDB Galera Cluster After Partial or Full Crash : https://www.symmcom.com/docs/how-tos/databases/how-to-recover-mariadb-galera-cluster-after-partial-or-full-crash

2023-10-17 / Sungwook Kang / http://sungwookkang.com

MySQL Galera Cluster, 갈레라 클러스터, MySQL PXC, 클러스터 장애 복구, 갈레라 클러스터 복구, Recovery Galera Cluster

[MySQL] MySQL 오류 로그 이해

SungWookKang — Mon, 16 Oct 2023 11:41:15 +0900

[MySQL] MySQL 오류 로그 이해

l Version : MySQL

시스템을 운영할 때, 오류를 완벽히 피하기는 거의 불가능에 가깝다고 생각한다. 그렇다면 문제가 발생하였을 때, 문제의 원인을 빠르게 파악하고 해결하기 위해서 가장 먼저 하는 행동은 무엇일까? 정답은 각종 로그를 확인하는 것이다. 이번 포스트에서는 MySQL 오류 로그를 통해 어떠한 정보를 확인할 수 있는지 알아본다. 이 글에서는 오류 로그는 5.6버전을 설명하고 있지만, 이후 버전에서도 충분히 활용할 수 있다고 판단된다. 모든 오류 내용을 다루지는 않지만 예제에서 확인할 수 있는 몇 가지 정보를 공유한다.

MySQL 오류 로그에는 MySQL 상태 및 활동과 관련한 다양한 정보가 기록되어 있다. 정상적인 MySQL 시작, 종료에 대한 기록 및 운영 중에 발생하는 오류들, 그리고 설정 문제로 인한 오류 등 다양한 문제에 대한 정보를 포함하고 있다.

MySQL오류 로그는 일반적은 경우 아래 위치에 기록된다.

/var/log/mysql/error.log

만약 해당 위치에 로그 파일이 없다면 my.cnf 에서 log_error 파라메터의 정의된 위치에서 오류 로그가 기록되는 것을 확인할 수 있다.

[Error log on MySQL – clean startup and shutdown]

MySQL의 클린 스타트가 어떻게 시작되는지 알아본다. 정상적인 상태를 알고 있다면, 나중에 이상징후가 있을 때 좀 더 쉽게 문제를 찾을 수 있다. MySQL이 시작될 때 처음에는 모든 플러그인이 시작된다. 잘못된 경우 이 단계에서 오류가 표시된다.

2015-10-26 19:35:20 13762 [Note] Plugin 'FEDERATED' is disabled.

다음으로 InnoDB 초기화와 관련된 중요한 부분을 볼 수 있다.

2015-10-26 19:35:20 13762 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-10-26 19:35:20 13762 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-26 19:35:20 13762 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-26 19:35:20 13762 [Note] InnoDB: Memory barrier is not used
2015-10-26 19:35:20 13762 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-10-26 19:35:20 13762 [Note] InnoDB: Using Linux native AIO
2015-10-26 19:35:20 13762 [Note] InnoDB: Using CPU crc32 instructions
2015-10-26 19:35:20 13762 [Note] InnoDB: Initializing buffer pool, size = 512.0M
2015-10-26 19:35:21 13762 [Note] InnoDB: Completed initialization of buffer pool
2015-10-26 19:35:21 13762 [Note] InnoDB: Highest supported file format is Barracuda.
2015-10-26 19:35:21 13762 [Note] InnoDB: 128 rollback segment(s) are active.
2015-10-26 19:35:21 13762 [Note] InnoDB: Waiting for purge to start
2015-10-26 19:35:21 13762 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence number 710963181

다음 단계에서는 인증 플러그인이 시작된다.

2015-10-26 19:35:21 13762 [Note] RSA private key file not found: /var/lib/mysql//private_key.pem. Some authentication plugins will not work.
2015-10-26 19:35:21 13762 [Note] RSA public key file not found: /var/lib/mysql//public_key.pem. Some authentication plugins will not work.

마지막에는 구성된 IP 및 포트에 MySQL을 바인딩하는 방법에 대한 정보가 표시된다. 이벤트 스케줄러도 초기화 된다. 마지막으로 MySQL이 올바르게 시작되었음을 나타내는 ‘ready for connections’ 메시지가 표시된다.

2015-10-26 19:35:21 13762 [Note] Server hostname (bind-address): '*'; port: 33306
2015-10-26 19:35:21 13762 [Note] IPv6 is available.
2015-10-26 19:35:21 13762 [Note] - '::' resolves to '::';
2015-10-26 19:35:21 13762 [Note] Server socket created on IP: '::'.
2015-10-26 19:35:21 13762 [Warning] 'proxies_priv' entry '@ root@ip-172-30-4-23' ignored in --skip-name-resolve mode.
2015-10-26 19:35:21 13762 [Note] Event Scheduler: Loaded 2 events
2015-10-26 19:35:21 13762 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.26-74.0' socket: '/var/run/mysqld/mysqld.sock' port: 33306 Percona Server (GPL), Release 74.0, Revision 32f8dfd

종료 프로세스의 경우 아래와 같은 로그가 기록된다. 이 메시지의 내용은 종료하는데 있어서 매우 중요한 정보를 나타낸다.

2015-10-26 19:35:13 12955 [Note] /usr/sbin/mysqld: Normal shutdown

MySQL은 다양한 방법으로 중지될 수 있다. 사용자는 init 스크립트를 사용할 수 있고, ‘mysqladmin’을 사용하여 SHUTDOWN 명령을 실행할 수 있으며, 데이터베이스 종료를 시작하는 SIGTERM을 MySQL로 보낼 수도 있다. MySQL 인스턴스가 종료된 원인을 조사할 경우 이러한 메시지는 항상 누군가(또는 무언가) 완전한 종료를 실행했음을 나타난다.

아래 메시지는 크래시가 발생하지도 않았으며 MySQL도 종료되지 않았다. MySQL은 나머지 연결을 닫고 강제로 종료한다.

2015-10-26 19:35:13 12955 [Note] Giving 12 client threads a chance to die gracefully
2015-10-26 19:35:13 12955 [Note] Event Scheduler: Purging the queue. 2 events
2015-10-26 19:35:13 12955 [Note] Shutting down slave threads
2015-10-26 19:35:15 12955 [Note] Forcefully disconnecting 6 remaining clients
2015-10-26 19:35:15 12955 [Warning] /usr/sbin/mysqld: Forcing close of thread 37 user: 'cmon'
2015-10-26 19:35:15 12955 [Warning] /usr/sbin/mysqld: Forcing close of thread 53 user: 'cmon'
2015-10-26 19:35:15 12955 [Warning] /usr/sbin/mysqld: Forcing close of thread 38 user: 'cmon'
2015-10-26 19:35:15 12955 [Warning] /usr/sbin/mysqld: Forcing close of thread 39 user: 'cmon'
2015-10-26 19:35:15 12955 [Warning] /usr/sbin/mysqld: Forcing close of thread 44 user: 'cmon'
2015-10-26 19:35:15 12955 [Warning] /usr/sbin/mysqld: Forcing close of thread 47 user: 'cmon'

그리고 MySQL에서는 활성화된 모든 플러그인을 종료한다.

2015-10-26 19:35:15 12955 [Note] Binlog end
2015-10-26 19:35:15 12955 [Note] Shutting down plugin 'partition'
2015-10-26 19:35:15 12955 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'
2015-10-26 19:35:15 12955 [Note] Shutting down plugin 'ARCHIVE'
...

아래 내용은 종료되는 플러그인 중 InnoDB에 관한 것으로 빠른 종료가 활성화된 상태에서도 바쁜 서버에서는 완전한 InnoDB 종료에 시간이 걸릴 수 있다.

2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'MyISAM'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'MRG_MYISAM'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'CSV'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'MEMORY'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'sha256_password'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'mysql_old_password'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'mysql_native_password'
2015-10-26 19:35:17 12955 [Note] Shutting down plugin 'binlog'
2015-10-26 19:35:17 12955 [Note] /usr/sbin/mysqld: Shutdown complete

종료 프로세스는 ‘Shutdown complete’라는 메시지와 함께 종료된다.

[Configuration errors]

my.cnf를 편집하는 과정에서 변수명에 대한 오타 또는 설정에 대한 리밋값 오류가 있을 수 있다. MySQL은 시작될 때, 구성 파일을 구문 분석한다. 오류가 발생하면 실행이 거부된다.

2015-10-27 11:20:05 18858 [Note] Plugin 'FEDERATED' is disabled.
2015-10-27 11:20:05 18858 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-10-27 11:20:05 18858 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-27 11:20:05 18858 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-27 11:20:05 18858 [Note] InnoDB: Memory barrier is not used
2015-10-27 11:20:05 18858 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-10-27 11:20:05 18858 [Note] InnoDB: Using Linux native AIO
2015-10-27 11:20:05 18858 [Note] InnoDB: Using CPU crc32 instructions
2015-10-27 11:20:05 18858 [Note] InnoDB: Initializing buffer pool, size = 512.0M
2015-10-27 11:20:05 18858 [Note] InnoDB: Completed initialization of buffer pool
2015-10-27 11:20:05 18858 [Note] InnoDB: Highest supported file format is Barracuda.
2015-10-27 11:20:05 18858 [Note] InnoDB: 128 rollback segment(s) are active.
2015-10-27 11:20:05 18858 [Note] InnoDB: Waiting for purge to start
2015-10-27 11:20:06 18858 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence number 773268083
2015-10-27 11:20:06 18858 [ERROR] /usr/sbin/mysqld: unknown variable '--max-connections=512'
2015-10-27 11:20:06 18858 [ERROR] Aborting

위 로그를 살펴보면 max_connections 변수와 관련하여 변수에 대한 오타가 있음을 확인할 수 있다. MySQL은 my.cnf에서 ‘-‘ 접두사를 허용하지 않음으로 ‘ps’ 출력 또는 MySQL 설명서에서 설정을 복사하는 경우 이 부분을 주의하기 바란다.

아래 내용은 변수 오타가 아닌 잘못된 구성의 문제로, 서버에 메모리를 과도하게 할당했을 때 발생한 오류이다.

2015-10-27 11:24:41 31325 [Note] Plugin 'FEDERATED' is disabled.
2015-10-27 11:24:41 31325 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-10-27 11:24:41 31325 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-27 11:24:41 31325 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-27 11:24:41 31325 [Note] InnoDB: Memory barrier is not used
2015-10-27 11:24:41 31325 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-10-27 11:24:41 31325 [Note] InnoDB: Using Linux native AIO
2015-10-27 11:24:41 31325 [Note] InnoDB: Using CPU crc32 instructions
2015-10-27 11:24:41 31325 [Note] InnoDB: Initializing buffer pool, size = 512.0G
InnoDB: mmap(70330089472 bytes) failed; errno 12
2015-10-27 11:24:41 31325 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2015-10-27 11:24:41 31325 [ERROR] Plugin 'InnoDB' init function returned error.
2015-10-27 11:24:41 31325 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2015-10-27 11:24:41 31325 [ERROR] Unknown/unsupported storage engine: InnoDB
2015-10-27 11:24:41 31325 [ERROR] Aborting

메시지를 살펴보면 이 호스트에서 불가능했던 512G의 메모리를 할당하려고 시도하였고 오류가 발생한 것을 확인할 수 있다. MySQL을 시작하려면 InnoDB가 필요한데, InnoDB 초기화 오류로 인해 MySQL이 시작되지 않았다.

[Permission errors]

아래 로그를 살펴보면 MySQL은 ‘permission denied’ 오류로 인해 바이너리 로그에 대한 인덱스 파일을 찾을 수 없다. 이 경우 MySQL의 하드 스톱 원인 이기도 하다. 바이너리 로그를 읽고 쓸 수 있어야 한다.

/usr/sbin/mysqld: File './binlog.index' not found (Errcode: 13 - Permission denied)
2015-10-27 11:31:40 11469 [ERROR] Aborting

아래 메시지는 또 다른 권한 문제로 ibdata1 파일과 관련되어 있다. 이는 InnoDB가 내부 데이터(InnoDB 사전 및 기본적으로 실행 취소 로그)를 저장하는데 사용되는 공유 시스템 테이블 스페이스이다. MySQL 5.6의 기본 설정인 innodb_file_per_table을 사용하더라도 InnoDB에서는 초기화를 위해 이 파일이 필요하다.

2015-10-27 11:32:46 13601 [Note] Plugin 'FEDERATED' is disabled.
2015-10-27 11:32:46 13601 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-10-27 11:32:46 13601 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-27 11:32:46 13601 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-27 11:32:46 13601 [Note] InnoDB: Memory barrier is not used
2015-10-27 11:32:46 13601 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-10-27 11:32:46 13601 [Note] InnoDB: Using Linux native AIO
2015-10-27 11:32:46 13601 [Note] InnoDB: Using CPU crc32 instructions
2015-10-27 11:32:46 13601 [Note] InnoDB: Initializing buffer pool, size = 512.0M
2015-10-27 11:32:46 13601 [Note] InnoDB: Completed initialization of buffer pool
2015-10-27 11:32:46 13601 [ERROR] InnoDB: ./ibdata1 can't be opened in read-write mode
2015-10-27 11:32:46 13601 [ERROR] InnoDB: The system tablespace must be writable!
2015-10-27 11:32:46 13601 [ERROR] Plugin 'InnoDB' init function returned error.
2015-10-27 11:32:46 13601 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2015-10-27 11:32:46 13601 [ERROR] Unknown/unsupported storage engine: InnoDB
2015-10-27 11:32:46 13601 [ERROR] Aborting

아래 로그는 시스템 스키마(mysql 스키마)와 관련된 권한 문제이다. 로그를 보면 InnoDB는 이 스키마에서 테이블을 열 수 있는 액세스 권한이 없다고 표시한다. 이경우 MySQL이 멈추게 되며 심각한 문제임을 알 수 있다.

015-10-27 11:35:21 17826 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13 - Permission denied)
2015-10-27 11:35:21 17826 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
2015-10-27 11:35:21 17826 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-10-27 11:35:21 17826 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-27 11:35:21 17826 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-27 11:35:21 17826 [Note] InnoDB: Memory barrier is not used
2015-10-27 11:35:21 17826 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-10-27 11:35:21 17826 [Note] InnoDB: Using Linux native AIO
2015-10-27 11:35:21 17826 [Note] InnoDB: Using CPU crc32 instructions
2015-10-27 11:35:21 17826 [Note] InnoDB: Initializing buffer pool, size = 512.0M
2015-10-27 11:35:21 17826 [Note] InnoDB: Completed initialization of buffer pool
2015-10-27 11:35:21 17826 [Note] InnoDB: Highest supported file format is Barracuda.
2015-10-27 11:35:21 7fa02e97d780 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
2015-10-27 11:35:21 17826 [ERROR] InnoDB: Could not find a valid tablespace file for 'mysql/innodb_index_stats'. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2015-10-27 11:35:21 17826 [ERROR] InnoDB: Tablespace open failed for '"mysql"."innodb_index_stats"', ignored.
2015-10-27 11:35:21 7fa02e97d780 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
2015-10-27 11:35:21 17826 [ERROR] InnoDB: Could not find a valid tablespace file for 'mysql/innodb_table_stats'. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2015-10-27 11:35:21 17826 [ERROR] InnoDB: Tablespace open failed for '"mysql"."innodb_table_stats"', ignored.
2015-10-27 11:35:21 7fa02e97d780 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.

[Out of memory errors]

MySQL 서버의 메모리 부족과 관련된 또 다른 자주 발생하는 문제로, 다양하게 나타나지만 가장 흔하게 접하게 되는 메시지는 아래와 같다.

Killed
151027 12:18:58 mysqld_safe Number of processes running now: 0

mysqld_safe는 mysqld를 모니터링하고 종료되면 다시 시작하는 ‘angel’ 프로세스이다. MySQL에는 해당되지만 Galera 노드에서는 해당되지 않는다. 이 경우 MySQL을 다시 시작하지는 않지만 다음 순서가 표시된다.

Killed
151027 12:18:58 mysqld_safe Number of processes running now: 0
151027 12:18:58 mysqld_safe WSREP: not restarting wsrep node automatically
151027 12:18:58 mysqld_safe mysqld from pid file /var/lib/mysql/mysql.pid ended

메모리 문제가 나타날 수 있는 또 다른 방법은 오류 로그의 다음 메시지를 통해서이다.

InnoDB: mmap(3145728 bytes) failed; errno 12
InnoDB: mmap(3145728 bytes) failed; errno 12

이 경우 ‘perror’ 유틸리티를 사용하여 오류 코드를 확인하면, 정확히 무슨 일이 일어났는지 알 수 있다.

$ perror 12
OS error code 12: Cannot allocate memory

메모리 문제가 의심되거나 예상치 못한 MySQL 크래시가 발생하는 경우 dmesg를 실행하여 더 많은 데이터를 얻을 수도 있다. 아래와 같은 출력이 표시되면 OOM Killer가 MySQL을 종료하여 문제가 발생한 것임을 확인할 수 있다.

[ 4165.802544] Out of memory: Kill process 8143 (mysqld) score 938 or sacrifice child
[ 4165.808329] Killed process 8143 (mysqld) total-vm:5101492kB, anon-rss:3789388kB, file-rss:0kB
[ 4166.226410] init: mysql main process (8143) killed by KILL signal
[ 4166.226437] init: mysql main process ended, respawning

[InnoDB crashes]

대부분의 경우 InnoDB는 매우 견고하고 내구성이 뛰어난 스토리지 엔진이다. 하지만 어떤 상황에서는 데이터가 손상될 수 있다. 일반적으로 잘못된 구성(예: 이중 쓰기 버퍼 비활성화) 또는 일종의 하드웨어 결함(메모리 모듈 결함, 불안정한 I/O 계층)과 관련이 있다. 이러한 경우 InnoDB가 크래시 될 수 있다. InnoDB 버그로 인해서도 크래시가 발생할 수도 있다. 흔한 일은 아니지만 가끔씩 발생한다. 크래시 원인에 관계없이 오류 로그는 일반적으로 비슷한 방식으로 표시된다. 실제 사례를 살펴보자.

2015-10-13 15:08:06 7f53f0658700 InnoDB: Assertion failure in thread 139998492198656 in file btr0pcur.cc line 447
InnoDB: Failing assertion: btr_page_get_prev(next_page, mtr) == buf_block_get_page_no(btr_pcur_get_block(cursor))

InnoDB 코드는 온전성 검사로 가득 차 있다. 어설션은 매우 빈번하며, 그 중 하나가 실패하면 InnoDB는 의도적으로 MySQL을 크래시 시킨다. 처음에는 실패한 어설션의 정확한 위치에 대한 정보가 표시된다. 이는 정확히 무슨 일이 일어났는지에 대한 정보를 제공한다. MySQL 소스 코드는 인터넷에서 확인할 수 있으며 특정 버전과 관련된 코드를 다운로드하는 것은 매우 쉽다. MySQL 코드는 적절하게 문서화되어 있으며 최소한 어떤 종류의 활동이 문제를 유발하는지 파악하는 것은 문제가 되지 않는다.

InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

InnoDB 로깅 정보에는 InnoDB 복구 프로세스에 대한 정보가 있다. 어떤 상황에서는 MySQL을 시작하고 InnoDB 데이터를 덤프할 수 있다. 이는 "거의 최후의 수단"으로 사용된다. 한 단계 더 나아가면 16진수 편집기를 사용하여 InnoDB 파일을 파헤치게 된다.

13:08:06 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=67108864
read_buffer_size=131072
max_used_connections=36
max_threads=514
thread_count=27
connection_count=26
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 269997 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

다음 단계에서는 일부 상태 카운터가 기록된 것을 볼 수 있다. 이는 구성에 대한 몇 가지 아이디어를 제공할 것으로 예상된다. 너무 많은 리소스를 사용하도록 MySQL을 구성했을 수도 있다. 이 데이터를 검토하면 역추적에 도달하게 된다. 이 정보는 스택을 안내하고 크래시가 발생했을 때 어떤 종류의 호출이 실행되었는지 보여준다. 이 특별한 경우에 정확히 무슨 일이 일어났는지 확인해 보자.

Thread pointer: 0xa985960
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f53f0657d40 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x8cd37c]
/usr/sbin/mysqld(handle_fatal_signal+0x461)[0x6555a1]
/lib64/libpthread.so.0(+0xf710)[0x7f540f978710]
/lib64/libc.so.6(gsignal+0x35)[0x7f540dfd4625]
/lib64/libc.so.6(abort+0x175)[0x7f540dfd5e05]
/usr/sbin/mysqld[0xa0277b]
/usr/sbin/mysqld[0x567f88]
/usr/sbin/mysqld[0x99afde]
/usr/sbin/mysqld[0x8eb926]
/usr/sbin/mysqld(_ZN7handler11ha_rnd_nextEPh+0x5d)[0x59a6ed]
/usr/sbin/mysqld(_Z13rr_sequentialP11READ_RECORD+0x20)[0x800cd0]
/usr/sbin/mysqld(_Z12mysql_deleteP3THDP10TABLE_LISTP4ItemP10SQL_I_ListI8st_orderEyy+0xc88)[0x8128c8]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x1bc5)[0x6d6d15]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x5a8)[0x6dc228]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x108c)[0x6dda4c]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x162)[0x6ab002]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x6ab0f0]
/usr/sbin/mysqld(pfs_spawn_thread+0x143)[0xaddd73]
/lib64/libpthread.so.0(+0x79d1)[0x7f540f9709d1]
/lib64/libc.so.6(clone+0x6d)[0x7f540e08a8fd]

MySQL이 DELETE 명령을 실행할 때 문제가 발생한 것을 볼 수 있다. 레코드를 순차적으로 읽고 전체 테이블 스캔을 수행했다(handler read_rnd_next).

InnoDB: Failing assertion: btr_page_get_prev(next_page, mtr) == buf_block_get_page_no(btr_pcur_get_block(cursor))

InnoDB가 버퍼 풀 스캔을 수행할 때 충돌이 발생했음을 알 수 있다(btr_pcur_move_to_next_page 메소드에서 어설션이 트리거됨).

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (a991d40): DELETE FROM cmon_stats WHERE cid = 2 AND ts < 1444482484
Connection ID (thread ID): 5
Status: NOT_KILLED

마지막으로 어떤 스레드가 어설션을 트리거했는지 확인할 수 있다(때로는 항상 로깅 되지는 않음). 이 경우에는 실제로 일종의 문제를 일으킨 DELETE 쿼리였음을 확인할 수 있다.

You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
151013 15:08:06 mysqld_safe Number of processes running now: 0

일반적으로 MySQL은 오류 로그와 관련하여 매우 장황하다. 하지만 상황이 너무 잘못되어 MySQL이 실제로 많은 정보를 수집할 수 없는 경우도 있다. 이는 여전히 뭔가 매우 잘못되었다는 매우 명확한 표시를 제공한다(신호 11). 아래 사례를 살펴보자.

22:31:40 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at https://bugs.launchpad.net/percona-xtradb-cluster

key_buffer_size=33554432
read_buffer_size=131072
max_used_connections=10
max_threads=202
thread_count=9
connection_count=7
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 113388 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1fb7050
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Segmentation fault (core dumped)
150119 23:48:08 mysqld_safe Number of processes running now: 0

로그를 살펴보면 MySQL이 크래시 했다는 명확한 정보가 있다. 하지만 추가 정보는 없다. 분할 오류는 진단 메시지에 기록될 수도 있다. 이 특별한 경우 dmesg는 다음을 반환했다.

[370591.200799] mysqld[5462]: segfault at 51 ip 00007fe624e3e688 sp 00007fe4f4099c30 error 4 in libgcc_s.so.1[7fe624e2f000+16000]

많은 내용이 포함된 것은 아니지만 이미 보고된 경우 이러한 정보는 매우 유용할 수 있다. 오류 로그에 기록된 정보만으로 문제를 해결하는 것이 항상 가능한 것은 아니다. 하지만 데이터베이스의 문제 디버깅을 시작하기에는 확실히 좋은 장소이다. 매우 일반적이고 단순한 구성 오류가 발생하는 경우 오류 로그에서 찾을 수 있는 정보만으로도 원인을 찾아내고 해결책을 찾는 데 충분하다. 심각한 MySQL 충돌에 대해 이야기하고 있다면 상황은 확실히 다르다. 대부분의 경우 문제를 스스로 해결할 수 없을 것이다. 반면에 이 데이터는 범인을 식별하고 이를 다루는 기존 버그 보고서를 찾는 데 충분할 수 있다. 이러한 버그 보고서에는 많은 토론과 팁 또는 해결 방법이 포함되어 있다. 아마도 그 중 하나를 구현할 수 있을 것이다. 해당 버그가 xyz 버전에서 수정되었다는 정보도 유용하다. 이를 확인하고 문제가 해결되면 업그레이드 계획을 세울 수 있다. 최악의 경우에는 스스로 버그 보고서를 작성할 수 있을 만큼 충분한 데이터가 있어야 한다.

[참고자료]

l Understanding the MySQL Error Log : https://severalnines.com/blog/understanding-mysql-error-log/

2023-10-11 / Sungwook Kang / http://sungwookkang.com

MySQL, ErrorLog, 오류로그, ErrorMessage, MySQL Error,

[MySQL] ProxySQL 연결이 실패할 때 확인해야 할 기본 체크리스트

SungWookKang — Wed, 11 Oct 2023 10:44:01 +0900

[MySQL] ProxySQL 연결이 실패할 때 확인해야 할 기본 체크리스트

l Version : ProxySQL

MySQL서버를 여러대로 구성해야하는 경우 (예, Replication, Sharding 등) 어플리케이션 수에 따라 MySQL 서버와 맺게 되는 커넥션수가 급격하게 늘어난다. 예를들어 MySQL 서버가 30대, 어플리케이션 서버가 200대이고, 각 서버별로 커넥션을 10개씩 유지한다면 30 * 200 * 10 = 60000 커넥션이 발생한다. 이런 이슈를 피하기 위해 중간에 미들웨어 개념으로 프록시 역할을 해주는 것이 ProxySQL이다. ProxySQL은 효율적인 커넥션 관리뿐만 아니라 라우팅 기능 등 여러 기능을 제공한다.

l ProxySQL 이란 무엇인가 : https://sungwookkang.com/entry/ProxySQL-%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

이번 포스트는 ProxySQL을 운영할 때, 어플리케이션에서 DB 커넥션 관련 오류가 발생할 때 확인해야 하는 체크리스트를 정리하였다. 당연한 말이지만, 막상 트러블이 발생했을 때 어디서부터 확인해야 될지 우왕좌왕 하는 경우가 많다. 해당 순서를 참고하여 빠르게 확인할 수 있도록 한다.

1. ProxySQL 런타임 상태 확인

ProxySQL의 프로세스가 정상적으로 활성화된 상태라도 ProxySQL이 MySQL과 연결이 정상적인지 또는 클러스터에서 제외되지는 않았는지 런타임 상태를 확인한다.

select * from runtime_mysql_servers;

status 항목이 SHUNNED이면 현재 해당 서버와 연결이 끊어진 것으로, 원인을 확인하여 ONLINE상태가 되도록 한다.

2. Ping log를 확인하여, ProxySQL과 MySQL의 연결 상태를 확인한다.

SELECT * FROM monitor.mysql_server_ping_log ORDER BY time_start_us DESC LIMIT 10;

위의 핑 로그에서는 패스워드 관련으로 핑 실패가 발생한 것을 확인할 수 있다.

3. 커넥션 로그를 확인하여 MySQL서버와 연결 상태를 확인한다.

커넥션 로그를 확인하여, 현재 등록된 타겟 서버(노드라고도 부름, mysql_servers 테이블 목록)와의 커넥션 상태를 확인한다.

SELECT * FROM monitor.mysql_server_connect_log ORDER BY time_start_us DESC LIMIT 10;

connect_error 항목이 NULL이 아닐 경우 ProxySQL과 MySQL 연결이 정상적이지 않은 것으로 원인을 찾아 해결할 수 있도록 한다.

4. ProxySQL 오류 로그확인

ProxySQL에 발생하는 각종 로그는 파일로 기록된다. 로그 파일의 위치는 proxysql.cnf에서 확인할 수 있다.

cat /etc/proxysql.cnf

오류 로그를 확인하여 ProxySQL에서 발생하는 다양한 로그를 확인한다.

tail -10 /var/log/proxysql/proxysql-error.log

5. 외부 접근용 계정 확인

ProxySQL을 사용할 경우, 외부 어플리케이션은 MySQL이 아닌 ProxySQL로 연결하게 된다. 이때 외부 어플리케이션이 사용할 ID/PWD가 생성되어 있는지 확인한다.

select * from mysql_users;

6. 모니터링 계정 확인

MySQL 서버에서 ProxySQL이 사용할 모니터링 계정이 정상적으로 등록되어 있는지 확인한다. ProxySQL에서 모니터링으로 사용할 계정은 아래 명령으로 확인할 수 있다. 모니터링이 실패하면 ProxySQL에서는 서버와 통신이상으로 노드에서 제외한다.

SELECT * FROM global_variables WHERE variable_name LIKE 'mysql-monitor_%';

시스템을 운영하다 보면 다양한 오류 환경을 만나게 되는데, 이때 케이스를 해결하는 방법보다, 원인을 파악하는데 오랜 시간이 걸리는 경우가 대부분이다. 케이스에 따른 체크리스트를 잘 만들어 놓으면 긴급 상황에서 많은 도움이 된다.

2023-10-11 / Sungwook Kang / http://sungwookkang.com

ProxySQL, 프록시SQL, 트러블슈팅,ProxySQL 연결오류

[MySQL] MySQL Percona XtraDB Cluster 소개 및 설정 변수 알아보기

SungWookKang — Wed, 27 Sep 2023 14:30:23 +0900

[MySQL] MySQL Percona XtraDB Cluster 소개 및 설정 변수 알아보기

l Version : MySQL Percona 8.X

Percona XtraDB Cluster는 MySQL을 위한 완전한 오픈 소스 고가용성 솔루션으로 MySQL용 Percona Server 및 Percona XtraBackup을 Galera 라이브러리와 통합하여 동기식 다중 소스 복제를 가능하게 한다. Galera 라이브러리에 대한 내용은 아래 링크를 참고한다.

l MySQL Galera Cluster + ProxySQL에서 Galera Cluster 특성을 고려한 R/W 호스트 그룹 설정 하기 : https://sungwookkang.com/entry/MySQL-Galera-Cluster-ProxySQL%EC%97%90%EC%84%9C-Galera-Cluster-%ED%8A%B9%EC%84%B1%EC%9D%84-%EA%B3%A0%EB%A0%A4%ED%95%9C-RW-%ED%98%B8%EC%8A%A4%ED%8A%B8-%EA%B7%B8%EB%A3%B9-%EC%84%A4%EC%A0%95-%ED%95%98%EA%B8%B0

클러스터는 노드로 구성되며, 각 노드에는 노드 전체에 걸쳐 동기화된 동일한 데이터 세트가 포함되어 있다. 권장되는 구성은 3개 이상의 노드를 보유하는 것이지만 2개의 노드를 보유할 수도 있다. 각 노드는 일반 MySQL Server 인스턴스(예: Percona Server)이다. 기존 MySQL Server 인스턴스를 노드로 변환하고 이 노드를 기본으로 사용하여 클러스터를 실행할 수 있다. 클러스터에서 노드를 분리하여 일반 MySQL Server 인스턴스로 사용할 수도 있다.

Percona XtraDB Cluster 장점은 쿼리를 실행하면 노드에서 로컬로 실행된다. 모든 데이터는 로컬에서 사용할 수 있으므로 원격 액세스가 필요하지 않다. 중앙 관리 시스템이 아니므로 언제든지 노드를 유연하게 구성할 수 있으며 클러스터는 데이터 손실 없이 계속 작동한다. 읽기 작업 부하를 확장하는 데 적합한 솔루션이며 모든 노드에 읽기 쿼리를 호출할 수 있다.

단점으로는 노드 프로비저닝의 오버헤드가 있다. 새 노드를 추가하면 기존 노드 중 하나에서 전체 데이터 세트를 복사해야 한다. 예를 들어 노드가 100GB이면 100GB를 복사하는 방식이다. 이러한 특징 때문에 쓰기 확장 솔루션으로는 사용할 수 없다. 전체 트래픽을 1개 노드에 실행하는 경우에 비해 2개 노드에 쓰기 트래픽을 실행하는 경우 쓰기 처리량이 약간 향상될 수 있지만 많은 것을 기대할 수는 없다. 모든 쓰기는 여전히 모든 노드에서 진행되기 때문이다.

Percona XtraDB Cluster 구성요소는 XtraDB 스토리지 엔진으로 실행되는 MySQL용 Percona 서버를 기반으로 하며, Codership Oy에서 개발한 쓰기 세트 복제(wsrep) API의 구현인 Galera 라이브러리를 사용한다. 기본 및 권장 데이터 전송 방법은 Percona XtraBackup을 사용한다.

[XtraDB Cluster제약 사항]

l 복제는 InnoDB 스토리지 엔진에서만 작동한다.

l 다른 유형의 테이블에 대한 쓰기는 복제되지 않는다.

l LOCK TABLES 및 UNLOCK TABLES는 다중 소스 설정에서 지원되지 않는다.

n GET_LOCK(), RELEASE_LOCK() 등과 같은 잠금 함수

l 쿼리 로그를 테이블로 보낼 수 없다. 쿼리 로깅을 활성화하는 경우 로그를 파일로 전달해야 한다. 쿼리 로깅 및 로그 파일 이름을 선택하려면 General_log 및 General_log_file을 사용해야 한다.

log_output = FILE

l 허용되는 최대 트랜잭션 크기는 wsrep_max_ws_rows 및 wsrep_max_ws_size 변수에 의해 정의된다.

l LOAD DATA INFILE 처리는 10,000개 행마다 커밋된다. 따라서 LOAD DATA로 인한 대규모 트랜잭션은 일련의 작은 트랜잭션으로 분할된다.

l COMMIT를 발행하는 트랜잭션은 해당 단계에서 여전히 중단될 수 있다.

l 클러스터 수준의 낙관적 동시성 제어로 인해 동일한 행에 쓰고 별도의 Percona XtraDB 클러스터 노드에서 커밋하는 두 개의 트랜잭션이 있을 수 있으며 그 중 하나만 성공적으로 커밋할 수 있다. 실패한 항목은 중단되며, 클러스터 수준 중단의 경우 Percona XtraDB Cluster는 교착 상태 오류 코드를 반환한다.

(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).

l XA 트랜잭션은 지원되지 않는다. 커밋시 롤백이 가능하기 때문이다.

l 전체 클러스터의 쓰기 처리량은 가장 약한 노드에 의해 제한된다. 한 노드가 느려지면 전체 클러스터도 느려진다.

l 최소 권장 클러스터 크기는 노드 3개이다. 세 번째 노드는 중재자가 될 수 있다.

l enforce_storage_engine=InnoDB는 wsrep_replicate_myisam=OFF와 호환되지 않는다. wsrep_replicate_myisam은 기본적으로 OFF로 설정된다.

l 클러스터 모드에서 Percona XtraDB Cluster를 실행할 때 ALTER TABLE ... IMPORT/EXPORT 워크로드를 가급적 사용하지 않도록 한다. 모든 노드에서 동기화되어 실행되지 않으면 노드 불일치가 발생할 수 있다.

l 모든 테이블에는 기본 키가 있어야 합니다. 이렇게 하면 동일한 행이 다른 노드에서 동일한 순서로 표시된다. 기본 키가 없는 테이블에서는 DELETE 문이 지원되지 않는다.

l 임시 테이블에 영구 테이블 이름을 재사용하지 않도록 한다. MySQL은 영구 테이블과 동일한 이름의 임시 테이블을 허용하지만 이 접근 방식은 권장되지 않는다. Galera Cluster는 이름이 임시 테이블의 이름과 일치하는 영구 테이블의 복제를 차단한다.

l wsrep_debug를 1로 설정하면 오류 로그에 다음 메시지가 포함될 수 있다.

... [Note] WSREP: TO BEGIN: -1, 0 : create table t (i int) engine=innodb
... [Note] WSREP: TO isolation skipped for: 1, sql: create table t (i int) engine=innodb.Only temporary tables affected.

l 버전 8.0.21부터 INPLACE ALTER TABLE 쿼리는 쿼리 실행 중에 테이블에 대한 내부 공유 잠금을 사용한다. 이 변경으로 인해 모든 INPLACE ALTER TABLE 쿼리에 대해 LOCK=NONE 절이 더 이상 허용되지 않는다. 이 변경 사항은 다음 시나리오에서 클러스터 노드가 중단될 수 있는 교착 상태를 해결한다.

n 한 세션에 있거나 TOI(Total Order Isolation)로 적용되는 INPLACE ALTER TABLE 쿼리

n 다른 세션의 동일한 테이블에 있는 DML

n log_bin, log_bin_index 값을 정의할 때 하나 이상의 점 문자(.)를 사용하지 않는다.

n MySQL과 XtraBackup은 서로 다른 방식으로 값을 처리하며 이러한 차이로 인해 예측할 수 없는 동작이 발생한다.

[Percona 버전 번호이해]

버전 번호는 제품 릴리스를 식별한다. 제품에는 해당 릴리스 당시의 최신 GA(일반 출시) 기능이 포함되어 있다.

Percona는 기본 버전, 마이너 빌드 및 선택적 사용자 정의 빌드 패턴을 따르는 의미 체계 버전 번호 지정을 사용한다. Percona는 각 마이너 빌드 릴리스에 대해 음수가 아닌 고유한 정수를 오름차순으로 할당한다. 버전 번호는 필요한 경우 기본 Percona Server for MySQL 버전 번호, 마이너 빌드 버전 및 사용자 정의 빌드 버전을 결합한다.

l Base Version : 기본으로 사용되는 Percona Server for MySQL 버전을 나타내는 가장 왼쪽 숫자 집합으로, 베이스 버전이 이 증가하면 마이너 빌드 버전과 사용자 정의 빌드 버전이 0으로 재설정된다.

l Minor Build : Percona XtraDB 클러스터가 릴리스 될 때마다 증가하는 내부 번호이며 사용자 정의 빌드 번호는 0으로 재설정된다.

l Customer Build : 버그 수정에 사용되는 사용자 정의 빌드에 할당된 선택적 번호이다. 수정 사항에 해당 기능이 포함되지 않는 한 기능은 변경되지 않는다. 예를 들어 Percona XtraDB Cluster 8.0.20-11.1, 8.0.20-11.2 및 8.0.20-11.3은 동일한 Percona Server for MySQL 버전 및 마이너 빌드 버전을 기반으로 하지만 사용자 정의 빌드 버전이다.

[wsrep status variables]

wsrep status variables	Comments
wsrep_apply_oooe	병렬화 효율성, 쓰기가 순서 없이 적용되는 빈도.
wsrep_apply_oool	더 높은 시퀀스 번호를 가진 쓰기 세트가 더 낮은 시퀀스 번호를 가진 쓰기 세트보다 먼저 적용되는 빈도.
wsrep_apply_window	동시에 적용된 최고 및 최저 시퀀스 번호 사이의 평균 거리.
wsrep_causal_reads	wsrep_causal_reads 변수가 ON으로 설정된 동안 처리된 쓰기 세트 수.
wsrep_cert_bucket_count	인증 색인 해시 테이블의 셀 수.
wsrep_cert_deps_distance	병렬로 적용될 수 있는 가장 높은 시퀀스 번호와 가장 낮은 시퀀스 번호 사이의 평균 거리.
wsrep_cert_index_size	인증 색인의 항목 수.
wsrep_cert_interval	트랜잭션이 복제되는 동안 수신된 평균 쓰기 세트 수.
wsrep_cluster_conf_id	발생한 클러스터 멤버십 변경 수.
wsrep_cluster_size	클러스터의 현재 노드 수.
wsrep_cluster_state_uuid	클러스터의 UUID 상태로, 이 값이 wsrep_local_state_uuid의 값과 동일하면 노드가 클러스터와 동기화상태임.
wsrep_cluster_status	클러스터 구성 요소의 상태로 Primary, Non-Primary, Disconnected가 있음.
wsrep_commit_oooe	트랜잭션이 순서 없이 커밋된 빈도.
wsrep_commit_oool	이 변수는 현재 사용하지 않음.
wsrep_commit_window	동시에 커밋된 최고 시퀀스 번호와 최저 시퀀스 번호 사이의 평균 거리.
wsrep_connected	노드가 클러스터에 연결되어 있는지 여부를 표시. 값이 OFF이면 노드가 아직 클러스터 구성 요소에 연결되지 않은 상태로, 이는 잘못된 구성으로 인한 것일 수 있음.
wsrep_evs_delayed	지연된 것으로 간주되는 쉼표로 구분된 노드 목록. 노드 형식은 <uuid>:<address>:<count>로, <count>는 해당 노드에 대한 지연 목록의 항목 수.
wsrep_evs_evict_list	제거된 노드의 UUID 목록.
wsrep_evs_repl_latency	그룹 통신 복제 대기 시간에 관한 정보를 제공. 이 대기 시간은 메시지가 전송된 시점부터 메시지가 수신될 때까지 초 단위로 측정. 출력 형식: <min>/<avg>/<max>/<std_dev>/<sample_size>
wsrep_evs_state	내부 EVS 프로토콜 상태.
wsrep_flow_control_interval	Galera 흐름 제어의 하한 및 상한을 표시. 상한은 대기열에 허용되는 최대 요청 수이며, 대기열이 상한에 도달하면 새 요청이 거부된다. 기존 요청이 처리되면 대기열이 줄어들고, 하한에 도달하면 새 요청이 다시 허용된다.
wsrep_flow_control_interval_high	트리거할 흐름 제어의 상한을 표시.
wsrep_flow_control_interval_low	흐름 제어를 정지하는 하한값을 표시.
wsrep_flow_control_paused	흐름 제어로 인해 일시 중지된 마지막 상태 쿼리 이후의 시간.
wsrep_flow_control_paused_ns	일시 중지된 상태에서 소요된 총 시간은 나노초 단위로 측정.
wsrep_flow_control_recv	마지막 상태 쿼리 이후 수신된 FC_PAUSE 이벤트 수. 대부분의 상태 변수와 달리 이 카운터는 쿼리를 실행할 때마다 재설정되지 않으며, 서버가 다시 시작되면 재설정된다.
wsrep_flow_control_requested	노드가 복제 일시 중지를 요청했는지 여부를 반환.
wsrep_flow_control_sent	마지막 상태 쿼리 이후 전송된 FC_PAUSE 이벤트 수. 대부분의 상태 변수와 달리 이 카운터는 쿼리를 실행할 때마다 재설정되지 않으며, 서버가 다시 시작되면 재설정된다.
wsrep_flow_control_status	노드에 일반 트래픽에 대해 흐름 제어가 활성화되어 있는지 여부를 표시. SST 중에는 흐름 제어 상태를 나타내지 않는다.
wsrep_gcache_pool_size	GCache에 할당된 페이지 풀 및 동적 메모리의 크기(바이트)를 표시.
wsrep_gcomm_uuid	Galera 보기 ID(따라서 클러스터 상태 UUID와 관련 없음)인 gvwstate.dat의 UUID를 노출. 이 UUID는 각 노드마다 고유하며, 수동 제거 기능을 사용할 때 이 값을 알아야 한다.
wsrep_incoming_addresses	클러스터에 있는 수신 노드 주소의 쉼표로 구분된 목록을 표시.
wsrep_ist_receive_status	JOIN 노드에 대한 IST 진행 상황을 표시. IST가 실행 중이 아닌 경우 값은 비어 있으며, IST가 실행 중인 경우 값은 완료된 전송 비율.
wsrep_ist_receive_seqno_end	IST의 마지막 트랜잭션의 시퀀스 번호.
wsrep_ist_receive_seqno_current	IST에서 현재 트랜잭션의 시퀀스 번호.
wsrep_ist_receive_seqno_start	IST의 첫 번째 트랜잭션의 시퀀스 번호.
wsrep_last_applied	마지막으로 적용된 트랜잭션의 시퀀스 번호.
wsrep_last_committed	마지막으로 커밋된 트랜잭션의 시퀀스 번호.
wsrep_local_bf_aborts	실행되는 동안 복제본 트랜잭션에 의해 중단된 로컬 트랜잭션 수.
wsrep_local_cached_downto	GCache에서 가장 낮은 시퀀스 번호. 이 정보는 IST 및 SST를 결정하는 데 도움이 될 수 있다. 값이 0이면 GCache에 쓰기 세트가 없음을 의미 (일반적으로 단일 노드의 경우).
wsrep_local_cert_failures	인증 테스트에 실패한 쓰기 세트 수.
wsrep_local_commits	노드에 커밋된 쓰기 세트 수.
wsrep_local_index	클러스터에 있는 노드의 인덱스.
wsrep_local_recv_queue	수신 대기열의 현재 길이(즉, 적용을 기다리는 쓰기 세트 수).
wsrep_local_recv_queue_avg	마지막 상태 쿼리 이후 수신 대기열의 평균 길이. 이 숫자가 0보다 크면 노드가 쓰기 세트를 수신하는 속도만큼 빠르게 적용할 수 없음을 의미. 이는 노드가 과부하되어 복제 제한이 발생할 수 있다는 신호일 수 있다.
wsrep_local_replays	비대칭 잠금 세분성으로 인한 트랜잭션 재생 횟수.
wsrep_local_send_queue	전송 대기열의 현재 길이(즉, 전송 대기 중인 쓰기 세트 수).
wsrep_local_send_queue_avg	마지막 상태 쿼리 이후 전송 대기열의 평균 길이. 클러스터에서 네트워크 처리량 문제나 복제 제한이 발생하는 경우 이 값은 0보다 훨씬 커진다.
wsrep_local_state	내부 Galera 클러스터 FSM 상태 번호.
wsrep_local_state_comment	노드 상태에 대한 내부 번호 및 사람이 읽을 수 있는 해당 설명. 1 : Joining - Node is joining the cluster 2 : Donor/Desynced - Node is the donor to the node joining the cluster 3 : Joined - Node has joined the cluster 4 : Synced-Node is synced with the cluster
wsrep_local_state_uuid	노드에 저장된 상태의 UUID.
wsrep_monitor_status	로컬 모니터(로컬 및 복제 작업), 적용 모니터(쓰기 세트의 적용 작업) 및 커밋 모니터(쓰기 세트의 커밋 작업)의 상태. 이 변수의 값에서 각 모니터(L: Local, A: Apply, C: Commit)는 last_entered 및 last_left 쌍으로 표시. wsrep_monitor_status (L/A/C) [ ( 7, 5), (2, 2), ( 2, 2) ]
wsrep_protocol_version	사용된 wsrep 프로토콜의 버전.
wsrep_provider_name	wsrep 공급자의 이름(일반적으로 Galera).
wsrep_provider_vendor	wsrep 공급자 공급업체의 이름(일반적으로 Codership Oy).
wsrep_provider_version	wsrep 공급자의 현재 버전.
wsrep_ready	노드가 쿼리를 수락할 준비가 되었는지 표시. 상태가 OFF이면 거의 모든 쿼리가 ERROR 1047(08S01) 알 수 없는 명령 오류로 인해 실패한다. (wsrep_on 변수가 0으로 설정되지 않은 경우).
wsrep_received	다른 노드에서 수신된 총 쓰기 세트 수.
wsrep_received_bytes	다른 노드에서 수신된 쓰기 세트의 총 크기(바이트).
wsrep_repl_data_bytes	복제된 데이터의 총 크기(바이트).
wsrep_repl_keys	복제된 총 키 수.
wsrep_repl_keys_bytes	복제된 키의 총 크기(바이트).
wsrep_repl_other_bytes	복제된 다른 비트의 총 크기.
wsrep_replicated	다른 노드로 전송된 총 쓰기 세트 수.
wsrep_replicated_bytes	복제된 쓰기 세트의 총 크기. 네트워크를 통해 클러스터 피어로 전송된 실제 바이트 크기를 계산하려면 이 변수의 값에 지정된 네트워크 세그먼트의 클러스터 피어 수를 곱한다.

[wsrep system variables]

wsrep system variables	Comments
pxc_encrypt_cluster_traffic	SSL 암호화의 자동 구성을 활성화 유무. l ON, 1, true : Enabled(default). l OFF, 0, false : Disabled.
pxc_maint_mode	ProxySQL의 설정을 조정하지 않고 노드를 종료하기 위한 유지 관리 모드를 지정. l DISABLED : ProxySQL에게 평소와 같이 트래픽을 노드로 라우팅하도록 지시하는 기본 상태. l SHUTDOWN: 노드 종료를 시작할 때 자동으로 설정. l MAINTENANCE: 노드를 종료하지 않고 유지 관리를 수행해야 하는 경우 이 상태를 수동으로 변경할 수 있다.
pxc_maint_transition_period	pxc_maint_mode를 SHUTDOWN 또는 MAINTENANCE로 변경할 때 전환 기간을 정의. 기본적으로 기간은 10초로 설정. 장기 실행 트랜잭션을 수용하도록 값을 늘릴 수 있다.
pxc_strict_mode	Percona XtraDB Cluster에서 실험적 기능과 지원되지 않는 기능의 사용을 피하기 위해 검증을 실행하는 PXC Strict 모드를 제어. 선택한 실제 모드에 따라 유효성 검사에 실패하면 서버에서 오류가 발생하거나(시작 중지 또는 작업 거부) 경고를 기록하고 정상적으로 계속 실행.
wsrep_applier_FK_checks	Percona XtraDB Cluster 8.0.26-16부터 wsrep_slave_FK_checks 변수는 이 변수를 위해 더 이상 사용되지 않음.
wsrep_applier_threads	Percona XtraDB Cluster 8.0.26-16부터 wsrep_slave_threads 변수는 더 이상 사용되지 않으며, wsrep_applier_threads 변수를 사용한다.
wsrep_applier_UK_checks	Percona XtraDB Cluster 8.0.26-16부터 wsrep_slave_UK_checks 변수는 더 이상 사용되지 않으며, wsrep_applier_UK_checks 변수를 사용한다.
wsrep_auto_increment_control	클러스터 크기에 따라 자동 증가 시스템 변수의 자동 조정을 활성화. l auto_increment_increment : 연속적인 AUTO_INCREMENT 열 값 사이의 간격을 제어. l auto_increment_offse : AUTO_INCREMENT 열 값의 시작점을 결정.
wsrep_causal_reads	경우에 따라 소스가 복제본보다 더 빠르게 이벤트를 적용할 수 있으며, 이로 인해 소스와 복제본이 잠시 동안 동기화되지 않을 수 있다. 이 변수가 ON으로 설정되면 복제본은 다른 쿼리를 수행하기 전에 해당 이벤트가 적용될 때까지 기다린다. 이 변수를 활성화하면 대기 시간이 길어진다.
wsrep_certification_rules	클러스터에서 인증이 수행되는 방식을 제어하며, 특히 외래 키가 처리되는 방식에 영향을 미친다.
wsrep_certify_nonPK	기본 키가 없는 행에 대해 기본 키 자동 생성을 활성화.
wsrep_cluster_address	클러스터에 연결할 때 노드가 사용하는 백엔드 스키마, IP 주소, 포트 및 옵션을 정의. 이 변수는 활성 상태이고 클러스터의 구성원인 다른 노드의 주소를 하나 이상 지정해야 한다. 실제로는 가능한 모든 클러스터 노드의 전체 목록을 제공하는 것이 가장 좋다(필수는 아님).
wsrep_cluster_name	클러스터의 이름을 지정하며 모든 노드에서 동일해야 한다. 노드는 클러스터에 연결을 시도할 때 값을 확인한다. 이름이 일치하면 노드가 연결됩니다.
wsrep_data_home_dir	wsrep 공급자가 해당 파일(예: grastate.dat)을 저장하는 디렉터리의 경로를 지정.
wsrep_dbug_option	wsrep 공급자에게 전달할 DBUG 옵션을 정의.
wsrep_debug	데이터베이스 서버 및 wsrep-lib에 대한 디버그 수준 로깅을 활성화(기본적으로 --wsrep-debug 변수는 비활성화되어 있음). 이 변수는 문제를 진단하거나 버그를 제출할 때 사용할 수 있다.
wsrep_desync	노드가 흐름 제어에 참여해야 하는지 여부를 정의 (비활성화 기본값). 수신 대기열이 너무 커지면 노드가 흐름 제어에 참여한다. 이 변수를 활성화하면 노드에 대한 흐름 제어가 비활성화된다. 적용할 수 없는 쓰기 세트를 계속 수신하고 수신 대기열은 계속 증가하며 노드는 계속해서 클러스터 뒤처지게 된다. 이를 다시 OFF로 전환하려면 비동기화 기간에 따라 IST 또는 SST가 필요하다. 이는 RSU TOI 중에 발생하는 클러스터 비동기화와 유사하다. 이 때문에 wsrep_desync를 오랜 기간 동안 활성화하거나 여러 노드에 대해 동시에 활성화하는 것은 좋은 생각이 아니다.
wsrep_dirty_reads	노드가 비작동 상태, 즉 기본 구성요소에 대한 연결이 끊어졌을 때 읽기 쿼리를 수락할지 여부를 정의. 기본적으로 이 변수는 비활성화되어 있으며 데이터가 올바른지 알 수 있는 방법이 없기 때문에 노드는 모든 쿼리를 거부한다. 이 변수를 활성화하면 노드는 읽기 쿼리(USE, SELECT, LOCK TABLE 및 UNLOCK TABLES)를 허용하지만 작동하지 않는 노드에서 데이터베이스를 수정하거나 업데이트하는 모든 명령은 계속 거부된다(DDL 및 DML 문 포함). INSERT, DELETE, UPDATE 등). 교착 상태 오류를 방지하려면 wsrep_dirty_reads를 활성화한 경우 wsrep_sync_wait 변수를 0으로 설정한다. Percona XtraDB Cluster 8.0.26-16부터 set_var 힌트를 사용하여 변수를 업데이트할 수 있다.
wsrep_drupal_282555_workaround	Drupal에 영향을 미치는 MySQL InnoDB 버그(Drupal 버그 #282555 및 MySQL 버그 #41984)에 대한 해결 방법을 활성화한다. 경우에 따라 AUTO_INCREMENT 열에 DEFAULT 값을 삽입할 때 중복 키 오류가 발생한다.
wsrep_forced_binlog_format	클라이언트 세션 binlog_format 변수 값에 관계없이 항상 유효한 바이너리 로그 형식을 정의한다. l ROW: Force row-based logging format l STATEMENT: Force statement-based logging format l MIXED: Force mixed logging format l NONE: Do not force the binary log format and use whatever is set by the binlog_format variable (default)
wsrep_ignore_apply_errors	오류에 대한 wsrep 적용자 동작 규칙을 정의.
wsrep_min_log_verbosity	wsrep/Galera의 최소 로깅 상세 수준을 정의하고 log_error_verbosity 변수와 함께 작동. wsrep_min_log_verbosity는 log_error_verbosity와 동일한 값을 갖는다. log_error_verbosity가 wsrep_min_log_verbosity보다 큰 경우 wsrep/Galera의 실제 로그 상세 수준은 wsrep_min_log_verbosity 값보다 클 수 있다.
wsrep_load_data_splitting	노드가 대규모 LOAD DATA 트랜잭션을 분할해야 하는지 여부를 정의. 이 변수는 기본적으로 활성화됩니다. 즉, LOAD DATA 명령은 10,000행 이하의 트랜잭션으로 분할된다. 이 변수를 비활성화하면 막대한 데이터 로드로 인해 충돌 발생 시 노드가 작업을 완전히 롤백하지 못할 수 있으며 커밋된 내용은 커밋된 상태로 유지된다.
wsrep_log_conflicts	노드가 충돌에 대한 추가 정보를 기록해야 하는지 여부를 정의. 기본적으로 이 변수는 비활성화되어 있으며 Percona XtraDB Cluster는 MySQL의 표준 로깅 기능을 사용. 이 변수를 활성화하면 충돌이 발생한 테이블과 스키마뿐만 아니라 충돌을 일으킨 키의 실제 값도 기록된다.
wsrep_max_ws_rows	각 쓰기 세트에 포함될 수 있는 최대 행 수를 정의. 기본적으로 쓰기 세트의 최대 행 수에는 제한이 없다. 허용되는 최대 값은 1048576이다.
wsrep_max_ws_size	최대 쓰기 세트 크기(바이트)를 정의. 지정된 값보다 큰 값은 거부된다. 1024와 기본값 2147483647 사이의 값으로 설정할 수 있다.
wsrep_mode	Percona XtraDB Cluster 8.0.31에서 구현되었으며, 지정된 값에 따라 노드 동작을 정의. 값은 기본적으로 비어 있거나 비활성화되어 있음. l 비어 있음 - 노드 동작을 변경하지 않음. l IGNORE_NATIVE_REPLICATION_FILTER_RULES - 기본 복제 필터 규칙을 무시하도록 wsrep 동작을 변경.
wsrep_node_address	노드의 네트워크 주소를 지정. 기본적으로 이 변수는 첫 번째 네트워크 인터페이스(일반적으로 eth0 또는 enp2s0)의 IP 주소와 기본 포트(4567)로 설정.
wsrep_node_incoming_address	노드가 클라이언트 연결을 예상하는 네트워크 주소를 지정. 기본적으로 wsrep_node_address의 IP 주소와 포트 번호 3306을 사용.
wsrep_node_name	노드의 고유 이름을 정의. 기본값은 호스트 이름. 이 변수의 값을 클러스터에서 지정된 노드를 식별하는 수단으로 사용할 수 있다.
wsrep_notify_cmd	클러스터 멤버십이나 로컬 노드 상태가 변경될 때마다 노드가 실행해야 하는 알림 명령을 지정. 이는 경고를 보내거나 로드 밸런서를 재구성하는 데 사용될 수 있다.
wsrep_on	노드의 현재 세션 트랜잭션 변경 사항이 클러스터에 복제되는지 정의. 세션을 OFF로 설정하면 해당 세션에 트랜잭션 변경 사항이 복제되지 않는다. 설정으로 인해 노드가 클러스터를 떠나지 않으며 노드가 다른 노드와 통신한다.
wsrep_OSU_method	노드가 DDL 문을 복제하는 데 사용하는 온라인 스키마 업그레이드 방법을 정의.
wsrep_provider	Galera 라이브러리의 경로를 지정. 경로를 지정하지 않거나 값이 유효하지 않은 경우 노드는 MySQL의 독립 실행형 인스턴스로 작동.
wsrep_provider_options	wsrep_provider옵션 인덱스에 설명된 복제 공급자에 대한 선택적 설정을 지정. 이러한 옵션은 복제 중에 다양한 상황이 처리되는 방식에 영향을 준다.
wsrep_recover	로그에서 GTID를 구문 분석하여 충돌 후 데이터베이스 상태를 복구. GTID가 발견되면 서버의 초기 위치로 지정된다.
wsrep_reject_queries	노드가 클라이언트의 쿼리를 거부해야 하는지 여부를 정의. 쿼리 거부는 업그레이드 중에 쿼리를 수락하지 않고 노드를 유지하고 쓰기 세트를 적용하려는 경우 유용할 수 있다.
wsrep_replicate_myisam	MyISAM 테이블에 대한 DML 문을 복제해야 하는지 여부를 정의. 기본적으로 비활성화되어 있다. 전역 수준에서 wsrep_replicate_myisam은 시작 중에만 설정할 수 있다. 세션 수준에서는 런타임 중에도 변경할 수 있다.
wsrep_restart_replica	Percona XtraDB Cluster 8.0.26-16부터 더 이상 사용되지 않음.
wsrep_restart_slave	Percona XtraDB Cluster 8.0.26-16부터 더 이상 사용되지 않음.
wsrep_retry_autocommit	인증 오류가 발생할 경우 클러스터에서 자동 커밋 트랜잭션을 다시 시도할 횟수를 지정. 충돌이 있는 경우 클러스터 노드는 클라이언트에 오류를 반환하지 않고 명령문을 다시 시도하여 다음에 통과할 수 있기를 바라면 안전하다. 이는 복제 충돌로 인해 발생할 수 있는 교착 상태 오류를 방지하기 위해 자동 커밋을 사용하는 애플리케이션을 돕는 데 유용할 수 있다. 이 변수가 0으로 설정되면 자동 커밋 트랜잭션이 다시 시도되지 않는다.
wsrep_RSU_commit_timeout	RSU를 시작하기 전에 활성 연결이 COMMIT 작업을 완료할 수 있도록 허용하는 시간 제한(마이크로초)을 지정. RSU를 실행하는 동안 사용자가 노드를 격리했고 노드에서 실행 중인 활성 트래픽이 없을 것으로 예상된다. RSU는 이를 확인하고 RSU를 시작하기 전에 COMMIT 상태의 활성 연결을 기다린다. 기본적으로 이 검사의 시간 제한은 5밀리초이지만 어떤 경우에는 COMMIT가 더 오래 걸린다. 이 변수는 제한 시간을 설정하며 (5밀리초, 365일) 범위의 값을 허용한다. 값은 마이크로초 단위로 설정된다. 변수의 단위는 마이크로초 단위이므로 그에 맞춰 설정한다.
wsrep_slave_FK_checks	Percona XtraDB Cluster 8.0.26-16부터 이 변수는 더 이상 사용되지 않음.
wsrep_slave_threads	Percona XtraDB Cluster 8.0.26-16부터 이 변수는 더 이상 사용되지 않음.
wsrep_slave_UK_checks	Percona XtraDB Cluster 8.0.26-16부터 이 변수는 더 이상 사용되지 않음.
wsrep_SR_store	스트리밍 복제 조각을 위한 스토리지를 정의. 사용 가능한 값은 기본값인 table과 변수를 비활성화하는 none이다.
wsrep_sst_allowed_methods	wsrep_sst_method 변수에 대해 서버에서 허용하는 SST 방법을 제한. 기본값은 xtrabackup-v2이다.
wsrep_sst_donor	현재 노드가 SST 및 IST에 대한 기증자로 선호해야 하는 노드 목록(wsrep_node_name 값 사용)을 지정.
wsrep_sst_method	SST(상태 스냅샷 전송)에 대한 방법 또는 스크립트를 정의.
wsrep_sst_receive_address	기증자 노드가 상태 전송을 보내야 하는 네트워크 주소를 지정. 기본적으로 이 변수는 AUTO로 설정되며 wsrep_node_address의 IP 주소가 사용됩니다.
wsrep_start_position	노드의 시작 위치를 UUID:seqno로 지정. 이 변수에 대해 모든 노드가 동일한 값을 갖도록 설정하면 상태 전송 없이 클러스터를 설정할 수 있다.
wsrep_sync_wait	특정 명령문에 대한 클러스터 전체의 인과성 검사를 제어한다. 클러스터와 완전히 동기화된 노드에서 명령문이 실행되는지 확인한다. Percona XtraDB Cluster 8.0.26-16부터 set_var 힌트를 사용하여 변수를 업데이트할 수 있다.
wsrep_trx_fragment_size	스트리밍 복제 조각 크기를 정의한다. 이 변수는 wsrep_trx_fragment_unit에 의해 정의된 값으로 측정된다. 최소값은 0이고 최대값은 2147483647이다. Percona XtraDB Cluster for MySQL 8.0.26-16부터 set_var 힌트를 사용하여 변수를 업데이트할 수 있다.
wsrep_trx_fragment_unit	wsrep_trx_fragment_size에 대한 측정 유형을 정의. 가능한 값은 바이트, 행, 명령문이다. Percona XtraDB Cluster for MySQL 8.0.26-16부터 set_var 힌트를 사용하여 변수를 업데이트할 수 있다.

[참고자료]

l About Percona XtraDB Cluster : https://docs.percona.com/percona-xtradb-cluster/8.0/intro.html

2023-09-27 / Sungwook Kang / http://sungwookkang.com

MySQL Percona, XtraDB, XtraBackup, XtraDB Cluster, 퍼코나 클러스터, 퍼코나 데이터베이스

[Linux] 리눅스 디스크 용량 확인

SungWookKang — Tue, 26 Sep 2023 15:27:10 +0900

[Linux] 리눅스 디스크 용량 확인

l Linux

리눅스 시스템을 운영하다 보면 디스크 공간 사용률이 100%가 되어 서비스에 장애가 발생하는 경우가 있다. 일반적으로 실수하는 부분이 로그 파일을 방치하여 어느 순간 디스크 공간을 모두 소진하였거나, 데이터베이스 서버의 경우 데이터를 백업할 때 순간적으로 디스크를 모두 소진하여 발생할 때가 있다. 주기적인 시스템 모니터링으로 디스크 공간에 대한 사용률을 확인하여 사전에 이러한 부분을 방지할 수 있도록 하는 것이 중요하다. 그렇다면 어느 디렉터리에서 많은 공간을 사용하는지를 확인하는 방법은 무엇일까? 이번 포스트에서는 리눅스에서 디스크 사용량을 확인하는 방법에 대해서 알아본다.

리눅스에서 디스크 공간을 확인하는 명령어는 df (Disk Free)이다. 마운트 되어있는 모든 디스크의 사용량을 보여준다. 1K-blocks 항목이 디스크에 할당된 용량이며, Used는 실제 사용량, Available는 사용 가능한 공간, Use%는 디스크 공간에서 사용률을 퍼센트로 나타낸다.

디스크 용량 및 사용량이 킬로바이트로 표시되기 때문에 용량이 큰 경우 자릿수로 인해 쉽게 사용자가 확인하기 어렵다. 이때 -h 옵션을 사용하면 사용자 친화적으로 확인할 수 있다.

df -h

디스크가 아닌 각 디렉터리별 사용량 확인은 du명령을 사용한다. du는 disk usage의 약자로 하위 디렉토리를 포함한 디스크 사용량을 보여준다.

du -h /var/lib/

하위 디렉터리가 많을 경우, 어느 디렉토리에서 사용량이 많은지 한번에 확인하기 힘들다. 따라서 사용량 기준으로 정렬한 결과를 표시할 때에는 sort -n 옵션을 사용한다.

du -h /var/log | sort -n

그런데 나타난 결과를 보면 정렬 상태가 이상하다. 단위가 바뀌면서 88K가 4.1G 보다 더 큰 것처럼 정렬되었다. 따라서 정렬을 할 때에는 -h 옵션을 사용하지 않도록 한다.

du /var/log | sort -n

2023-09-26 / Sungwook Kang / https://sungwookkang.com

리눅스, Linux, 디스크 사용량, 리눅스 디스크, 디스크 usage, disk usage

[MySQL] MySQL 5.7에서 8.0으로 업그레이드시 변경되는 설정 및 옵션 정리

SungWookKang — Wed, 13 Sep 2023 15:54:51 +0900

[MySQL] MySQL 5.7에서 8.0으로 업그레이드시 변경되는 설정 및 옵션 정리

l Version : MySQL 8.X

MySQL 5.7 버전과 MySQL 8.0은 큰 변화가 있기 때문에, 업그레이드하기 전에 많은 주의가 필요하다. 현재 운영중인 MySQL 5.7X 버전에서 MySQL 8.0.X로 업그레이드 프로젝트를 진행하게 되어, 업그레이드시 주의해야 될 사항 및 변경되는 사항을 정리해본다.

[Data Dictionary]

MySQL Server 8.0에는 트랜잭션 테이블의 데이터베이스 개체에 대한 정보가 포함된 전역 Data Dictionary가 통합되어 있다. 이전 MySQL 시리즈에서는 Data Dictionary가 메타데이터 파일과 InnoDB 시스템 테이블에 저장되었다. 이전에는 innodb_read_only 시스템 변수를 활성화하면 InnoDB 스토리지 엔진에 대해서만 테이블을 생성하고 삭제할 수 없었다. MySQL 8.0부터 innodb_read_only를 활성화하면 모든 스토리지 엔진에 대해 이러한 작업이 방지된다. 모든 스토리지 엔진에 대한 테이블 생성 및 삭제 작업은 mysql 시스템 데이터베이스의 데이터 Dictionary 테이블을 수정하지만 해당 테이블은 InnoDB 스토리지 엔진을 사용하며 innodb_read_only가 활성화되면 수정할 수 없다. Data Dictionary 테이블을 수정해야 하는 다른 테이블 작업에도 동일한 원칙이 적용된다.

이전에는 STATISTICS 및 테이블 통계에 대한 INFORMATION_SCHEMA 쿼리가 스토리지 엔진에서 직접 통계를 검색했다면, MySQL 8.0부터는 캐시된 테이블 통계가 기본적으로 사용된다. information_schema_stats_expiry 시스템 변수는 캐시된 테이블 통계가 만료되는 기간을 정의한다. 기본값은 86400초(24시간)이며, 테이블에 대해 수동으로 캐시된 값을 업데이트하려면 ANALYZE TABLE을 사용할 수 있다. 캐시된 통계가 없거나 통계가 만료된 경우에는 테이블 통계 열을 쿼리할 때 스토리지 엔진에서 통계가 검색된다. 항상 스토리지 엔진에서 직접 최신 통계를 검색하려면 information_schema_stats_expiry를 0으로 설정한다.

INFORMATION_SCHEMA 테이블은 Data Dictionary 테이블에 대한 뷰로, 이를 통해 최적화 프로그램은 해당 기본 테이블에 대한 인덱스를 사용할 수 있다. 결과적으로 최적화 프로그램 선택에 따라 INFORMATION_SCHEMA 쿼리 결과의 행 순서가 이전 결과와 다를 수 있다. 쿼리 결과에 특정 행 순서 특성이 있어야 하는 경우 ORDER BY 절을 포함한다.

INFORMATION_SCHEMA 테이블에 대한 쿼리는 이전 MySQL 시리즈와는 다른 문자로 열 이름을 반환할 수 있다. 애플리케이션은 결과 세트에 대해 열 이름이 대소문자를 구분하지 않도록 테스트해야 한다. 이러한 부분을 방지하려면 필수 문자 대소문자로 열 이름을 반환하도록 별칭을 사용한다.

mysqldump 및 mysqlpump는 명령줄에 명시적으로 이름이 지정된 경우에도 더 이상 INFORMATION_SCHEMA 데이터베이스를 덤프하지 않는다. Data Dictionary에 대한 자세한 내용은 아래 링크를 참고한다.

l Data Dictionary Usage Differences : https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-usage-differences.html

[caching_sha2_password 인증 플러그인 변경]

caching_sha2_password 및 sha256_password 인증 플러그인은 mysql_native_password 플러그인보다 더 안전한 비밀번호 암호화를 제공하고, caching_sha2_password는 sha256_password보다 더 나은 성능을 제공한다. caching_sha2_password은 MySQL 8.0부터 기본 인증 플러그인으로 사용된다. 이 변경 사항은 서버와 libmysqlclient 클라이언트 라이브러리 모두에 영향을 미친다.

서버의 경우 default_authentication_plugin 시스템 변수의 기본값이 mysql_native_password에서 caching_sha2_password로 변경된다. 이 변경 사항은 MySQL 8.0 이상을 설치하거나 업그레이드한 후에 생성된 새 계정에만 적용된다. 업그레이드된 설치에 이미 존재하는 계정의 경우 해당 인증 플러그인은 변경되지 않은 상태로 유지된다. 기존 사용자를 caching_sha2_password로 전환하려면 ALTER USER 문을 사용하여 전환할 수 있다.

ALTER USER user IDENTIFIED WITH caching_sha2_password BY 'password';

MySQL 8.0 이상으로 업그레이드한 후 호환성 문제가 발생하는 경우 이전 기본 인증 플러그인으로 되돌리도록 서버를 재구성할 수 있다. 이 설정을 사용하면 기본의 애플리케이션들이 이전의 패스워드 방식을 사용할 수 있다. 하지만 이 방법은 보안에 취약하기 때문에 영구적으로 사용할 수 없다.

[mysqld]
default_authentication_plugin=mysql_native_password

자세한 내용은 아래 링크를 참고한다.

l Pluggable Authentication : https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html#pluggable-authentication-compatibility

[caching_sha2_password and the root Administrative Account]

MySQL 8.0으로 업그레이드하는 경우 'root'@'localhost' 관리 계정용 플러그인을 포함하여 기존 인증 플러그인 계정은 변경되지 않은 상태로 유지된다. 새로운 MySQL 8.0 설치의 경우 데이터 디렉터리를 초기화하면 'root'@'localhost' 계정이 생성되고 해당 계정은 기본적으로 caching_sha2_password를 사용한다. 따라서 데이터 디렉터리 초기화 후 서버에 연결하려면 caching_sha2_password를 지원하는 클라이언트나 커넥터를 사용해야 한다. 신규 설치 후 루트 계정이 mysql_native_password를 사용하도록 하려면 MySQL을 설치하고 평소와 같이 데이터 디렉토리를 초기화한다. 그런 다음 루트로 서버에 연결하고 다음과 같이 ALTER USER를 사용하여 계정 인증 플러그인과 비밀번호를 변경한다.

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

[caching_sha2_password and Replication]

모든 서버가 MySQL 8.0.4 이상으로 업그레이드된 복제 시나리오에서 원본 서버에 대한 복제본 연결은 caching_sha2_password로 인증하는 계정을 사용할 수 있다. 이러한 연결의 경우 caching_sha2_password로 인증하는 계정을 사용하는 다른 클라이언트와 동일한 요구 사항이 적용된다. 즉, 보안 연결 또는 RSA 기반 암호 교환을 사용한다.

[Configuration Changes]

MySQL 스토리지 엔진은 자체 파티셔닝 핸들러 제공을 담당하며 MySQL 서버는 더 이상 일반 파티셔닝 지원을 제공하지 않는다. InnoDB와 NDB는 MySQL 8.0에서 지원되는 기본 파티셔닝 핸들러를 제공하는 유일한 스토리지 엔진이다. 다른 스토리지 엔진을 사용하는 파티션된 테이블은 서버를 업그레이드하기 전에 InnoDB 또는 NDB로 변환하거나 파티셔닝을 제거하기 위해 변경해야 한다. 그렇지 않으면 나중에 사용할 수 없다.

collation_server 및 collation_database 시스템 변수의 기본값이 latin1_swedish_ci에서 utf8mb4_0900_ai_ci로 변경되었다. 결과적으로 새 개체의 기본 문자 집합과 데이터 정렬은 명시적인 문자 집합과 데이터 정렬을 지정하지 않는 한 이전과 다르다. 여기에는 테이블, 뷰, 저장된 프로그램 등 데이터베이스와 그 안에 있는 개체가 포함된다. 이전 기본값이 사용되었다고 가정하면 이를 유지하기 위한 방법은 my.cnf 파일에서 아래 명령을 사용하여 서버를 재시작 한다.

[mysqld]
character_set_server=latin1
collation_server=latin1_swedish_ci

복제된 설정에서 MySQL 5.7에서 8.0으로 업그레이드할 때, 업그레이드하기 전에 기본 문자 집합을 MySQL 5.7에서 사용된 문자 집합으로 다시 변경하는 것이 좋다. 업그레이드가 완료되면 기본 문자 집합을 utf8mb4로 변경할 수 있다. 또한 MySQL 8.0은 MySQL 5.7이 수행하지 않는 특정 문자 집합의 허용된 문자에 대한 검사를 시행한다는 점을 기억해야 한다. 이는 알려진 문제로 업그레이드를 시도하기 전에 사용 중인 문자 세트에 대해 정의되지 않은 문자가 주석에 포함되어 있는지 확인해야 한다. 아래 두 가지 방법 중 하나로 이 문제를 해결할 수 있다.

l 문제의 문자를 포함하는 문자 세트로 문자 세트를 변경

l 문제가 되는 문자를 제거

MySQL 8.0.11부터 서버 초기화 시 사용된 설정과 다른 lower_case_table_names 설정으로 서버를 시작할 수 없다. 다양한 데이터 사전 테이블 필드에서 사용되는 데이터 정렬은 서버가 초기화될 때 정의된 lower_case_table_names 설정을 기반으로 하고, 다른 설정으로 서버를 다시 시작하면 식별자 정렬 및 비교 방법과 관련하여 불일치가 발생하므로 제한이 필요하다.

[Server Changes]

MySQL 8.0.11에서는 사용자 계정의 비권한 특성을 수정하기 위한 GRANT 문 사용, NO_AUTO_CREATE_USER SQL 모드, PASSWORD() 함수, old_passwords 시스템 변수 등 계정 관리와 관련된 더 이상 사용되지 않는 여러 기능이 제거되었다. 이러한 제거된 기능을 참조하는 명령문을 MySQL 5.7에서 8.0으로 복제하면 복제 오류가 발생할 수 있다. 제거된 기능을 사용하는 애플리케이션은 이를 방지하도록 수정되어야 하며, 가능하면 MySQL 8.0에서 제거된 기능에 설명된 대로 대안을 사용해야 한다.

MySQL 8.0에서 시작 실패를 방지하려면 MySQL 옵션 파일의 sql_mode 시스템 변수 설정에서 NO_AUTO_CREATE_USER 인스턴스를 제거한다. 저장된 프로그램 정의에 NO_AUTO_CREATE_USER SQL 모드를 포함하는 덤프 파일을 MySQL 8.0 서버로 로드하면 오류가 발생한다. MySQL 5.7.24 및 MySQL 8.0.13부터 mysqldump는 저장된 프로그램 정의에서 NO_AUTO_CREATE_USER를 제거한다. 이전 버전의 mysqldump로 생성된 덤프 파일을 수동으로 수정하여 NO_AUTO_CREATE_USER 인스턴스를 제거해야 한다.

MySQL 8.0.11에서는 더 이상 사용되지 않는 호환성 SQL 모드인 DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS가 제거되었다. 더 이상 sql_mode 시스템 변수에 할당하거나 mysqldump -- Compatible 옵션에 허용되는 값으로 사용할 수 없다. MAXDB가 제거된다는 것은 CREATE TABLE 또는 ALTER TABLE에 대한 TIMESTAMP 데이터 유형이 더 이상 DATETIME으로 처리되지 않음을 의미한다.

제거된 SQL 모드를 참조하는 명령문을 MySQL 5.7에서 8.0으로 복제하면 복제 오류가 발생할 수 있다. 여기에는 현재 sql_mode 값에 제거된 모드가 포함되어 있는 동안 실행되는 저장 프로그램(저장 프로시저 및 함수, 트리거 및 이벤트)에 대한 CREATE 문의 복제가 포함된다.

MySQL 8.0.3부터 공간 데이터 유형은 열에 저장된 값에 대한 공간 참조 시스템(SRS)을 명시적으로 나타내기 위해 SRID 속성을 허용한다. 명시적인 SRID 특성이 있는 공간 열은 SRID로 제한되며 해당열은 해당 ID를 가진 값만 사용하며 열의 SPATIAL 인덱스는 최적화 프로그램에서 사용하게 된다. 최적화 프로그램은 SRID 속성이 없는 공간 열의 SPATIAL 인덱스를 무시한다. 최적화 프로그램이 SRID로 제한되지 않은 공간 열의 SPATIAL 인덱스를 고려하도록 하려면 해당 열을 각각 수정해야 한다.

정확한 연산을 수행하는 함수에 대해 ST_ 접두사를 구현하거나 최소 경계 사각형을 기반으로 연산을 수행하는 함수에 대해 MBR 접두사를 구현하는 공간 함수 네임스페이스 변경으로 인해 MySQL 8.0.0에서 여러 공간 함수가 제거되었다. 생성된 열 정의에서 제거된 공간 함수를 사용하면 업그레이드가 실패할 수 있다. 업그레이드하기 전에 제거된 공간 함수에 대해 mysqlcheck --check-upgrade를 실행하고 찾은 모든 것을 ST_ 또는 MBR이라는 이름의 대체 항목으로 변경해야 한다. 제거된 함수목록은 아래 링크를 참고한다.

l Features Removed in MySQL 8.0 : https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals

BACKUP_ADMIN 권한은 MySQL 8.0.3 이상으로 전체 업그레이드를 수행할 때 RELOAD 권한이 있는 사용자에게 자동으로 부여된다.

MySQL 8.0.13부터는 행 기반 또는 혼합 복제 모드와 명령문 기반 복제 모드의 임시 테이블 처리 방식 차이로 인해 런타임 시 바이너리 로깅 형식 전환에 대한 새로운 제한 사항이 있다. 세션에 열려 있는 임시 테이블이 있으면 SET @@SESSION.binlog_format을 사용할 수 없다. 복제 채널에 열려 있는 임시 테이블이 있으면 SET @@global.binlog_format 및 SET @@persist.binlog_format을 사용할 수 없다. PERSIST와 달리 PERSIST_ONLY는 런타임 전역 시스템 변수 값을 수정하지 않기 때문에 복제 채널에 열려 있는 임시 테이블이 있는 경우 SET @@persist_only.binlog_format이 허용된다. 복제 채널 적용자가 실행 중인 경우 SET @@global.binlog_format 및 SET @@persist.binlog_format을 사용할 수 없다. 이는 적용자가 다시 시작될 때만 변경 사항이 복제 채널에 적용되며 이때 복제 채널에 열려 있는 임시 테이블이 있을 수 있기 때문이다. 이 동작은 이전보다 더 제한적이며 복제 채널 적용자가 실행 중인 경우 SET @@persist_only.binlog_format이 허용된다.

MySQL 8.0.27부터 Internal_tmp_mem_storage_engine에 대한 세션 설정을 구성하려면 SESSION_VARIABLES_ADMIN 또는 SYSTEM_VARIABLES_ADMIN 권한이 필요하다.

MySQL 8.0.27부터 복제 플러그인은 복제 작업이 진행되는 동안 donor 역할을 하는 MySQL 인스턴스에서 동시 DDL 작업을 허용한다. 이전에는 복제 작업 중에 백업 잠금이 유지되어 donor에 대한 동시 DDL이 방지되었다. 복제 작업 중에 donor에서 동시 DDL을 차단하는 이전 동작으로 되돌리려면 clone_block_ddl 변수를 활성화한다. 자세한 내용은 아래 링크를 참고한다.

l Cloning and Concurrent DDL : https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-concurrent-ddl.html

MySQL 8.0.30부터 시작 시 log_error_services 값에 나열된 오류 로그 구성 요소는 MySQL Server 시작 시퀀스 초기에 암시적으로 로드된다. 이전에 INSTALL COMPONENT를 사용하여 로드 가능한 오류 로그 구성 요소를 설치했고 시작 시 읽는 log_error_services 설정(예: 옵션 파일에서)에 해당 구성 요소를 나열한 경우 시작 경고가 발생하지 않도록 구성을 업데이트해야 한다. 자세한 내용은 아래 링크를 참고한다.

l Error Log Configuration Methods : https://dev.mysql.com/doc/refman/8.0/en/error-log-configuration.html#error-log-configuration-methods

[InnoDB Changes]

InnoDB 시스템 테이블을 기반으로 하는 INFORMATION_SCHEMA 뷰는 Data Dictionary 테이블의 내부 시스템 뷰로 대체되었다. 그리고 영향을 받은 InnoDB INFORMATION_SCHEMA 뷰의 이름이 변경되었다. MySQL 8.0.3 이상으로 업그레이드한 후 이전 InnoDB INFORMATION_SCHEMA 뷰 이름을 참조하는 스크립트가 있다면 새로운 이름으로 업데이트 해야 한다.

Old Name	New Name
INNODB_SYS_COLUMNS	INNODB_COLUMNS
INNODB_SYS_DATAFILES	INNODB_DATAFILES
INNODB_SYS_FIELDS	INNODB_FIELDS
INNODB_SYS_FOREIGN	INNODB_FOREIGN
INNODB_SYS_FOREIGN_COLS	INNODB_FOREIGN_COLS
INNODB_SYS_INDEXES	INNODB_INDEXES
INNODB_SYS_TABLES	INNODB_TABLES
INNODB_SYS_TABLESPACES	INNODB_TABLESPACES
INNODB_SYS_TABLESTATS	INNODB_TABLESTATS
INNODB_SYS_VIRTUAL	INNODB_VIRTUAL

MySQL과 함께 번들로 제공되는 zlib 라이브러리 버전이 버전 1.2.3에서 버전 1.2.11로 상향되었다. zlib 1.2.11의 zlib 압축Bound() 함수는 zlib 버전 1.2.3에서보다 주어진 바이트 길이를 압축하는 데 필요한 버퍼 크기의 약간 더 높은 추정치를 반환한다. CompressBound() 함수는 압축된 InnoDB 테이블을 생성하거나 압축된 InnoDB 테이블에 행을 삽입 및 업데이트할 때 허용되는 최대 행 크기를 결정하는 InnoDB 함수에 의해 호출된다. 결과적으로 이전 릴리스에서 성공했던 최대 행 크기에 매우 가까운 행 크기를 사용하는 CREATE TABLE ... ROW_FORMAT=COMPRESSED, INSERT 및 UPDATE 작업이 이제 실패할 수 있다. 이 문제를 방지하려면 업그레이드하기 전에 MySQL 8.0 테스트 인스턴스에서 큰 행이 있는 압축된 InnoDB 테이블에 대해 CREATE TABLE 문을 테스트해야 한다.

--innodb-directories 기능이 도입되면서 절대 경로 또는 데이터 디렉터리 외부 위치로 생성된 테이블당 파일 및 일반 테이블스페이스 파일의 위치가 innodb_directories 인수 값에 추가되어야 한다. 그렇지 않으면 InnoDB는 복구 중에 이러한 파일을 찾을 수 없어 오류가 발생한다. 테이블스페이스 파일 위치를 보려면 정보 스키마 FILES 테이블을 쿼리한단.

SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G

실행 취소 로그는 더 이상 시스템 테이블스페이스에 상주하지 않는다. MySQL 8.0에서 실행 취소 로그는 기본적으로 두 개의 실행 취소 테이블스페이스에 있다. 자세한 내용은 아래 링크를 참고한다.

l Undo Tablespaces : https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html

MySQL 5.7에서 MySQL 8.0으로 업그레이드하면 MySQL 5.7 인스턴스에 존재하는 모든 실행 취소 테이블스페이스가 제거되고 두 개의 새로운 기본 실행 취소 테이블스페이스로 대체된다. 기본 실행 취소 테이블스페이스는 innodb_undo_directory 변수에 의해 정의된 위치에 생성된다. innodb_undo_directory 변수가 정의되지 않은 경우 데이터 디렉터리에 실행 취소 테이블스페이스가 생성된다. MySQL 5.7에서 MySQL 8.0으로 업그레이드하려면 MySQL 5.7 인스턴스의 실행 취소 테이블스페이스가 비어 있고 안전하게 제거될 수 있도록 느린 종료가 필요하다. 이전 MySQL 8.0 릴리스에서 MySQL 8.0.14 이상으로 업그레이드하는 경우 innodb_undo_tablespaces 설정이 2보다 큰 결과로 업그레이드 전 인스턴스에 존재하는 실행 취소 테이블스페이스는 사용자 정의 실행 취소 테이블스페이스로 처리된다. 업그레이드 후 각각 ALTER UNDO TABLESPACE 및 DROP UNDO TABLESPACE 구문을 사용하여 삭제되었다. MySQL 8.0 릴리스 시리즈 내에서 업그레이드할 때 항상 느린 종료가 필요한 것은 아니며, 이는 기존 실행 취소 테이블스페이스에 실행 취소 로그가 포함될 수 있음을 의미한다. 따라서 기존 실행 취소 테이블스페이스는 업그레이드 프로세스에 의해 제거되지 않는다.

MySQL 8.0.17부터 CREATE TABLESPACE ... ADD DATAFILE 절은 순환 디렉터리 참조를 허용하지 않는다. 예를 들어, 다음 명령문의 순환 디렉터리 참조(/../)는 허용되지 않는다. 제한사항에 대한 예외는 Linux에서 존재하며, 이전 디렉토리가 심볼릭 링크인 경우 순환 디렉토리 참조가 허용된다. 예를 들어, 위 예의 데이터 파일 경로는 any_directory가 심볼릭 링크인 경우 허용된다. (데이터 파일 경로가 '../'로 시작하는 것은 여전히 허용된다.) 업그레이드 문제를 방지하려면 MySQL 8.0.17 이상으로 업그레이드하기 전에 테이블스페이스 데이터 파일 경로에서 순환 디렉터리 참조를 제거하고, 테이블스페이스 경로를 검사하려면 정보 스키마 INNODB_DATAFILES 테이블을 쿼리한다.

MySQL 8.0.14에 도입된 회귀로 인해 분할된 테이블이 있고 lower_case_table_names=1로 설정된 인스턴스의 경우 MySQL 5.7 또는 MySQL 8.0.14 이전의 MySQL 8.0 릴리스에서 MySQL 8.0.16으로의 대소문자 불일치 문제로 인해 시스템 전체 업그레이드가 실패한다.

MySQL은 테이블 파티션의 테이블스페이스 이름과 파일 이름을 구성할 때 구분 기호 문자열을 사용한다. 다음과 같이 " #p# " 구분 기호 문자열은 파티션 이름 앞에 오고 " #sp# " 구분 기호 문자열은 하위 파티션 이름 앞에 위치한다. MySQL 업그레이드 작업 전 아래 상황을 확인하고 수정한다.

l 소문자 구분 기호와 파티션 이름을 보장하기 위해 디스크와 Data Dirctionray의 파일 이름을 파티션 한다.

l 이전 버그 수정으로 인해 발생한 관련 문제에 대한 데이터 사전의 파티션 메타데이터이다.

l 이전 버그 수정으로 인해 발생한 관련 문제에 대한 InnoDB 통계 데이터이다.

l 테이블스페이스 가져오기 작업 중에 디스크의 파티션 테이블스페이스 파일 이름을 확인하고 필요한 경우 소문자 구분 기호와 파티션 이름을 확인하기 위해 수정한다.

MySQL 8.0.21부터는 시작 시 또는 MySQL 5.7에서 업그레이드할 때 테이블스페이스 데이터 파일이 알 수 없는 디렉터리에 있는 것으로 발견되면 오류 로그에 경고가 기록된다. 알려진 디렉터리는 datadir, innodb_data_home_dir 및 innodb_directories 변수에 의해 정의된 디렉터리이다. 디렉터리를 알리려면 해당 디렉터리를 innodb_directories 설정에 추가한다. 디렉터리를 알리면 복구 중에 데이터 파일을 찾을 수 있다. 자세한 내용은 아래 링크를 참고한다.

l Tablespace Discovery During Crash Recovery : https://dev.mysql.com/doc/refman/8.0/en/innodb-recovery.html#innodb-recovery-tablespace-discovery

MySQL 8.0.30부터 innodb_redo_log_capacity 변수는 리두 로그 파일이 차지하는 디스크 공간의 양을 제어한다. 이 변경으로 인해 리두 로그 파일의 기본 수와 해당 위치도 변경되었다. MySQL 8.0.30부터 InnoDB는 데이터 디렉토리의 #innodb_redo 디렉토리에 32개의 리두 로그 파일을 유지한다. 이전에 InnoDB는 기본적으로 데이터 디렉터리에 두 개의 리두 로그 파일을 생성했으며, 리두 로그 파일의 수와 크기는 innodb_log_files_in_group 및 innodb_log_file_size 변수에 의해 제어되었다. 이 두 변수는 이제 더 이상 사용되지 않는다.

innodb_redo_log_capacity 설정이 정의되면 innodb_log_files_in_group 및 innodb_log_file_size 설정이 무시된다. 그렇지 않으면 해당 설정은 innodb_redo_log_capacity 설정(innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity)을 계산하는 데 사용된다. 해당 변수가 설정되지 않은 경우 리두 로그 용량은 innodb_redo_log_capacity 기본값인 104857600바이트(100MB)로 설정된다.

MySQL 5.7.35 이전에는 중복 또는 압축 행 형식이 있는 테이블의 인덱스에 대한 크기 제한이 없었다. MySQL 5.7.35부터 제한은 767바이트이며, 5.7.35 이전의 MySQL 버전에서 MySQL 8.0으로 업그레이드하면 액세스할 수 없는 테이블이 생성될 수 있다. 중복 또는 압축 행 형식의 테이블에 767바이트보다 큰 인덱스가 있는 경우 MySQL 8.0으로 업그레이드하기 전에 인덱스를 삭제하고 다시 생성해야 한다. 이러한 부분에 문제가 발생하면 아래와 같은 오류 메시지가 나타난다.

mysql> ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.

[SQL Changes]

MySQL 8.0.13부터 GROUP BY 절에 대해 더 이상 사용되지 않는 ASC 또는 DESC 한정자가 제거되었다. 이전에 GROUP BY 정렬에 의존했던 쿼리는 이전 MySQL 버전과 다른 결과를 생성할 수 있다. 지정된 정렬 순서를 생성하려면 ORDER BY 절을 사용해야 한다. GROUP BY 절에 ASC 또는 DESC 한정자를 사용하는 MySQL 8.0.12 이하에서 해당 형식의 쿼리를 사용한다면 수정해야 한다. 그렇지 않으면 MySQL 8.0.13 이상 복제본 서버로의 복제와 마찬가지로 MySQL 8.0.13 이상으로의 업그레이드가 실패할 수 있다.

MySQL 5.7에서는 예약되지 않았던 일부 키워드가 MySQL 8.0에서는 예약어로 사용된다. 이로 인해 이전에 식별자로 사용된 단어가 불법이 될 수 있다. 변경된 예약어는 아래 링크를 참고한다.

l Keywords and Reserved Words : https://dev.mysql.com/doc/refman/8.0/en/keywords.html

업그레이드한 후에는 애플리케이션 코드에 지정된 최적화 프로그램 힌트를 테스트하여 원하는 최적화 전략을 달성하는 데 힌트가 여전히 필요한지 확인하는 것이 좋다. 최적화 기능 향상으로 인해 특정 최적화 기능 힌트가 불필요해질 수 있다. 어떤 경우에는 불필요한 최적화 힌트가 역효과를 낳을 수도 있다.

MySQL 5.7에서 CONSTRAINT 기호 절 없이 InnoDB 테이블에 대한 FOREIGN KEY 정의를 지정하거나 기호 없이 CONSTRAINT 키워드를 지정하면 InnoDB가 생성된 제약 조건 이름을 사용하게 된다. 이 동작은 생성된 이름 대신 FOREIGN KEY index_name 값을 사용하는 InnoDB를 사용하여 MySQL 8.0에서 변경되었다. 제약 조건 이름은 스키마(데이터베이스)별로 고유해야 하기 때문에 변경으로 인해 스키마별로 고유하지 않은 외래 키 인덱스 이름으로 인해 오류가 발생한다. 이러한 오류를 방지하기 위해 새로운 제약 조건 명명 동작은 MySQL 8.0.16에서 되돌려졌으며 InnoDB는 다시 한번 생성된 제약 조건 이름을 사용한다. InnoDB와의 일관성을 위해 MySQL 8.0.16 이상 기반의 NDB 릴리스는 CONSTRAINT 기호 절이 지정되지 않거나 기호 없이 CONSTRAINT 키워드가 지정된 경우 생성된 제약 조건 이름을 사용한다. MySQL 5.7 및 이전 MySQL 8.0 릴리스를 기반으로 하는 NDB 릴리스는 FOREIGN KEY index_name 값을 사용했다. 이러한 변경 사항으로 인해 이전 외래 키 제약 조건 명명 동작에 의존하는 응용 프로그램에 대한 비호환성이 발생할 수 있다.

IFNULL() 및 CASE()와 같은 MySQL 흐름 제어 함수에 의한 시스템 변수 값 처리는 MySQL 8.0.22에서 변경되었다. 이제 시스템 변수 값은 상수가 아닌 동일한 문자 및 데이터 정렬의 열 값으로 처리된다. 이전에 성공했던 시스템 변수와 함께 이러한 함수를 사용하는 일부 쿼리는 나중에 잘못된 데이터 정렬 혼합으로 인해 거부될 수 있다. 이러한 경우 시스템 변수를 올바른 문자 집합과 데이터 정렬로 캐스팅해야 한다.

MySQL 8.0.28은 이전 MySQL 8.0 릴리스에서 CONVERT() 함수가 때때로 BINARY 값을 이진이 아닌 문자 집합으로 잘못 변환하는 것을 허용하는 문제를 수정했다. 이 동작에 의존할 수 있는 응용 프로그램을 확인하고 필요한 경우 업그레이드 전에 수정해야 한다. 특히 CONVERT()가 인덱스 생성 열에 대한 표현식의 일부로 사용된 경우 함수 동작의 변경으로 인해 MySQL 8.0.28로 업그레이드한 후 인덱스가 손상될 수 있다. 이러한 문제를 예방하기 위해 아래 목록을 적용해 볼 수 있다. 사전에 입력 데이터의 유효성을 검사할 수 없는 경우 MySQL 8.0.28로 업그레이드를 수행할 때까지 인덱스를 다시 생성하거나 테이블을 다시 작성해서는 안된다.

l 업그레이드를 수행하기 전에 잘못된 입력 데이터를 수정

l 인덱스를 삭제한 다음 다시 생성

l ALTER TABLE 테이블 FORCE를 사용하여 테이블을 강제로 재구축

l MySQL 소프트웨어를 업그레이드

[Changed Server Defaults]

아래표는 변경된 서버의 기본값이 요약되어 있다.

Option/Parameter	Old Default	New Default
Server changes
character_set_server	latin1	utf8mb4
collation_server	latin1_swedish_ci	utf8mb4_0900_ai_ci
explicit_defaults_for_timestamp	OFF	ON
optimizer_trace_max_mem_size	16KB	1MB
validate_password_check_user_name	OFF	ON
back_log	-1 (autosize) changed from : back_log = 50 + (max_connections / 5)	-1 (autosize) changed to : back_log = max_connections
max_allowed_packet	4194304 (4MB)	67108864 (64MB)
max_error_count	64	1024
event_scheduler	OFF	ON
table_open_cache	2000	4000
log_error_verbosity	3 (Notes)	2 (Warning)
local_infile	ON (5.7)	OFF
InnoDB changes
innodb_undo_tablespaces	0	2
innodb_undo_log_truncate	OFF	ON
innodb_flush_method	NULL	fsync (Unix), unbuffered (Windows)
innodb_autoinc_lock_mode	1 (consecutive)	2 (interleaved)
innodb_flush_neighbors	1 (enable)	0 (disable)
innodb_max_dirty_pages_pct_lwm	0 (%)	10 (%)
innodb_max_dirty_pages_pct	75 (%)	90 (%)
Performance Schema changes
performance-schema-instrument='wait/lock/metadata/sql/%=ON'	OFF	ON
performance-schema-instrument='memory/%=COUNTED'	OFF	COUNTED
performance-schema-consumer-events-transactions-current=ON	OFF	ON
performance-schema-consumer-events-transactions-history=ON	OFF	ON
performance-schema-instrument='transaction%=ON'	OFF	ON
Replication changes
log_bin	OFF	ON
server_id	0	1
log-slave-updates	OFF	ON
expire_logs_days	0	30
master-info-repository	FILE	TABLE
relay-log-info-repository	FILE	TABLE
transaction-write-set-extraction	OFF	XXHASH64
slave_rows_search_algorithms	INDEX_SCAN, TABLE_SCAN	INDEX_SCAN, HASH_SCAN
slave_pending_jobs_size_max	16M	128M
gtid_executed_compression_period	1000	0
Group Replication changes
group_replication_autorejoin_tries	0	3
group_replication_exit_state_action	ABORT_SERVER	READ_ONLY
group_replication_member_expel_timeout	0	5

[Server Defaults]

Character_set_server 시스템 변수 및 명령줄 옵션 --character-set-server의 기본값이 latin1에서 utf8mb4로 변경되었다. MySQL 5.7에서 MySQL 8.0으로 업그레이드해도 기존 데이터베이스 개체의 문자 집합은 변경되지 않는다. 하지만 Character_set_server를 명시적으로 설정하지 않는 한(이전 값 또는 새 값으로) 새 스키마는 기본적으로 utf8mb4를 사용한다. 가능하면 utf8mb4로 전환하는 것이 좋다.

collation_server 시스템 변수 및 명령줄 인수 --collation-server의 기본값이 latin1_swedish_ci에서 utf8mb4_0900_ai_ci로 변경되었다. 이는 서버의 기본 데이터 정렬, 즉 문자 집합의 문자 순서이다. 각 문자 집합에는 가능한 데이터 정렬 목록이 제공되므로 데이터 정렬과 문자 집합 사이에는 링크가 있다. 5.7에서 8.0으로 업그레이드해도 기존 데이터베이스 개체의 데이터 정렬은 변경되지 않지만 새 개체에는 적용된다.

licit_defaults_for_timestamp 시스템 변수의 기본값이 OFF(MySQL 레거시 동작)에서 ON(SQL 표준 동작)으로 변경되었다. 이 옵션은 원래 5.6에 도입되었으며 5.6 및 5.7에서는 OFF 되었다가 8.0에서 다시 ON으로 변경되었다.

Optimizer_trace_max_mem_size 시스템 변수의 기본값이 16KB에서 1MB로 변경되었다. 이전 기본값으로 인해 모든 중요 쿼리에 대해 최적화 프로그램 추적이 잘렸다. 이러한 변경으로 인해 대부분의 쿼리에 유용한 최적화 프로그램 추적이 보장된다.

verify_password_check_user_name 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 즉, verify_password 플러그인이 활성화되면 기본적으로 현재 세션 사용자 이름과 일치하는 비밀번호를 거부한다.

back_log 시스템 변수의 자동 크기 조정 알고리즘이 변경되었다. 자동 크기(-1) 값은 이제 max_connections 값으로 설정됩니다. 이는 50 + (max_connections / 5)로 계산된 값보다 크다. back_log는 서버가 들어오는 요청을 따라잡을 수 없는 상황에서 들어오는 IP 연결 요청을 대기열에 추가한다. 최악의 경우, 동시에 재연결을 시도하는 클라이언트 수가 max_connections인 경우 모두 버퍼링될 수 있으며 거부-재시도 루프가 방지된다.

max_allowed_packet 시스템 변수의 기본값이 4194304(4M)에서 67108864(64M)로 변경되었다. 이 더 큰 기본값의 주요 이점은 max_allowed_packet보다 큰 삽입 또는 쿼리에 대한 오류를 수신할 가능성이 적다는 것이다. 이전 동작으로 되돌리려면 max_allowed_packet=4194304로 설정한다.

max_error_count 시스템 변수의 기본값이 64에서 1024로 변경되었다. 이는 MySQL이 1000개의 행에 닿는 UPDATE 문과 같은 더 많은 수의 경고를 처리하고 그 중 많은 경고가 변환 경고를 제공하도록 보장한다. 이 변경 사항은 정적 할당이 없으므로 많은 경고를 생성하는 문의 메모리 소비에만 영향을 미친다.

event_scheduler 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 즉, 이벤트 스케줄러는 기본적으로 활성화되어 있다. 이는 "유휴 트랜잭션 종료"와 같은 SYS의 새로운 기능을 활성화하는 것이다.

table_open_cache 시스템 변수의 기본값이 2000에서 4000으로 변경되었다. 이는 테이블 액세스 시 세션 동시성을 높이는 것으로 사소한 변경 사항이다.

log_error_verbosity 시스템 변수의 기본값이 3(참고)에서 2(경고)로 변경되었다. 목적은 기본적으로 MySQL 8.0 오류 로그를 덜 장황하게 만드는 것이다.

[InnoDB Defaults]

innodb_undo_tablespaces 시스템 변수의 기본값이 0에서 2로 변경되었다. InnoDB에서 사용하는 실행 취소 테이블스페이스 수를 구성한다. MySQL 8.0에서 innodb_undo_tablespaces의 최소값은 2이며 더 이상 시스템 테이블스페이스에 롤백 세그먼트를 생성할 수 없다. 따라서 이는 5.7 동작으로 다시 되돌릴 수 없는 경우로, 이 변경의 목적은 실행 취소 로그(다음 항목 참조)를 자동으로 자르고 mysqldump와 같은 (가끔) 긴 트랜잭션에 사용되는 디스크 공간을 회수할 수 있도록 하는 것이다.

innodb_undo_log_truncate 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 활성화되면 innodb_max_undo_log_size에 정의된 임계값을 초과하는 실행 취소 테이블스페이스가 잘림으로 표시된다. 실행 취소 테이블스페이스만 잘라낼 수 있다. 시스템 테이블스페이스에 있는 실행 취소 로그 자르기는 지원되지 않는다. 5.7에서 8.0으로 업그레이드하면 실행 취소 테이블스페이스를 사용하도록 시스템이 자동으로 변환된다. 시스템 테이블스페이스 사용은 8.0에서 옵션이 아니다.

innodb_flush_method 시스템 변수의 기본값은 Unix 계열 시스템에서는 NULL에서 fsync로, Windows 시스템에서는 NULL에서 unbuffered로 변경되었다. 이는 실질적인 영향을 주지 않는것으로 용어 및 옵션 정리에 가깝다. Unix의 경우 이는 5.7에서도 기본값이 fsync였기 때문에 문서 변경일 뿐이다(기본 NULL은 fsync를 의미함). 마찬가지로 Windows에서 innodb_flush_method 기본값 NULL은 5.7에서 async_unbuffered를 의미했으며 8.0에서는 기본 unbuffered로 대체되었다. 이는 기존 기본 innodb_use_native_aio=ON과 결합하여 동일한 효과를 갖는다.

호환되지 않는 변경 innodb_autoinc_lock_mode 시스템 변수의 기본값이 1(연속)에서 2(인터리브)로 변경되었다. 기본 설정이 인터리브 잠금 모드로 변경된 것은 MySQL 5.7에서 발생한 기본 복제 유형이 명령문 기반에서 행 기반 복제로 변경된 것을 반영한다. 명령문 기반 복제에는 주어진 SQL 문 시퀀스에 대해 자동 증가 값이 예측 가능하고 반복 가능한 순서로 할당되도록 연속 자동 증가 잠금 모드가 필요한 반면, 행 기반 복제는 SQL 문의 실행 순서에 민감하지 않는다. 따라서 이 변경 사항은 명령문 기반 복제와 호환되지 않는 것으로 알려져 있으며 순차 자동 증분에 의존하는 일부 응용 프로그램이나 사용자 생성 테스트 모음을 손상시킬 수 있다. innodb_autoinc_lock_mode=1을 설정하여 이전 기본값을 복원할 수 있다.

innodb_flush_neighbors 시스템 변수의 기본값은 1(활성화)에서 0(비활성화)으로 변경된다. 이는 빠른 IO(SSD)가 이제 배포의 기본값이기 때문에 수행된다. 대부분의 사용자에게는 이로 인해 성능이 약간 향상될 것으로 예상된다. 느린 하드 드라이브를 사용하는 사용자는 성능 손실을 경험할 수 있으므로 innodb_flush_neighbors=1을 설정하여 이전 기본값으로 되돌리는 것이 좋다.

innodb_max_dirty_pages_pct_lwm 시스템 변수의 기본값이 0(%)에서 10(%)으로 변경되었다. innodb_max_dirty_pages_pct_lwm=10을 사용하면 InnoDB는 버퍼 풀의 10% 이상이 수정된('Dirty') 페이지를 포함할 때 플러시 활동을 증가시킨다. 이 변경의 목적은 보다 일관된 성능을 제공하는 대신 최대 처리량을 약간 낮추는 것이다.

innodb_max_dirty_pages_pct 시스템 변수의 기본값이 75(%)에서 90(%)으로 변경되었다. 이 변경 사항은 innodb_max_dirty_pages_pct_lwm에 대한 변경 사항과 결합되어 원활한 InnoDB 플러시 동작을 보장하고 플러시 버스트를 방지한다. 이전 동작으로 되돌리려면 innodb_max_dirty_pages_pct=75 및 innodb_max_dirty_pages_pct_lwm=0으로 설정한다.

[Performance Schema Defaults]

성능 스키마 MDL(메타 데이터 잠금) 계측은 기본적으로 켜져 있다. Performance-schema-instrument='wait/lock/metadata/sql/%=ON'에 대한 컴파일된 기본값이 OFF에서 ON으로 변경되었다. 이는 SYS에 MDL 지향 뷰를 추가하기 위한 활성화 도구이다.

성능 스키마 메모리 계측은 기본적으로 켜져 있다. Performance-schema-instrument='memory/%=COUNTED'에 대한 컴파일된 기본값이 OFF에서 COUNTED로 변경되었다. 서버 시작 후 계측이 활성화된 경우 집계 결과가 올바르지 않고 할당이 누락되었다가 여유 공간이 확보되면 마이너스 결과 값이 발생할 수 있으므로 이는 중요하다.

성능 스키마 트랜잭션 계측은 기본적으로 켜져 있습니다. Performance-schema-consumer-events-transactions-current=ON, Performance-schema-consumer-events-transactions-history=ON 및 Performance-schema-instrument='transaction%=ON'에 대한 컴파일된 기본값이 OFF에서 ON으로 변경되었다.

[Replication Defaults]

log_bin 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 즉, 바이너리 로깅이 기본적으로 활성화되어 있다. 거의 모든 프로덕션 설치에는 복제 및 특정 시점 복구에 사용되는 바이너리 로그가 활성화되어 있다. 따라서 기본적으로 바이너리 로그를 활성화하면 하나의 구성 단계가 제거되고 나중에 활성화하려면 mysqld를 다시 시작해야 한다. 기본적으로 이를 활성화하면 더 나은 테스트 적용 범위가 제공되고 성능 회귀를 더 쉽게 발견할 수 있다. server_id도 설정해야 한다. 8.0의 기본 동작은 ./mysqld --log-bin --server-id=1을 실행한 것과 같다. 8.0을 사용하고 있고 5.7 동작을 원하는 경우 ./mysqld --skip-log-bin --server-id=0을 실행할 수 있다.

server_id 시스템 변수의 기본값이 0에서 1로 변경되었다(log_bin=ON으로의 변경과 결합). 이 기본 ID로 서버를 시작할 수 있지만 실제로 중복된 서버 ID를 방지하려면 배포 중인 복제 인프라에 따라 서버 ID를 설정해야 한다.

log-slave-updates 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 이로 인해 복제본은 복제된 이벤트를 자체 바이너리 로그에 기록한다. 이 옵션은 그룹 복제에 필요하며 오늘날 표준이 된 다양한 복제 체인 설정에서 올바른 동작을 보장한다.

expire_logs_days 시스템 변수의 기본값이 0에서 30으로 변경되었다. 새로운 기본값 30은 mysqld가 30일보다 오래된 사용되지 않은 바이너리 로그를 주기적으로 제거하도록 한다. 이 변경은 복제 또는 복구 목적에 더 이상 필요하지 않은 바이너리 로그에 과도한 양의 디스크 공간이 낭비되는 것을 방지하는 데 도움이 된다. 이전 값 0은 자동 바이너리 로그 제거를 비활성화한다.

master_info_repository 및 Relay_log_info_repository 시스템 변수의 기본값이 FILE에서 TABLE로 변경된다. 따라서 8.0에서는 복제 메타데이터가 기본적으로 InnoDB에 저장된다. 이렇게 하면 기본적으로 충돌 방지 복제를 시도하고 달성하기 위한 안정성이 향상된다.

transaction-write-set-extraction 시스템 변수의 기본값이 OFF에서 XXHASH64로 변경되었다. 이 변경으로 인해 기본적으로 트랜잭션 쓰기 세트가 활성화된다. 트랜잭션 쓰기 세트를 사용하면 소스가 쓰기 세트를 생성하기 위해 약간 더 많은 작업을 수행해야 하지만 결과는 충돌 감지에 도움이 된다. 이는 그룹 복제에 대한 요구 사항이며 새로운 기본값을 사용하면 소스에서 바이너리 로그 쓰기 집합 병렬화를 쉽게 활성화하여 복제 속도를 높일 수 있다.

slave_rows_search_algorithms 시스템 변수의 기본값이 INDEX_SCAN, TABLE_SCAN에서 INDEX_SCAN, HASH_SCAN으로 변경되었다. 이 변경 사항은 기본 키 없이 테이블에 변경 사항을 적용하기 위해 복제본 적용자가 수행해야 하는 테이블 검색 횟수를 줄여 행 기반 복제 속도를 높인다.

slave_pending_jobs_size_max 시스템 변수의 기본값이 16M에서 128M으로 변경되었다. 이 변경으로 인해 다중 스레드 복제본에 사용할 수 있는 메모리 양이 늘어난다.

gtid_executed_compression_기간 시스템 변수의 기본값이 1000에서 0으로 변경되었다. 이 변경으로 인해 mysql.gtid_executed 테이블의 압축은 필요할 때만 암시적으로 발생한다.

[Group Replication Defaults]

group_replication_autorejoin_tries의 기본값이 0에서 3으로 변경되었다. 즉, 자동 재참여가 기본적으로 활성화되어 있음을 의미한다. 이 시스템 변수는 그룹이 추방되거나 group_replication_unreachable_majority_timeout 설정에 도달하기 전에 그룹의 대다수에 연결할 수 없는 경우 구성원이 그룹에 자동으로 다시 참여하기 위해 시도하는 횟수를 지정한다.

group_replication_exit_state_action의 기본값이 ABORT_SERVER에서 READ_ONLY로 변경되었다. 예를 들어 네트워크 오류가 발생한 후 구성원이 그룹을 종료하면 인스턴스가 종료되지 않고 읽기 전용이 된다.

group_replication_member_expel_timeout의 기본값이 0에서 5로 변경되었다. 그룹과의 연락이 두절된 것으로 의심되는 구성원은 5초 감지 기간 이후 5초 후에 제명 책임을 지게 된다.

innodb_dedicated_server라는 새 옵션의 경우 개발 서버나 개인 랩탑의 경우 ON을 OFF로 설정한다. 그 이유는 사용할 수 있는 모든 메모리를 사용하기 때문에 랩탑 같은 일반적인 공유 환경에서 메모리 부족 문제가 발생할 수 있기 때문이다. 하지만 프로덕션 환경의 경우 innodb_dedicated_server를 ON으로 설정하는 것이 좋다. ON으로 설정하면 다음 InnoDB 변수(명시적으로 지정하지 않은 경우)는 사용 가능한 메모리 innodb_buffer_pool_size, innodb_log_file_size 및 innodb_flush_method를 기반으로 자동 크기 조정된다. 작세한 내용은 아래 링크를 참고한다.

l Enabling Automatic Configuration for a Dedicated MySQL Server : https://dev.mysql.com/doc/refman/8.0/en/innodb-dedicated-server.html

Conclusion

대부분의 기본값은 개발 및 프로덕션 환경 모두에 적합하지만, 항상 예외는 발생할 수 있기 때문에 각자의 환경에 맞게 기본값을 적절히 수정해서 사용할 수 있도록 한다. MySQL 8.0에는 각 시스템 변수에 대해 가장 최근에 설정된 소스와 해당 값 범위를 보여주는 성능 스키마 Variable_info 테이블이 있다. 이는 구성 변수와 그 값에 대해 알아야 할 모든 것에 대한 SQL 액세스를 제공한다.

[참고자료]

l Changes in MySQL 8.0 : https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html

2023-09-13 / Sungwook Kang / http://sungwookkang.com

MySQL, 업그레이드 고려사항, MySQL8 변경사항

[Kubernetes] 쿠버네티스에서 POD(파드)란? 그리고 POD 생성하기

SungWookKang — Fri, 8 Sep 2023 15:39:34 +0900

[Kubernetes] 쿠버네티스에서 POD(파드)란? 그리고 POD 생성하기

l Kubernetes

파드(Pod)는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 도커가 가장 일반적으로 잘 알려진 컨테이너 런타임이지만, 쿠버네티스는 도커 외에도 다양한 컨테이너 런타임을 지원한다.

파드는 하나 이상의 컨테이너의 그룹이며 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 컨텐츠는 항상 함께 배치되고, 스케줄되며, 공유 컨텍스트에서 실행된다. 즉, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 컨테이너들의 집합과 비슷하다.

파드는 각 애플리케이션의 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너가 포함된다. 클라우드가 아닌 컨텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.

애플리케이션 컨테이너와 마찬가지로, 파드에는 파드 시작 중에 실행되는 초기화 컨테이너가 포함될 수 있다. 클러스터가 제공하는 경우, 디버깅을 위해 임시 컨테이너를 삽입할 수도 있다. 쿠버네티스에서는 이러한 파드를 생성하기 위한 방법으로 kubectl run, kubectl create, kubectl apply 로 3가지가 있다. 각 각의 특징에 대해서 알아본다.

[kubectl run]

kubectl run은 kubernetes 클러스터에서 파드나 작업을 생성하는 명령어이다. 가장 간단하게 pod를 만드는 방식이며, 실행 명령어 뒤에 각종 옵션 정보를 입력해서 생성한다. 가장 간편한 실행 방법인 반면 입력 정보가 남지 않기 때문에 재실행 및 문제가 발생했을 때 원인을 찾거나 해결 방법을 공유하는 등의 어려움이 있다. 일반적인 개발 단계에서 간편하게 pod를 생성할 때 유용하지만 많은 옵션을 함께 사용해야 할 경우 모든 명령어를 입력해야하기 때문에, yaml을 작성하여 사용하는 것이 일반적이다. 기본 구조는 아래와 같다.

Kubectl run [파드이름] –image=[이미지 이름]

아래 예시는 파드 생성시 실행할 이미지를 지정한다.

kubectl run nginx --image=nginx

아래 예시는 실행할 파드의 개수를 지정한다. Nginx 이미지를 사용하여 3개의 파드를 생성한다. 파드가 중간에 삭제되면 지정한 개수만큼 파드가 유지되도록 파드가 자동 생성된다.

kubectl run nginx --image=nginx --replicas=3

아래 예시는 파드를 생성할 때 포트 번호를 노출시킨다.

kubectl run nginx --image=nginx --port=80

아래 예시는 파드를 생성할 때 다양한 환경변수를 대입하여 파드를 실행한다.

kubectl run my-proxysql --image=my-proxysql --port=6033 --image-pull-policy=Never --restart=Never --env PROXY_ADMIN_PWD=pwd --env PROXY_ADMIN_ID=id

[kubectl create]

Kubectl create 명령은 kubernetes에서 새로운 리소스를 생성할 때 사용한다. 이 명령을 사용하면 yaml파일을 생성하지 않고도 명령어 자체에서 리소스를 생성할 수 있다. 기본구조는 아래와 같다.

kubectl create [리소스 종류] [리소스 이름]

아래 예시는 Nginx 이미지를 사용하는 my-nginx라는 pod 리소스를 생성한다.

kubectl create pod my-nginx --image=nginx

아래 예시는 Nginx 이미지를 사용하는 my-deployment 이름을 가진 Deployment 리소스를 생성한다.

Kubectl create deployment my-deployment --image=nginx

아래 예시는 80포트를 8080으로 매핑하는 my-service라는 이름의 ClusterIP 서비스 리소스를 생성한다.

Kubectl create service clusterip my-service --tcp=80:8080

아래 예시는 key1=value1, key2=value2 데이터를 가진 my-config 이름을 가진 ConfigMap 리소스를 생성한다.

kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

아래 예시는 password=1234데이터를 가진 my-secret 이름의 secret 리소스를 생성한다.

Kubectl create secret generic my-secret --from-literal=password=1234

아래 예시는 리소스를 생성하지 않고 생성 결과만 미리 확인한다.

kubectl create deployment my-deployment --image=nginx --dry-run

아래 예시는 파일(yaml 또는 json)을 사용하여 리소스를 생성한다.

kubectl create -f test.yaml

아래 예시는 리소스가 생성될 네임스페이스를 지정한다.

Kubectl create deployment my-deployment --image=nginx -n my-namespace

아래 예시는 컨테이너의 재시작 정책을 지정한다. 상태는 Always, OnFailure, Never 중 하나를 사용한다.

Kubectl create pod my-pod --image=nginx --restart-policy=OnFailure

[kubectl apply]

kubectl apply는 kubectl create와 동일하지만 가장 큰 차이점은 기존에 동일한 pod가 없다면 새로운 pod를 생성하고, 이미 동일한 pod가 존재하는 경우 기존 config와 비교하여 수정된 부분만 업데이트 한다.

[kubectl delete]

파드나 리소스를 삭제하기 위해서는 kubectl delete 명령을 사용한다. 기본 구조는 아래와 같다.

Kubectl delete [리소스 유형] [리소스 이름]

아래 예시는 nginx라는 파드를 삭제한다.

kubectl delete pod nginx

삭제할 때 다양한 옵션을 함께 사용할 수 있다.

l --all : 모든 리소스를 삭제

l --force : 강제로 삭제

l ---grace-period=<second> : 대기시간(초) 이후 삭제 설정

l --timeout=<second> : 명령이 실행될 때 대기할 최대 시간(초) 설정

2023-09-08 / Sungwook Kang / https://sungwookkang.com

Kubernetes, 쿠버네티스, pod, 파드, kubectl, create, delete, apply, 파드생성, 리소스 생성

[kubernetes] minikube에서 로컬 docker image 사용하기

SungWookKang — Thu, 7 Sep 2023 22:23:28 +0900

[kubernetes] minikube에서 로컬 docker image 사용하기

l Kubernetes, Docker

일반적으로 로컬 컴퓨터에서 쿠버네티스(Kubernetes)를 테스트할 때 minikube 환경을 많이 사용한다. 도커 데스크탑(docker desktop)이 설치된 환경에서도 쿠버네티스를 활성화하면 minikube가 활성화되어 동작한다. 이러한 환경에서 kubectl run 또는 yaml로 파드를 생성할 때, 로컬의 이미지를 사용할 경우 이미지를 가져올 수 없다는 오류와 함께 파드가 생성된 후 종료된다. 이번 포스트에서는 minikube 환경에서 로컬의 docker image를 사용하여 파드를 생성하는 방법을 알아본다.

로컬의 docker images에서 커스텀 빌드된 이미지 proxysql이 있다.

로컬의 도커 이미지를 사용하여 파드를 생성하면 오류가 발생한다.

kubectl run my-proxysql --image=proxysql

오류를 살펴보면 ErrImagePull이라는 상태 메시지를 볼 수 있는데, 상태를 자세히 확인하기 위해 kubectl describe 명령을 사용하여 상세 메시지를 확인한다.

kubectl describe pods my-proxysql

마지막에 오류 메시지를 보면, 이미지를 가져올 수 없어 발생한 오류라는 것을 확인할 수 있다.

Failed to pull image "proxysql": rpc error: code = Unknown desc = Error response from daemon: pull access denied for proxysql, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

일반적으로 생각할 때, 쿠버네티스를 사용하여 파드를 생성하면, 로컬의 이미지를 사용할 줄 알았는데 그렇지 않다. 그래서 minikube에서 로컬의 이미지를 사용할 수 있도록 minikube와 도커를 연결해야해는데, 다행히 쿠버네티스에서는 공식적으로 이러한 부분을 지원하고 있다.

아래 명령어를 사용하면, 현재 minikube에서 도커 host와 연결할 수 있는 방법을 알려준다. 결과 정보를 바탕으로 일일이 등록해도 되지만, 마지막줄에서 도커 호스트와 한번에 연결할 수 있는 명령어를 제공하기 때문에 그대로 복사해서 사용할 수 있다.

minikube docker-env

마지막 줄의 명령어를 실행하여 minikube에서 docker host에 연결한다.

eval $(minikube -p minikube docker-env)

명령어실행 후 도커에서 컨테이너를 조회해 보면 쿠버네티스의 컨테이너가 조회되는 것을 확인할 수 있다.

지금부터는 docker 이미지가 minikube에서 동작하는 driver(docker)와 연결되었기 때문에 이제부터 생성되는 docker image는 minikube 위에 생성하게 된다.

다시 한번 이미지를 빌드 한다. 이번에는 이전과 차별을 두기 위해 my-proxysql 이라는 이름으로 이미지를 생성하였다.

docker build -t my-proxysql .

아래 명령을 사용하여 minikube 이미지 목록을 확인한다. 방금 빌드한 이미지 목록을 확인할 수 있다.

minikube image ls --format table

아래 명령을 사용하여 파드를 실행한다. 이때 로컬의 이미지를 사용하도록 --image-pull-policy=Never 옵션을 함께 사용한다. 정상적으로 파드가 실행중인 것을 확인할 수 있다.

kubectl run my-proxysql1 --image=my-proxysql --image-pull-policy=Never --restart=Never

[참고자료]

l https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env

l https://www.baeldung.com/docker-local-images-minikube

l https://egkatzioura.com/2020/03/08/use-local-docker-image-on-minikube/

2023-09-07 / Sungwook Kang / https://sungwookkang.com

도커파일, dockerfile, minikube, Kubernetes, 로컬이미지 사용, 파드생성, pod create, 도커이미지

[Docker] 컨테이너실행시 sh 스크립트 호출과 매개변수 사용

SungWookKang — Thu, 7 Sep 2023 10:07:26 +0900

[Docker] 컨테이너실행시 sh 스크립트 호출과 매개변수 사용

l Docerk, Shell script

Dockerfil을 제작하면서, 컨테이너 실행시 특정 쉘 스크립트를 실행할 때, 쉘 스크립트 실행에 필요한 파라메터 값을 받아오지 못하는 문제가 있었다. (도커의 문제가 아닌 나의 코드 오류 문제) 단독으로 쉘 스크립트를 실행하면 정상적으로 실행되는데, 유독 컨테이너 실행시에만 그 값을 받지 못하였다. 해결 방법은 매우 간단하게 Dockerfile에서 사용한 ENV 환경변수를 그대로 쉘 스크립트에서 사용하면 되는거였다. (너무 어렵게 생각해서 문제를 해결하지 못한 것이었다.)

[잘못된 예시]

abc.sh에서 인풋 변수로 값을 사용할 수 있도록 read 명령어를 사용하였으며, 해당 변수로 받은 값을 출력하려고 작성.

abc.sh

#!/usr/bin/env bash

read var1
read var2

echo $var1
echo $var2

컨테이너 실행시 ENTRYPOINT에서 abc.sh를 실행하면서 파라메터를 전달하려고 작성.

Dockerfile

FROM ~~~~

ENV sh_var1 var1_value
ENV sh_var2 var2_value

ENTRYPOINT [“abc.sh”, “$sh_var1”, “$sh_var2”]

[정상 예시]

abc.sh

#!/usr/bin/env bash

#read var1 <- 인풋 변수 삭제
#read var2 <- 인풋 변수 삭제

echo $sh_var1 #<- dockerfile ENV 변수를 그대로 가져다 사용
echo $sh_var2 #<- dockerfile ENV 변수를 그대로 가져다 사용

Dockerfile

FROM ~~~~

ENV sh_var1 var1_value
ENV sh_var2 var2_value

ENTRYPOINT [“abc.sh”] #<- ENTRYPOINT호출시 sh 파일만 실행

물론 위 방법 외에도 다양한 사용법이 있을텐데, 우선 나의 코드에서는 각각의 변수를 호출해서 사용하려고 해서 발생한 문제로, 도커파일과 쉘 스크립트간의 매개변수 전달에 대한 이해가 부족해서 발생한 문제였다.

2023-09-07 / Sungwook Kang / https://sungwookkang.com

도커파일, dockerfile, 쉘스크립트, shell script, 매개변수, 도커환경변수, docker env, shell read

[Linux] 쉘(shell) 스크립트 기초

SungWookKang — Tue, 5 Sep 2023 19:20:47 +0900

[Linux] 쉘(shell) 스크립트 기초

l Linux

쉘 스크립트(shell script)는 셸이나 명령줄 인터프리터(Interpreter)에서 실행되도록 작성되었거나 한 운영 체제를 위해 쓰인 스크립트이다. 쉘 스크립트가 수행하는 일반 기능으로는 파일 이용, 프로그램 실행, 문자열 출력 등이 있다. 쉘 스크립트에서는 .sh라는 파일 확장자를 가진 파일이 특정 종류의 쉘 스크립트를 가리키는 것이 보통이지만, 대부분의 셸 스크립트는 파일 확장자를 지니지 않는다. 쉘 스크립트는 인터프리터 방식이므로 라인별로 읽어 실행함으로 속도가 다소 느리다는 단점이 있다.

쉘 스크립트라는 말은 유닉스 쉘을 위해 쓰인 스크립트를 말하는 반면, command.com(도스)과 cmd.exe (윈도우) 명령 줄 스크립트는 보통 배치 파일이라고 불린다. 최근엔 마이크로소프트가 개발한 CLI쉘인 파워쉘이 있다.

이번 포스트에서는 가장 널리 쓰이는 bash 쉘을 사용하는 스크립트를 설명한다.

첫 문장의 시작 (#!/bin/bash)

쉘 스크립트의 첫 번째줄에는 항상 #!/bin/bash가 기입되어 있어야 한다. 이 내용은 쉘이 실행될 때 어떤 쉘로 스크립트를 실행할지 정의하는 곳이다. 쉘에는 다양한 버전이 있다. 아래 예시는 hello.sh 라는 쉘 스크립트를 생성하고 실행하는 방법을 설명한다. 아래 스크립트를 hello.sh라는 파일을 생성하고 입력한다.

#!/bin/bash

echo "Hello, Shell Script"

아래 명령을 사용하여 스크립트를 실행하면 Hello, Shell Script를 출력한다. 스크립트 명령어에 대한 부분은 아래에서 자세히 설명하도록 한다. 만약 실행이 되지 않는다면 실행 권한이 없어 발생한것으로 chmod 777 hello.sh를 실행하여 권한 변경 후 실행한다.

$sh hello.sh

주석 처리 (#)

쉘 스크립트에서 단일 행 주석은 샵(#)을 사용한다.

#!/bin/bash

#여기는 주석입니다.
#주석은 실행되지 않습니다.

echo "Hello, Shell Script"

블록 주석은 : <<”END” ~ ~ END 를 사용한다.

#!/bin/bash

: << “END” #주석 시작
여기는 주석입니다.
주석은 실행되지 않습니다.
END #주석 끝

echo "Hello, Shell Script"

입력(read), 출력(echo)

echo는 출력, read는 입력을 할 수 있다. 위에서 이미 echo는 사용하였으므로 read를 사용하여 입력한 값을 출력하도록 스크립트를 작성해 본다. 입력 받은 값을 변수로 사용하려면 $기호를 사용한다.

#!/bin/bash
read input_value
echo "Hello, $input_value!"

스크립트를 실행하면 입력값이 발생할 때까지 실행되지 않고 대기한다. hahaha라고 입력하면 입력 받은 값이 변수로 사용되어 결과가 출력된다.

$sh hello.sh
hahaha

쉘 변수 특징

l 변수의 타입에는 로컬변수와 전역변수, 환경변수, 예약변수, 매개변수 등 다양하다.

l 변수는 대, 소문자를 구별한다.

l 변수명에는 영문자, 숫자, 언더바( _ )가 사용된다.

l 변수의 이름은 숫자를 포함할 수 있지만, 숫자로 시작할 수 없다.

l 변수에는 모든 값을 문자열로 저장된다.

l 변수에는 자료형을 기입하지 않기 때문에 어떠한 값도 입력할 수 있다. (변수에 타입을 지정할 수도 있다.)

l 값을 사용할 때는 변수명 앞에 특수문자 "$"를 사용한다. (Ex. echo ${data})

l 값을 대입(삽입)할 때는 특수문자 "$"를 사용하지 않는다. (Ex. data=mac)

l 변수를 생성할 때는 "=" 대입문자 앞뒤로 공백이 없어야 한다. (Ex. data="abcd") 문자열인 경우 “ “로 감싼다.

l 하나의 변수에 한 개의 값만 보존된다.

l 변수 값이 덮어 쓰기되는 것을 방지하기 위해서는 readonly를 사용한다.

l 변수를 unset으로 삭제할 수 있다. (readonly로 선언된 것은 삭제가 불가능하다.)

쉘 스크립트에서 시스템이 사용하는 예약어가 있다. 몇 가지 대표적인 예약어이다.

변수	설명
HOME	사용자 홈 디렉토리 의미
PATH	실행 파일의 경로
LANG	프로그램 실행 시 지원되는 언어
UID	사용자의 UID
SHELL	사용자가 로그인시 실행되는 쉘
USER	사용자 계정 이름
FUNCNAME	현재 실행되고 있는 함수 이름
TERM	로그인 터미널
Set	셸 변수를 출력하는 명령어
Env	환경 변수를 출력하는 명령어
Export	특정 변수의 범위를 환경 변수의 데이터 공간으로 전송하여 자식 프로세스에서도 특정 변수를 사용 가능하게 한다.
unset	선언된 변수를 제거

전역변수, 지역변수

쉘에서 선언된 변수는 기본적으로 전역변수(global variable)이며, 함수안에서 지역변수(local variable)로 사용할 수 있는데, 이때에는 local을 붙여서 사용한다. 함수안에서 local을 사용하지 않으면 전역 변수의 값을 덮어쓰게 된다.

#!/bin/bash

# 전역 변수 지정
string="hello shell, global variable"

function string_test() {
    # local을 붙여야 지역변수로 인식. 만약 local을 빼면 전역변수에 덮어쓰기로 적용
    local string="hello shell, local variable"
    echo ${string}
}

# 함수 호출
string_test # > hello shell, local variable
echo ${string} # > hello shell, global variabl

# 변수 초기화
unset string

변수 타입 지정

기본적으로 Bash는 문자열만 저장하지만 데이터 타입을 지정할 수도 있다.

변수타입	설명
declare -r	읽기 전용 타입
declare -i	정수형 타입
declare -a	배열 타입
declare -A	연관배열(MAP) 타입
declare -f	함수 타입
declare -x	환경변수(export) 지정으로 외부 환경에서도 이 변수를 사용할 수 있다.

읽기전용 변수 (readonly)

변수에 값을 덮어 쓸수 있지만 readonly로 지정한 경우 변수를 덮어쓸수 없다. 아래 예시는 readonly에서 변수 덮어쓰기를 시도할 때 발생한 오류를 확인할 수 있다.

#!/bin/bash

var="변수1"
VaR_2="변수2"
echo "Var_2=$VaR_2"

VaR_2="VaR_2를 변경합니다."
echo ${VaR_2}

readonly var
var="readonly var 변수를 변경해 봅니다."

변수 값의 치환

쉘 변수의 값을 치환할 때 사용하는 문법을 표로 정리하였다.

문법	설명
${var}	변수 값을 바꿔 넣는다.
${var:-word}	변수가 아직 세팅되지 않거나 공백 문자열의 경우 word를 반환한다. var에는 저장되지 않는다.
${var:=word}	변수가 아직 세팅되지 않거나 공백 문자열의 word를 반환한다. var에 저장된다.
${var:?word}	변수가 아직 세팅되지 않거나 공백 문자열의 경우 치환에 실패하고, 스탠다드 에러에 에러가 표시된다.
${var:+word}	변수가 세팅되지 않은 경우 word가 반환된다. var에는 저장되지 않는다.

#!/bin/sh

echo "1 - ${var:-wordSetInEcho1}"
echo "2 - var = ${var}"
echo "3 - ${var:=wordSetInEcho3}"
echo "4 - var = ${var}"
unset var
echo "5 - ${var:+wordSetInEcho5}"
echo "6 - var = $var"
var="newVarValue"
echo "7 - ${var:+wordSetInEcho7}"
echo "8 - var = $var"
echo "9 - ${var:?StandardErrorMessage}"
echo "10 - var = ${var}"

문자열 패턴 비교는 아래 조건을 사용할 수 있다.

문법	설명
${var%pattern}	끝에서 부터 word와 패턴이 일치하는 var의 최소 부분(첫번째 일치)을 제거하고 나머지를 반환
${var%%pattern}	끝에서 부터 word와 패턴이 일치하는 var의 최대 부분(마지막 일치)을 제거하고 나머지를 반환
${var#pattern}	처음 부터 word와 패턴이 일치하는 var의 최소 부분(첫 번째 일치)을 제거하고 나머지 부분을 반환
${var##pattern}	처음 부터 word와 패턴이 일치하는 var의 최대 부분(마지막 일치)을 제거하고 나머지 부분을 반환

환경 변수 (export)

쉘 스크립트에서 변수명 앞에 export를 붙여 환경변수(environment variable)로 사용할 수 있다. 다만 환경변수 사용시 시스템에 미리 정의된 예약변수와 겹치지 않게 주의한다. 실습을 위해 두 개의 파일을 준비한다.

shell1.sh

#!/bin/bash

echo ${export_variable}

shell2.sh

#!/bin/bash

#환경변수 선언
export export_variable="export test, hello shell"

#변수값을 받아서 사용할 스크립트 호출
/파일 경로/shell1.sh

shell2.sh를 실행한다. Export 변수의 값은 shell1.sh를 호출할 때 사용된다.

매개변수

프로그램에서 실행할 때 인자를 사용하듯 쉘 스크립트에서도 매개변수를 사용할 수 있다. 이 때 규칙이 있는데, 실행한 스크립트 이름은 ${0}, 이후 인자 값들은 ${1}. ${2}…으로 사용한다.

변수	기능
$0	스크립트명
$1 ~ $9	인수 1 번째부터 인수 9번째까지 사용
$#	스크립트에 전달될 인수의 수
$*	모든 인수를 모아 하나로 처리
$@	모든 인수를 각각 처리
$?	직전에 실행한 커멘드의 종료 값(0 성공, 1 실패)
$$	쉘 스크립트의 프로세스ID
$!	마지막으로 실행한 백그라운드 프로세스 ID

아래 스크립트는 매개변수를 입력 받아 어떻게 사용되는지 알아보는 예시이다.

#!/bin/sh

echo "\$0（script name）: $0"
echo "\$1（1st param）: $1"
echo "\$2（2nd param）: $2"
echo "\$#（number of param）: $#"
echo "\"\$*\": \"$*\""
echo "\"\$@\": \"$@\""
VAR="exit code is 0 "
echo $?

실행 결과는 아래와 같이 나타난다.

배열 (Array)

쉘 스크립트에서 배열은 1차원 배열만 지원하며 중괄호를 사용해야 한다. 배열 원소는 소괄호안에 공백으로 구분하며, 배열 안 원소는 문자열이든 숫자형이던 상관없이 쓸 수 있다.

#!/bin/bash

arr=("hello" "shell" 1 2 3 4 5)

echo "배열 전체 : ${arr[@]}"
echo "배열 원소의 갯수 : ${#arr[@]}"
echo "배열 첫번째 : ${arr}, 혹은 ${arr[0]}"
echo "4번 index를 갖는 배열의 원소 : ${arr[4]}"

arr[5]="four"

echo "4번째 index를 갖는 배열의 원소 : ${arr[4]}"

# 4번째 값 해제
unset arr[4]
echo "4번 배열 값 삭제 완료"
echo "4번 index를 갖는 배열의 원소 : ${arr[4]}"
echo "5번 index를 갖는 배열의 원소 : ${arr[5]}"

함수(function)

쉘 스크립트에서도 함수를 사용할 수 있다. 함수의 정의 형식은 아래와 같다. 주의할 점은 함수가 호출되기 전에 함수가 정의되어 있어야 하며 호출할 때는 괄호를 사용하지 않고 호출한다.

#!/bin/bash

function func(){
echo "func()"
}

#함수 호출
func

비교문(if..fi)

쉘에서는 비교문이 약간 특이하다. bash의 if문의 특이한 점은 fi 와 대괄호([ ]) 이다. 다른 언어와 달리 중괄호를 사용하지 않기 때문에 fi로 if문의 끝을 알려주어야 한다. 주의해야 할 점은 if문 뒤에 나오는 대괄호 [ ] 와 조건식 사이에는 반드시 공백이 존재해야 한다.

비교문에는 다양한 연산자를 사용할 수 있다.

연산자	설명
값1 -eq 값2	# 값이 같음(equal)
값1 -ne 값2	# 값이 같지 않음(not equal)
값1 -lt 값2	# 값1이 값2보다 작음(less than)
값1 -le 값2	# 값1이 값2보다 작거나 같음(less or equal)
값1 -gt 값2	# 값1이 값2보다 큼(greater than)
값1 -ge 값2	# 값1이 값2보다 크거나 같음(greater or equal)

문자열 비교

연산자	설명
문자1 = 문자2	# 문자1 과 문자2가 일치 (sql같이 = 하나만 써도 일치로 인식)
문자1 == 문자2	# 문자1 과 문자2가 일치
문자1 != 문자2	# 문자1 과 문자2가 일치하지 않음
-z 문자	# 문자가 null 이면 참
-n 문자	# 문자가 null 이 아니면 참
문자 == 패턴	# 문자열이 패턴과 일치
문자 != 패턴	# 문자열이 패턴과 일치하지 않음

논리 연산자

연산자	설명
조건1 -a 조건2	# AND
조건1 -o 조건2	# OR
조건1 && 조건2	# 양쪽 다 성립
조건1 \|\| 조건2	# 한쪽 또는 양쪽다 성립
!조건	# 조건이 성립하지 않음
true	# 조건이 언제나 성립
false	# 조건이 언제나 성립하지 않음

산술연산자 (쉘에서는 expr 숫자 연산자 숫자’ 형식으로 사용한다.)

연산자	의미	예시
+	덧셈	echo `expr 10 + 20` => 30
-	뺄셈	echo `expr 20 - 10` => 10
\*	제곱	echo `expr 11 \* 11` => 121
/	나눗셈	echo `expr 10 / 2` => 5
%	나머지	echo `expr 10 % 4` => 2
=	저장	a=$b b의 값은 a에 저장
==	동일	[ "$a" == "$b" ] $a과 $b가 동일하는 경우 TRUE가 반환
!=	다름	[ "$a" != "$b" ] $a과 $b가 동일하지 않는 경우 TRUE가 반환

예제로 살펴본다.

#!/bin/bash

function func(){
        a=10
        b=5

        if [ ${a} -eq ${b} ]; then
                echo "a와 b는 같다."
        fi

        if [ ${a} -ne ${b} ]; then
                echo "a와 b는 같지 않다."
        fi

        if [ ${a} -gt ${b} ]; then
                echo "a가 b보다 크다."
        fi

        if [ ${a} -ge ${b} ]; then
                echo "a가 b보다 크거나 같다."
        fi

       if [ ${a} -lt ${b} ]; then
                echo "a가 b보다 작다."
        fi

        if [ ${a} -le ${b} ]; then
                echo "a가 b보다 작거나 같다."
        fi

}

#함수 호출
func

여러 조건을 사용할때, 다른 언어에서는 else if역할을 하는 것을 쉘 스크립트에서는 elif라는 것을 사용하여 else if와 동일한 역할을 할 수 있다. elif[ 조건 ]; then 형식으로 사용한다. 만약 반복문에서 사용하여 조건이 참일때 반복문을 멈추고 싶을때 break라는 키워드를 사용하여 반복문을 멈출 수 있다.

#!/bin/bash

case ${1} in
        "linux") echo "리눅스" ;;
        "unix") echo "유닉스" ;;
        "windows") echo "윈도우즈" ;;
        "MacOS") echo "맥OS" ;;
        *) echo "해당없음" ;;
esac

파일 관련 조건문

쉘 스크립트는 명령어를 다루는 스크립트이기 때문에 파일이 존재하는지, 디렉토리가 존재하는지 등 파일과 관련된 조건 여부도 조건문을 통해 알 수 있다. 아래 표는 각 조건을 정리한 것이다. 참, 거짓을 판단할 때, 느낌표(!)를 사용하면 반대로 결과를 출력한다.

조건	설명
if [ -d ${변수} ]; then	${변수}의 디렉토리가 존재하면 true.
if [ ! -d ${변수} ]; then	${변수}의 디렉토리가 존재하지 않으면 true.
if [ -e ${변수} ]; then	${변수}라는 파일이 존재하면 true.
if [ ! -e ${변수} ]; then	${변수}라는 파일이 존재하지 않으면 true.
if [ -L ${변수} ]; then	파일이 symbolic link이면 true.
if [ -s ${변수} ]; then	파일의 크기가 0보다 크면 true.
if [ -S ${변수} ]; then	파일 타입이 소켓이면 true.
if [ -r ${변수} ]; then	파일을 읽을 수 있으면 true.
if [ -w ${변수} ]; then	파일을 쓸 수 있으면 true.
if [ -x ${변수} ]; then	파일을 실행할 수 있으면 true.
if [ -f ${변수} ]; then	파일이 정규 파일이면 true.
if [ -c ${변수} ]; then	파일이 문자 장치이면 true.
if [ ${변수1} -nt ${변수2}]; then	변수1의 파일이 변수2의 파일보다 최신 파일이면 true.
if [ ${변수1} -ot ${변수2}]; then	변수1의 파일이 변수2의 파일보다 최신이 아니면 true.
if [ ${변수1} -ef ${변수2}]; then	변수1의 파일과 변수2의 파일이 동일하면 true.

CASE문

일반적인 CASE 사용법과 비슷하지만 각 CASE 끝에 세미콜론을 2개씩 사용하는 특징이 있다. 그리고 CASE 끝은 ESAC로 닫아준다.

#!/bin/bash

DRINK="coffee"
case "$DRINK" in
    "beer") echo "맥주입니다"
    ;;
    "juice") echo "주스입니다"
    ;;
    "coffee") echo "개발자에겐 카페인 필수!"
    ;;
esac

CASE에서 OR 연산도 가능하다.

COUNTRY=korea

case $COUNTRY in
"korea"|"japan"|"china") # or 연산도 가능하다
    echo "$COUNTRY is Asia"
    ;;
"USA"|"Canada"|"Mexico")
    echo "$COUNTRY is Ameria"
    ;;
* )
    echo "I don't know where is $COUNTRY"
    ;;
esac

반복문(for)

반복문을 빠져나갈때에는 break를 사용하고, 현재 반복분이나 조건을 건너뛸때에는 continue를 사용한다.

#!/bin/bash

# 초기값; 조건값; 증가값을 사용한 정통적인 for문
for ((i=1; i<=4; i++)); do
echo $i
done

반복문(for in)

#!/bin/bash

function func(){
        echo "사용예1"
        for i in 1 2 3 4 5
        do
                echo "${i}"
        done

        echo "사용예2"
        list="1 2 3 4 5"
        for i in ${list}
        do
                echo "${i}"
        done

        echo "사용예3"
        for i in {1..5}
        do
                echo "${i}"
        done

        echo "사용예4: 크기를 2만큼 증가시키면서 출력"
        for i in {1..5..2}
        do
                echo "${i}"
        done

        echo "사용예5: 배열을 이용"
        arr=(1 2 3 4 5)
        for i in "${arr[@]}"
        do
                echo "${i}"
        done

      echo "사용예6: C와 유사한 형식의 for문"
        for ((i=0; i<5; i++)); do
                echo "${i}"
        done
}

#함수 호출
func

반복문 (while)

수행 조건이 true일때 실행되는 반복문이다.

count=0
while [ ${count} -le 5 ];
do
echo ${count}
count=$(( ${count}+1 ))
done

이중 괄호를 사용하면 논리 기호로도 사용 가능하다.

count=0
while (( ${count} <= 5 )); # 이중괄호 사용하면 논리기호 사용 가능
do
echo ${count}
count=$(( ${count}+1 ))
done

반복문(until)

수행 조건이 false 일때 실행되는 반복문이다. 조건이 While의 반대라고 생각하면 된다.

count2=10

until [ ${count2} -le 5 ]; do
echo ${count2}
count2=$(( ${count2}-1 ))
done

종료 상태 코드

명령어가 실패할 경우 리턴되는 결과에 따라 다른 동작을 하려면 명령어의 종료 코드를 반환 받아 사용하면 된다. 명령어의 종료 코드는 $?를 사용하여 가장 최근 실행한 명령어의 종료 코드를 받을 수 있다. 정상적인 종료는 0이 반환되며 0이 아닌 값은 오류라고 판단할 수 있다. 아래 표는 종료 코드에 따른 설명을 정리한 것이다.

종료 코드	설명
0	성공 (Success)
1	일반적 오류 (Catchall for general errors)
2	쉘 내장 명령의 틀린 사용 (Misuse of shell builtins)
126	파일이 실행 가능하지 않음 (Command invoked cannot execute)
127	명령어를 찾을 수 없음 (Command not found)
128	종료할 때 잘못된 인수 적용 (Invalid argument to exit)
128+n	치명적인 시그널 n 에러 (Fatal error signal “n”)
130	[Ctrl + C]키 조합에 의한 종료 (Script terminated by Control-C)

쉘 이스케이프 문자

명령어	설명
\f	앞 문자열만큼 열을 밀어서 이동한다.
\n	새로운 줄로 바꾼다.
\r	앞 문자열의 앞부분 부터 뒷문자열 만큼 대체하고 반환한다.
\t	탭 만큼 띄운다.

이 외에도 다양한 쉘 명령이 있다. 쉘 명령을 잘 활용하면 리눅스 환경에서 시스템 관련 다양한 정보들을 스크립트로 얻을 수 있다.

[참고자료]

l https://ko.wikipedia.org/wiki/%EC%85%B8_%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8

l https://reakwon.tistory.com/136

l https://inpa.tistory.com/entry/LINUX-%EC%89%98-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%ED%95%B5%EC%8B%AC-%EB%AC%B8%EB%B2%95-%EC%B4%9D%EC%A0%95%EB%A6%AC

l https://engineer-mole.tistory.com/200

2023-09-05 / Sungwook Kang / https://sungwookkang.com

리눅스, Linux, 쉘스크립트, 쉘사용법, 쉘명령어, shell command, shell script

[Linux] Alpine Linux (알파인 리눅스) 는 무엇일까?

SungWookKang — Mon, 4 Sep 2023 14:30:32 +0900

[Linux] Alpine Linux (알파인 리눅스) 는 무엇일까?

l Linux

컨테이너 환경으로 다양한 서비스를 빌드하다보니, DevOps 팀에서 베이스 이미지를 ubuntu나 centos 대신 alpine(알파인) 리눅스를 사용하는 것이 어떻겠냐는 제안을 받았다. 리눅스는 다양한 커널 기반으로 배포판을 가지고 있다. 이번 포스트에서는 Alpine Linux (이하 “알파인 리눅스”)에 대해서 알아본다.

[개요]

알파인 리눅스는 리눅스 커널 기반으로 한 리눅스 배포판 중 하나이며 MIT 라이선스 아래에 배포되었으며 LEAF 리눅스의 포크 버전이다. 알파인 리눅스는 다른 배포판과 다르게 Musl과 BusyBox를 기반으로 한다. 알파인 리눅스의 컨셉은 LEAF 리눅스와 동일하게 “작고”, “보안이 뛰어나고”, “간단함”을 기반으로 한다. 하지만 시간이 지나면서 다양한 사람들에 의해 알파인 리눅스만의 형태로 발전되고 있다.

[특징]

장점

l 가볍고, 간단하며 보안성을 목적으로 개발한 배포판

l 용량을 줄이기 위해 시스템의 기본 C runtime을 glibc 대신 musl libc를 사용

l 다양한 쉘 명령어는 GNU util대신 busybox를 탑재

l 초경량(약 80MB) 배포판으로 임베디드나 네트워크 서버 등 특정 용도에 적합.

l 특히 도커(Docker) 공식 이미지로 채택되어 5MB 크기의 리눅스 이미지로 유명함

l 보안에 염두해두고 설계되어 모든 바이너리는 독립적인 실행 파일(PIE)로 컴파일

단점

l 리눅스 표준인 GNU 도구가 없어가나 Busybox가 대신 들어가 있어, 쉘 명령어를 실행할 때 주의가 필요

l 라이트한 대신 패키지가 설치되어 있지 않아 직접 설치해주어야 하는 것들이 많다.

l 이것저것 설치하다보면 표준 리눅스 배포판과 거의 비슷한 용량이 되기도 한다. (개인적인 생각)

BusyBox란?
BusyBox란 일종의 명령어 모음집으로 박스안에 필요한 응용 프로그램들을 담아 놓은 것이다. 리눅스에서 사용되는 각 명령어들만 모아 놓아도 상당한 크기를 차지할 수 있는데, BusyBox에서는 각각에 함수들을 최소 사이즈로 다시 구현하였다. 그렇기 때문에 Embbeded(임베디드), 네트웍 서버 등 특정 용도에 적합하며 도커 컨테이너의 OS로 많이 사용한다.

[자주 사용되는 명령어]

알파인 리눅스에서는 패키지 인스톨러가, 전통적인 yum, apt 대신에 apk를 사용한다. 그리고 기본 쉘이 배시가 아니라 애쉬(ash)이다.

명령	설명
apk update	패키지 저장소 목록을 업데이트
apk search <package>	패키지 저장소 목록에서 패키지를 검색. v 옵션으로 설명 확인 가능.
apk add <package[=version]>	패키지를 설치. 버전을 명시하여 설치 가능.
apk del <package>	특정 패키지를 제거
apk cache clean	패키지 캐시를 모두 제거
apk cache -v sync	패키지 캐시를 초기화하고 부족한 패키지를 자동으로 다운로드
apk stats	현재 패키지 저장소에서 사용가능한 패키지나 설치된 패키지 등의 정보를 출력
apk fix	복구가 필요한 패키지를 복구하거나 종속성을 제외하고 업그레이드 진행.
apk info	현재 설치된 모든 패키지 정보 나열. -L 옵션을 사용하면 패키지내 파일 정보 출력.

[왜 컨테이너에서 알파인 리눅스를 사용할까?]

지극히 개인적인 생각이다. 컨테이너 이미지 파일을 만들 때, 베이스 이미지 위에 필요한 다양한 패키지를 설치하게 된다. 당연히 베이스 이미지 + 기타 필요한 패키지 크기만큼 이미지 사이즈가 되므로 빌드 후 용량도 커지게 된다. 그리고 이를 보관 및 배포하기 위해 스토리지 비용 및 네트워크 비용이 증가할 수 있다. 사실 스토리지 비용은 컴퓨팅 비용중에 가장 저렴한 부분 중 하나이다. 그래서 요즘은 용량 고민은 많이 하지 않는 편이다. 특히 온프레미스 환경에서 직접적으로 모든 것을 운용할 때에는 더더욱 그렇다. 하지만 클라우드 환경에선, 모든것이 비용으로 청구되기 때문에 최소한의 사이즈로 운영하면 비용 최적화에 많은 도움이 될 수 있을 것이라 생각한다.

[참고자료]

l Alpine Linux:Overview : https://wiki.alpinelinux.org/wiki/Alpine_Linux:Overview

l Alpine Linux : https://namu.wiki/w/Alpine%20Linux

2023-09-04 / Sungwook Kang / https://sungwookkang.com

리눅스, Linux, 알파인 리눅스, Apline Linux, APK 명령어, 리눅스 배포판

[MySQL] 성능 모니터링을 위한 Performance_Schema 개념

SungWookKang — Sat, 2 Sep 2023 06:11:53 +0900

[MySQL] 성능 모니터링을 위한 Performance_Schema 개념

l Version : MySQL 5.X, 8.X

MySQL에서 다양한 성능 및 관리 지표를 얻기 위해 사용하는 정보는 performance_schema (이하 “성능 스키마”)와 information_schema이다. 이번 포스트에서는 performance_schema에 관한 전체적인 개념을 다루며 각 항목에 대한 자세한 세부 내용은 별도 포스팅 한다.

MySQL performance_schema는 로우레벨에 실행되며, 런타임으로 서버 내부를 검사한다. 사용자가 자주 사용하는 것은 디폴트로 활성화되어 있기 때문에 따로 설정하지 않아도 정보를 볼 수 있지만, 그 외에는 필요에 따라 설정을 활성화해야 한다. performance_schema는 정보를 수집하는 instruments와 수집한 정보를 저장하는 consumers를 설정하여 이용하는 구조이다.

l Performance_schema : 성능 데이터 검사에 사용.

l Information_schema : 메타데이터 검사에 사용

	performance_schema	information_schema
주요 목적	성능 데이터의 수집	메타 데이터의 수집
애플리케이션	성능 개선	감시 도구이자 관리 도구
도입된 버전	5.5	5
SQL 표준	MySQL 전용 기능	O
설치방법	스토리지 엔진으로 설치	infomation schema API
데이터 수집 방법	mysqld 내부에서 런타임 수집	information schema 테이블 접근 시
통상적인 오버 헤드	있음	없음
출력에 의한 오버 헤드	적음	많음

Information_schema의 경우 DROP DATABASE 명령으로 삭제할 수 없다. 그 이유는 SYSTEM VIEW 이기 때문이다. 따라서 일반 사용자에게 all privileges on *.* 권한을 주더라도 삭제할 수 없다. 각 스키마의 table_type은 아래와 같다.

l Information_schema : SYSTEM VIEW

l mysql : BASE TABLE

l performance_schema : BASE TABLE

l sys : VIEW or BASE TABLE

performance_schema 이벤트는 서버의 바이너리 로그(데이터 수정을 설명)에 기록된 이벤트 및 이벤트 스케줄러 이벤트(저장 프로그램 유형)와 다르다. 성능 스키마 이벤트는 MySQL 서버의 특정 인스턴스에만 적용된다. 성능 스키마 테이블은 서버에 로컬로 간주되며 해당 테이블에 대한 변경 사항은 바이너리 로그에 복제되거나 기록되지 않는다.

[Performance_Schema 스토리지 엔진]

performance_schema 스토리지 엔진은 서버 소스 코드의 "계측 지점(Instrumentation Point)"을 사용하여 이벤트 데이터를 수집한다. 수집된 이벤트는 Performance_schema 데이터베이스의 테이블에 저장된다. 이러한 테이블은 다른 테이블과 마찬가지로 SELECT 문을 사용하여 쿼리할 수 있다. 그리고 성능 스키마의 테이블은 지속적인 온디스크 스토리지를 사용하지 않는 인메모리 테이블이기 때문에, 수집된 내용은 서버 시작 시 다시 채워지고 서버 종료 시 삭제된다.

아래 쿼리를 사용하여 performance_schema는 어떤 스토리지 엔진을 사용하는지 확인할 수 있다.

SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE = 'PERFORMANCE_SCHEMA';

결과를 살펴보면 전용 PERFORMANCE_SCHEMA 스토리지 엔진을 사용하는 것을 확인할 수 있으며, Transactions 항목을 보면 NO 로 되어 있으므로 SQL을 사용할 수는 있지만 InnoDB 와는 다르게 Transaction 은 지원하지 않는다는 것을 알 수 있다.

성능 스키마 구성은 SQL 문을 통해performance_schema 데이터베이스의 테이블을 업데이트하여 동적으로 수정할 수 있다. 구성 변경은 데이터 수집에 즉시 영향을 미친다. 데이터 수집은 계측을 추가하기 위해 서버 소스 코드를 수정하는 방식으로 구현된다. 복제나 이벤트 스케줄러와 같은 다른 기능과 달리 성능 스키마와 관련된 별도의 스레드가 없다

[Performance_Schema 동작 방식]

Performance_schema가 동작은 두 가지로 나눌 수 있다.

l Instrument(인스트루먼트) : 정보를 얻고자 하는 MySQL 코드를 나타냄

l Consumer(컨슈머) : 어떤 코드를 수행하였는지에 대한 정보를 저장

Instrument(인스트루먼트)

performance_schema의 setup_instruments 테이블에는 지원되는 모든 인스트루먼트 목록이 포함되어 있으며, 모든 인스트루먼트 명은 슬래시로 구분해서 구성되어 있다. 몇 가지 예시를 살펴보자.

l statement/sql/select

l wait/synch/mutex/innodb/autoinc_mutex

인스트루먼트 이름의 가장 왼쪽이 인스트루먼트의 종류를 의미한다. 따라서 위의 예시에서 statement는 인스트루먼트가 sql 문장임을 나태내고 있으며, wait/ 은 대기 관련된 내용을 나타내고 있다. 인스트루먼트에서 수집할 수 있는 성능 정보 항목은 performance_schema.setup_instruments 에서 확인 할 수 있다. 그룹별로 몇 개의 인스투르먼트가 있는지 확인한다.

select substring_index(name, '/', 1) as category, count(*) from setup_instruments group by substring_index(name, '/', 1);

인스트루먼트의 상세 목록은 아래 쿼리를 사용한다. MySQL 5.7 버전에서는 1032개의 인스트루먼트가 있다.

select * from performance_schema.setup_instruments;

Consumer(컨슈머)

컨슈머는 인스트루먼트가 정보를 보내는 대상을 의미한다. Performance_schema는 인스트루먼트 결과를 다양한 테이블에 저장하게 된다. performance_schema의 종류는 아래 쿼리로 확인할 수 있으며, 각 테이블의 내용은 SELECT 구문으로 조회할 수 있다. 이번 포스트에서는 각 테이블의 기능 및 역할을 설명하지는 않는다. MySQL 5.7 기준으로 89개의 테이블이 있다. MySQL 8.0의 경우에는 110개 테이블이 존재한다. 버전별로 특성이 있기 때문에 잘 구분해서 사용할 수 있도록 한다.

use performance_schema;
show tables;

[Performance_Schema 활성화]

인스트루먼트를 활성화하거나 비활성화 하는 방법은 performance_schema에서 수집하는 성능 지표 항목에 따라 활성 비활성을 할 수 있다. 아래 쿼리로 목록을 조회하고, 결과를 살펴보면 ENABLED 컬럼의 결과로 활성화 여부를 확인할 수 있다.

select * from performance_schema.setup_instruments;

setup_instruments 테이블에서는 ENABLED와 TIMED 칼럼을 업데이트하여 기능을 활성화할 수 있습니다. UPDATE 문으로 이들 값을 'YES'로 변경하면 활성화되고, 'NO'로 변경하면 비활성화된다. setup_instruments의 TIMED 칼럼값을 'YES'로 변경하여 활성화하면 instruments의 타이밍 정보를 수집할 수 있다. memory 카테고리의 instruments는 계측하는 구조가 없으므로 TIMED 칼럼을 'YES'로 UPDATE해도 쿼리는 성공하지만 카테고리 레코드 값은 'NO'로 남아 있어 활성화할 수 없다.

update performance_schema.setup_instruments set ENABLED='YES', TIMED='YES' where name='statement/sql/select';

인스트루먼트의 활성/비활성화를 쿼리로 업데이트한 경우, 영구적이지 않기 때문에 MySQL 서버 재시작시 다시 적용해주어야 한다. 그렇기 때문에 영구 적용을 위해서는 my.cnf에 시스템 변수로 설정한다.

mysql.cnf

performance-schema-instrument='wait/synch/mutex/sql/LOCK_status=ON'
performance-schema-instrument='wait/synch/mutex/innodb/autoinc_mutex=ON'

컨슈머를 활성화하는 방법도 인스트루먼트와 유사하게 performance_schema.setup_consumers 테이블을 update하거나 my.cnf 시스템 변수에 등록한다.

[참고자료]

l Chapter 1 MySQL Performance Schema : https://dev.mysql.com/doc/mysql-perfschema-excerpt/8.0/en/performance-schema.html

l MySQL Performance Schema - 성능 스키마 : https://hoing.io/archives/3811

l MySQL performance-schema-instruments 사용에 따른 성능 영향 실험 : https://engineering.linecorp.com/ko/blog/mysql-research-performance-schema-instruments#:~:text=performance_schema%EB%8A%94%20%EC%A0%95%EB%B3%B4%EB%A5%BC%20%EC%88%98%EC%A7%91,%EC%84%A4%EC%A0%95%ED%95%98%EC%97%AC%20%EC%9D%B4%EC%9A%A9%ED%95%98%EB%8A%94%20%EA%B5%AC%EC%A1%B0%EC%9E%85%EB%8B%88%EB%8B%A4.

2023-09-02 / Sungwook Kang / http://sungwookkang.com

MySQL, 성능 모니터, performance_schema, 성능스키마, MySQL모니터링, MySQL 시스템 정보 수집

[MySQL] “innodb_table_stats” not found 오류와 예상하지 못한 사이드 이펙트

SungWookKang — Fri, 1 Sep 2023 11:09:23 +0900

[MySQL] “innodb_table_stats” not found 오류와 예상하지 못한 사이드 이펙트

l Version : MySQL 5.7

MySQL 5.7에서 서비스 재시작 후 아래와 같은 오류가 로그에 잔뜩 쌓여있다. MySQL 에러 로그 위치는 일반적으로 아래와 같다.

sudo cat /var/log/mysql/error.log

2023-08-31T05:15:56.437819Z 2598 [ERROR] InnoDB: Table `mysql`.`innodb_table_stats` not found.
2023-08-31T05:15:56.437825Z 2598 [ERROR] InnoDB: Fetch of persistent statistics requested for table `XXXX`.`wp_46549_XXXXX ` but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

서비스를 재시작 했을 뿐인데 왜 이와 같은 로그가 발생한 것일까? 그 이유를 살펴보니 MySQL 5.6부터는 mysql database에 통계정보나 slave 관련 정보를 저장하기 위해 새롭게 InnoDB 테이블이 추가되었다.

l innodb_index_stats

l innodb_table_stats

l slave_master_info

l slave_relay_log_info

l slave_worker_info

MySQL 5.5의 데이터를 MySQL 5.6이나 MySQL 5.7로 업그레이드 했을때, mysql_upgrade 작업을 추가로 해주지 않으면 mysql database 구조는 5.5로 되돌아간다. 그렇기 때문에 반드시 mysql_upgrade를 진행해 주어야 한다.

위 발생하는 오류를 해결하기 위해서는 아래 방법을 실행한다.

1. 관련 테이블 삭제

USE mysql;
DROP TABLE innodb_index_stats;
DROP TABLE innodb_table_stats;
DROP TABLE slave_master_info;
DROP TABLE slave_relay_log_info;
DROP TABLE slave_worker_info;

2. MySQL 서비스 중지 후 mysql database에 존재하는 ibd 파일 삭제 (frm 파일은 DROP TABLE 시 삭제되었음)

cd /var/lib/mysql/mysql/

rm -rf innodb_index_stats.ibd
rm -rf innodb_table_stats.ibd
rm -rf slave_master_info.ibd
rm -rf slave_relay_log_info.ibd
rm -rf slave_worker_info.ibd

3. MySQL 서비스 시작

4. mysql 강제 업그레이드를 진행한다. 이 작업을 통해서 존재하지 않는 5개 테이블이 새로 생성된다.

mysql_upgrade –force -uroot –p

MySQL 업그레이드가 진행되면 아래와 같은 메시지들이 출력되며 업그레이드를 진행한다. 전체 스키마가 진행되는 모든 로그가 출력되기 때문에 테이블이 많은 데이터베이스라면 시간이 오래 걸린다. (나의 경우 테이블 갯수가 수 십만개 존재하는 데이터베이스였다.)

root@XXXXX:/var/lib/mysql/mysql# mysql_upgrade --force -uroot -p
Enter password:
Checking server version.
Running queries to upgrade MySQL server.
mysql_upgrade: [ERROR] 1146: Table 'mysql.plugin' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.servers' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_topic' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_category' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_relation' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_keyword' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_name' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_transition' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_transition_type' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_leap_second' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.gtid_executed' doesn't exist
mysql_upgrade: [ERROR] 1243: Unknown prepared statement handler (stmt) given to EXECUTE
mysql_upgrade: [ERROR] 1243: Unknown prepared statement handler (stmt) given to DEALLOCATE PREPARE
mysql_upgrade: [ERROR] 1146: Table 'mysql.server_cost' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.server_cost' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.engine_cost' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.engine_cost' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.plugin' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.servers' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.gtid_executed' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_category' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_topic' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_topic' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_category' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_relation' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.help_keyword' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.plugin' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.servers' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_leap_second' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_name' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_transition' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.time_zone_transition_type' doesn't exist
mysql_upgrade: [ERROR] 1146: Table 'mysql.servers' doesn't exist
Checking system database.
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.engine_cost
Error    : Table 'mysql.engine_cost' doesn't exist
status   : Operation failed
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.gtid_executed
Error    : Table 'mysql.gtid_executed' doesn't exist
status   : Operation failed
mysql.help_category
Error    : Table 'mysql.help_category' doesn't exist
status   : Operation failed
mysql.help_keyword
Error    : Table 'mysql.help_keyword' doesn't exist
status   : Operation failed
mysql.help_relation
Error    : Table 'mysql.help_relation' doesn't exist
status   : Operation failed
mysql.help_topic
Error    : Table 'mysql.help_topic' doesn't exist
status   : Operation failed
mysql.innodb_index_stats                           OK
mysql.innodb_table_stats                           OK
mysql.ndb_binlog_index                             OK
mysql.plugin
Error    : Table 'mysql.plugin' doesn't exist
status   : Operation failed
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.server_cost
Error    : Table 'mysql.server_cost' doesn't exist
status   : Operation failed
mysql.servers
Error    : Table 'mysql.servers' doesn't exist
status   : Operation failed
mysql.slave_master_info                            OK
mysql.slave_relay_log_info                         OK
mysql.slave_worker_info                            OK
mysql.slow_log                                     OK
mysql.tables_priv                                  OK
mysql.time_zone
Error    : Table 'mysql.time_zone' doesn't exist
status   : Operation failed
mysql.time_zone_leap_second
Error    : Table 'mysql.time_zone_leap_second' doesn't exist
status   : Operation failed
mysql.time_zone_name
Error    : Table 'mysql.time_zone_name' doesn't exist
status   : Operation failed
mysql.time_zone_transition
Error    : Table 'mysql.time_zone_transition' doesn't exist
status   : Operation failed
mysql.time_zone_transition_type
Error    : Table 'mysql.time_zone_transition_type' doesn't exist
status   : Operation failed
mysql.user                                         OK

Repairing tables
mysql.engine_cost
Error    : Table 'mysql.engine_cost' doesn't exist
status   : Operation failed
mysql.gtid_executed
Error    : Table 'mysql.gtid_executed' doesn't exist
status   : Operation failed
mysql.help_category
Error    : Table 'mysql.help_category' doesn't exist
status   : Operation failed
mysql.help_keyword
Error    : Table 'mysql.help_keyword' doesn't exist
status   : Operation failed
mysql.help_relation
Error    : Table 'mysql.help_relation' doesn't exist
status   : Operation failed
mysql.help_topic
Error    : Table 'mysql.help_topic' doesn't exist
status : Operation failed
mysql.plugin
Error    : Table 'mysql.plugin' doesn't exist
status   : Operation failed
mysql.server_cost
Error    : Table 'mysql.server_cost' doesn't exist
status   : Operation failed
mysql.servers
Error    : Table 'mysql.servers' doesn't exist
status   : Operation failed
mysql.time_zone
Error    : Table 'mysql.time_zone' doesn't exist
status   : Operation failed
mysql.time_zone_leap_second
Error    : Table 'mysql.time_zone_leap_second' doesn't exist
status   : Operation failed
mysql.time_zone_name
Error    : Table 'mysql.time_zone_name' doesn't exist
status   : Operation failed
mysql.time_zone_transition
Error    : Table 'mysql.time_zone_transition' doesn't exist
status   : Operation failed
mysql.time_zone_transition_type
Error    : Table 'mysql.time_zone_transition_type' doesn't exist
status   : Operation failed
The sys schema is already up to date (version 1.5.2).
Checking databases.

5. MySQL 서비스를 재시작 후 오류 로그를 확인하여 정상적으로 동작하는지 확인한다.

[Side Effect]

CASE 1.

mysql_upgrade 작업을 완료 후 MySQL 서비스를 재시작 하였더니 이번엔 새로운 로그가 기록되고 있었다. 다행이 오류 수준이 [ERROR]가 아닌 [WARNING]이었지만 뭔가 이상하다. 발생한 로그는 아래와 같다.

2023-08-31T06:17:51.827559Z 25 [Warning] InnoDB: Cannot open table XXXX/XXXX_XXXX_indexable from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
2023-08-31T06:17:51.827751Z 25 [Warning] InnoDB: Cannot open table XXXX/XXXX_XXXX _indexable_hierarchy from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
2023-08-31T06:17:51.828046Z 25 [Warning] InnoDB: Cannot open table XXXX/XXXX_XXXX _yoast_migrations from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
2023-08-31T06:17:51.828290Z 25 [Warning] InnoDB: Cannot open table XXXX/XXXX_XXXX _primary_term from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
2023-08-31T06:17:51.829080Z 25 [Warning] InnoDB: Cannot open table XXXX/XXXX_XXXX from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
2023-08-31T06:17:51.829516Z 25 [Warning] InnoDB: Cannot open table XXXX/XXXX_XXXX from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

위 로그는 데이터베이스 복구 과정에서 발생한 것이다. 문제는 위와 같은 내용을 에러로그에 기록하면서 CPU와 메모리를 엄청 많이 소비했다는 것이다. 현재 개발 환경이므로 CPU 2Core, Memory 32GB 환경에 MySQL buffer cache는 3GB로 세팅 되어 있다. 그런데 모니터링 그래프를 보면 CPU 100% 사용에 물리 메모리를 모두 소진한 것을 확인할 수 있다.

그런데 실제 버퍼캐시 메모리 사용은 거의 없었다. 예상하기는 mysql 시스템 작업을 위해 별도 스레드에서 사용한거 같은데, 중요한건 작업이 완료된 후에도 메모리가 반환되지 않는 상태로 mysqld 프로세스가 계속 사용중으로 유지되고 있었다.

작업이 완료되고, CPU 사용량이 정상화된 후, MySQL 서비스 재시작으로 메모리를 회수할 수 있었으며, 이후 정상적인 메모리 상태를 유지하고 있다.

CASE 2.

당시 상황을 스크린샷으로 남기지 못했지만, 위 상황에서 평소 1GB 미만의 메모리 사용량을 사용하는 pmm-agent에서 10GB 이상의 메모리 사용량을 보이면서 이상현상을 보이고 있었다. pmm-agent 서비스를 재시작 해보았지만 동일 증상이 계속되었다. 그래서 pmm client를 완전히 제거 후 재설치 하여 해당 문제를 해결하였다. 모니터링 솔루션이기 때문에 해당 문제의 원인을 찾아야 안정적인 라이브 서비스를 할 수 있을 듯한데, 원인을 아직 못찾았다. 예상으로는 perfschema를 모니터링 하면서 변경된 사항을 추적하느라 발생하는 것으로 예상만 하고 있다. (다음에 동일한 상황이 재현되면 상세히 확인해 볼 예정)

개발 서버에서 발생한 문제이다 보니 다양한 상태를 모니터링 하기 위한 설정이 미흡하여 많은 정보를 수집하지 못해 근본적인 원인을 찾지 못하는 아쉬움이 남는 트러블슈팅이었다. 모니터링은 과하다 싶을 정도로 많이 해서 문제가 발생했을 때 빠르고 정확하게 해결할 수 있는 정보로 활용할 수 있도록 하는 것이 매우 중요하다.

2023-09-01 / Sungwook Kang / http://sungwookkang.com

MySQL, innodb_index_stats, MySQL업그레이드, MySQL 트러블슈팅, MySQL Error

[Linux] OOM(Out of Memory)란?

SungWookKang — Wed, 30 Aug 2023 14:49:17 +0900

[Linux] OOM(Out of Memory)란?

l Linux

몇일전부터 개발 환경에서 겪던 문제로 멀쩡하던 MySQL 서비스가 갑자기 연결이 되지 않는다. 처음엔 단순히 행 현상인줄 알고, MySQL 서비스를 재시작 하였다. 그런데 동일한 상황이 하루에도 여러 번 발생하고 있어서 원인을 살펴보기로 했다. 원인을 살펴보니, 아래와 같은 로그가 있었다.

Aug 30 01:35:08 xxxxx kernel: [7189052.423131] [18540] 111 18540 1930392 1535479 12935168 0 0 mysqld
Aug 30 01:35:08 xxxxx kernel: [7189052.423132] Out of memory: Kill process 18540 (mysqld) score 512 or sacrifice child
Aug 30 01:35:08 xxxxx kernel: [7189052.424065] Killed process 18540 (mysqld) total-vm:7721568kB, anon-rss:6141916kB, file-rss:0kB, shmem-rss:0kB
Aug 30 01:35:08 xxxxx kernel: [7189052.749286] oom_reaper: reaped process 18540 (mysqld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

OOM으로 인한 OOM Killer(강제 서비스 종료)였다. OOM은 무엇이고 왜 발생하는 것일까? 그리고 로그는 어떻게 확인할 수 있을까?

OOM (Out of Memory)

Linux의 swap 메모리와 물리 메모리를 모두 사용 중 일 때, 프로세스에서는 필요에 의해 추가적인 물리 메모리 할당을 요청하였는데, 더 이상 할당할 물리 메모리 공간이 없어 할당이 불가능한 상태를 의미한다. 즉 메모리 Over Commit 상태일 때 발생하는 현상으로 물리적으로 메모리가 부족하다는 뜻이다. 이러한 문제는 물리 메모리만 증설하면 사실 간단히 해결된다. 하지만 왜 이러한 현상이 발생하는지 원인을 찾지 못한 상태에서 무한정 메모리를 증설할 수도 없다.

OOM Killer

서버 메모리 부족으로 OOM이 발생하였을 때, 리눅스에서는 메모리를 확보하기 위해 OOM Score를 기준으로 점수가 높은 프로세스를 강제로 Kill 하여 메모리를 확보하는 Kernel 기능이다. 이렇게 OOM Killer로 프로세스가 종료되면 내부 시스템 로그에 기록되어 추후 확인할 할 수 있다.

OOM Killer Log 확인

OOM Killer로 프로세스가 종료되었을 때에는 각종 시스템 로그에서 확인할 수 있다. 시스템 로그에는 OOM Killer외에도 다양한 로그가 있기 때문에 로그 양이 많을 경우 필터를 해서 검색을 해야 할 수도 있다. 일반적으로 특별히 로그 경로를 수정하지 않았다면 아래 경로에서 다양한 시스템 로그를 확인할 수 있다.

/var/log/

Kern.log에서는 아래와 같은 OOM 로그를 확인할 수 있었다.

cat kern.log

Aug 30 01:35:08 XXXXX kernel: [7189052.423131] [18540] 111 18540 1930392 1535479 12935168 0 0 mysqld
Aug 30 01:35:08 XXXXX kernel: [7189052.423132] Out of memory: Kill process 18540 (mysqld) score 512 or sacrifice child
Aug 30 01:35:08 XXXXX kernel: [7189052.424065] Killed process 18540 (mysqld) total-vm:7721568kB, anon-rss:6141916kB, file-rss:0kB, shmem-rss:0kB
Aug 30 01:35:08 xxxxx kernel: [7189052.749286] oom_reaper: reaped process 18540 (mysqld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

syslog에서는 다양한 로그가 많이 기록되어 OOM이라는 필터를 사용하여 확인하였다.

cat syslog | grep oom

Aug 29 23:45:33 xxxxx kernel: [7182478.018455] oom_kill_process+0x21f/0x420
Aug 29 23:45:33 xxxxx kernel: [7182478.018529] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Aug 29 23:45:34 xxxxx kernel: [7182478.495925] oom_reaper: reaped process 22648 (mysqld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Aug 30 01:35:08 xxxxx kernel: [7189052.422998] icinga2 invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0
Aug 30 01:35:08 xxxxx kernel: [7189052.423021] oom_kill_process+0x21f/0x420
Aug 30 01:35:08 xxxxx kernel: [7189052.423096] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Aug 30 01:35:08 xxxxx kernel: [7189052.749286] oom_reaper: reaped process 18540 (mysqld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

message 로그 파일에서도 동일한 오류 내역을 확인할 수 있다. Message 로그 파일은 다양한 로그 파일의 미러 역할을 하기 때문에 정말 다양한 로그가 기록되어 있다.

OOM killer 우선순위

로그를 살펴보면 OOM에 의해 mysqld가 kill 되었음을 확인할 수 있다. 그렇다면 프로세스를 종료시키는 우선순위는 어떻게 정해질까? 두 가지 방법이 있다.

1. oom_badness() 메소드에서 각 프로세스별 점수를 계산하여 종료시킬 프로세스를 선택한다.

2. 사용자가 특별히 지정하여 순위를 변동시킬 수 있다.

oom_badness()가 사용하는 우선순위 선정 방법은 아래와 같다.

1. 특정 프로세스를 킬 함으로써 최소한의 프로세스만 잃을 수 있어야 한다.

2. 많은 메모리를 회수할 수 있는 프로세스 (메모리 사용량이 작으면 킬 되지 않는다.)

3. 프로세스중 Leak이 발생하지 않는 프로세스 (릭이 발생하면 프로세스 Kill이 의미가 없다)

4. 사용자가 특별히 지정한 프로세스

이 외에도 nice와 score 기반으로 우선순위를 선정할 수 있다.

OOM Killer score 확인

OOM score 확인 방법은 /proc/${pid}/oom_score 파일을 통해 조회할 수 있다. PID를 확인하는 방법은 ps 명령을 사용한다.

l ps : shell에서 실행중인 프로세스만 출력

l ps -e : 실행 중인 모든 프로세스 출력

l ps -f : 실행중인 모든 프로세스의 상태 정보 출력

l ps -ef | grep mysql : grep을 사용하여 특정 프로세스(mysql) PID를 확인 한다.

ps -e | grep mywql

cat /proc/15368/oom_score

OOM Killer 순위 설정 방법

1. 특정 프로세스의 PID를 조회

2. /proc/PID/oom_adj 파일에 -17을 입력. oom_adj는 -17 ~ 15의 값을 가지며, 낮은 값 일수록 후순위.

3. /proc_PID/oom_scroe_adj 파일에 -1000을 입력. oom_score_adj는 -1000 ~ 1000의 값을 가지며 낮은 값일수록 후순위.

아래 예시는 oom_adj 파일에 -17로 변경하는 것으로 PID를 변경하여 사용할 수 있다.

sudo echo -17 > /proc/${pid}/oom_ajd

아래 예시는 oom_score_adj파일에 -1000로 변경하는 것으로 PID를 변경하여 사용할 수 있다.

sudo echo -1000 > /proc/${pid}/oom_score_adj

메모리 누수로 인한 System hang 현상을 방지하기 위해 리눅서 커널에서는 OOM killer 자체는 비활성화 할 수 없기 때문에 위 순위 설정을 참고하여 중요한 프로세스는 Kill 되지 않도록 한다.

2023-08-30 / Sungwook Kang / https://sungwookkang.com

리눅스, Linux, OOM, OutOfMemory, 메모리부족현상, 강제킬, 프로세스확인, 메모리압박, 아웃오브메모리, OOMKiller, oom_score

MySQL PMM(Percona Monitoring and Management) 소개 및 설치

SungWookKang — Tue, 22 Aug 2023 15:09:48 +0900

MySQL PMM(Percona Monitoring and Management) 소개 및 설치

l Version : MySQL, MariaDB, PMM

PMM은 서버, 클라이언트 구조로 각 노드들에 PMM Client를 설치하여 중앙의 PMM 서버로 데이터를 전송하는 방식이다. 위 화면을 보면 그라파나(Grafana) 대시보드를 사용하는 것을 알 수 있다. 그리고 데이터를 수집하는 에이전트는 프로메테우스(Prometheus)를 사용한다.

PMM Client

l pmm-admin : 각종 exporter들을 구동 및 제어한다. pmm-admin은 노드 관리를 효과적으로 하기 위해, PMM서버에 포함된 Consul 서버에 exporter 에이전트 접속 정보(아이피와 포트)를 등록한다. Prometheus는 수집주기마다, Consul에 등록된 에이전트 리스트를 가져와서 모니터링 메트릭을 수집한다.

l node_expoter, mysql_expoter : 모니터링 대상 노드(서버)에 서버에 데몬 형태로 구동되는 에이전트로, Prometheus에서 에이전트 포트로 메트릭 요청을 하면 현재 서버의 상태를 전송하는 역할을 한다.

PMM Server

l QNAP : DB서버를 모니터링 할 때, 시스템의 메트릭 뿐만 아닌, 슬로우 쿼리나, 각종 이벤트 정보들을 pmm-server로 데이터를 전달해야 하는데, Prometeus는 이러한 데이터를 받아들이지 않는다. 이러한 데이터를 받기 위해 QAN API를 사용한다. expoter에서 pmm-server의 80포트를 사용하여 /qan-api에 데이터를 전송하면, 내부의 nginx 서비스가 전달한 데이터를 받아서, 127.0.0.1:9001로 리다이렉션하여 쿼리를 저장한다.

l Prometheus : 타임시리즈 기반의 저장소로, 데이터 수집을 비롯해서 저장 그리고 쿼리 질의, Alert등 에이전트의 포트에 접근해서, 모니터링 시스템의 메트릭을 Pull 방식으로 끌어오는 역할을 수행한다.

l Consul : pmm-admin이 pmm의 consul에 모니터링이 될 대상들의 아이피와 포트 번호를 넣어주면, Prometheus는 이 정보를 바탕으로 등록된 scrape_interval마다 각 DB서버 에이전트에 접근하여 모니터링 지표를 수집한다.

l Grafana : 수집된 데이터를 Web UI로 제공한다.

PMM설치의 경우, 서버는 컨테이너로 제공되며, 클라이언트는 컨테이너 또는 전용 패키지 설치 파일로 제공된다. 이번 포스트에서는 Docker에서 PMM 서버를 실행하고, Client는 패키지로 설치한 다음, 모니터링 서버를 등록하는 과정을 살펴본다.

[PMM 서버 설치]

도커 이지지를 다운로드 한다.

docker pull percona/pmm-server:2

데이터를 저장할 호스트 볼륨을 생성한다.

docker volume create pmm-data

이미지를 실행하여 PMM 서비스를 실행한다. 이때, 관리를 위한 443 포트와 웹UI를 제공하기 위한 80포트를 사용하는데, 포트가 충돌나지 않도록 적절히 포트를 포워딩하여사용한다. (이 포스트에서는 도커 사용법을 다루지는 않는다.)

docker run --detach --restart always \
--publish 443:443 --publish 80:80 \
-v pmm-data:/srv \
--name pmm-server \
percona/pmm-server:2

서버가 정상적으로 실행되었으면, 웹브라우저에서 PMM 서버가 설치된 IP를 입력하여 UI 대시보드에 접속한다. 필자의 경우 컨테이너를 생성할 때, 8080포트를 사용하도록 매핑하였다. 기본 ID 및 패스워드는 admin / admin 이다. 정상적으로 접속이 되면 우선 서버 설치는 정상적으로 완료되었다고 판단하면 된다.

http://172.30.1.49:8080

[PMM Client 설치]

모니터링할 대상 서버에는 PMM Client를 설치한다. 운영체제에 따라 전용 패키지 또는 설치 파일을 다운로드하여 설치할 수 있다. 실습 환경은 우분투이며 편의상 패키지로 설치하였다. 각 환경에 따른 설치 방법은 아래 링크를 참고한다.

l Set up PMM Client : https://docs.percona.com/percona-monitoring-and-management/setting-up/client/index.html

apt update
apt-get install -y pmm2-client

Client 설치가 설치가 완료되었으면 PMM 서버에 수집할 클라이언트 목록을 등록해야 한다. 아래 명령어로 등록할 수 있다.

pmm-admin config --server-insecure-tls --server-url=https://admin:admin@X.X.X.X:443

l X.X.X.X : PMM 서버 IP를 입력한다.

l 443 : 기본 포트 번호. 컨테이너 실행시 포트 번호를 다르게 매핑하였다면 수정해야한다.

l Admin/admin : PMM 서버의 기본 접속 정보이다. 만약 이전 웹UI를 통해서 수정하였다면 이 부분도 수정한다.

여기까지 진행되었으면 PMM 대시보드에서 모니터링의 대상 서버가 추가된 것을 확인할 수 있다. 홈 대시보드에서는 Node Names에서 확인할 수 있다. 정보가 업데이트 되기까지 약간의 시간이 걸릴수도 있다.

이번 실습에서는 MySQL을 모니터링을 하기 때문에 MySQL 서비스에 대한 모니터링을 할 수 있도록 MySQL도 등록한다. 사용자 환경에 따라 필요한 서비스를 등록한다. 지원되는 서비스 목록은 아래와 같다.

l MySQL (and variants Percona Server for MySQL, Percona XtraDB Cluster, MariaDB)

l MongoDB

l PostgreSQL

l ProxySQL

l Amazon RDS

l Microsoft Azure

l Google Cloud Platform (MySQL and PostgreSQL)

l Linux

l External services

l HAProxy

l Remote instances

MySQL 서비스에 대한 정보를 수집할 수 있도록 PMM Client가 사용할 계정 및 다양한 시스템 환경을 설정한다. 설정 방법은 공식 문서를 참고할 수 있도록 한다.

l https://docs.percona.com/percona-monitoring-and-management/setting-up/client/mysql.html

이번 포스트에서는 슬로우 쿼리 로그를 모니터링 할 수 있도록 서비스를 등록하였다.

pmm-admin add mysql --query-source=slowlog --username=pmm --password=pass

대시보드를 살펴보면 MySQL 서비스가 등록되었으며, 관련 지표를 확인할 수 있다.

PMM은 내부 적으로 알림 시스템(alert-manager)을 가지고 있어, 특정 임계치를 설정하였을 때, 그 임계치를 넘으면 알림을 받을 수 있다. 이번 포스트에서는 다루지 않지만, 이러한 알림 시스템까지 설정하여 활용하면 시스템에 대한 상태를 매번 지켜보지 않아도 문제가 발생하였을 때, 메신저 등으로 알림을 받을 수 있어 빠르게 문제 인지 및 원인을 파악할 수 있다.

[참고자료]

l https://prometheus.io/docs/introduction/overview/

l https://docs.percona.com/percona-monitoring-and-management/setting-up/server/docker.html

l https://docs.percona.com/percona-monitoring-and-management/setting-up/client/mysql.html

l https://prometheus.io/docs/introduction/overview/

2023-08-22 / Sungwook Kang / http://sungwookkang.com

MySQL, MariaDB, Percona, DB모니터링, PMM, MySQL모니터링, 퍼코나 모니터링, Grafana, Promethus, 슬로우쿼리모니터링

MySQL Galera Cluster + ProxySQL에서 Galera Cluster 특성을 고려한 R/W 호스트 그룹 설정 하기

SungWookKang — Thu, 10 Aug 2023 15:55:44 +0900

MySQL Galera Cluster + ProxySQL에서 Galera Cluster 특성을 고려한 R/W 호스트 그룹 설정 하기

l Version : MySQL, MariaDB, Galera Cluster, ProxySQL 2.X

Galera Cluster (이하 “갈레라 클러스터”)는 다중 마스터 동기 복제를 제공하는 솔루션으로 DB 간의 직접적인 데이터 공유가 없는 형태의 오픈소스 고가용성 솔루션이다. 갈레라 클러스터는 동기 방식의 복제구조를 사용하는 멀티마스터 RDB 클러스터로 제공된다.

ProxySQL은 여러 데이터베이스에 대해 동일한 커넥션을 재사용할 수 있도록 멀티 플렉싱 기능과 쿼리를 분석하여 Write/Read를 분산하는 등 다양한 기능을 제공하는 솔루션이다.

l ProxySQL 이란 무엇인가 : https://sungwookkang.com/1528

l MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기 : https://sungwookkang.com/1536

ProxySQL 2.x 부터는 Galera Cluster를 좀더 유연하게 지원한다. 이번 포트스에서는 MySQL Galera cluster + ProxySQL로 구성된 환경에서 Galera Cluster 특성을 고려한 ProxySQL의 Write, Read 호스트 그룹 전략에 대해서 알아본다.

[mysql_galera_hostgroups]

ProxySQL에서 호스트 그룹에 따라 Write, Read를 역할을 정의한다. Galera Cluster 환경에서는 mysql_galera_hostgroups에서 해당 노드의 역할을 정의할 수 있다. 아래 스크립트를 실행하면 mysql_galera_hostgroups 테이블의 정보를 확인할 수 있다.

select * from mysql_galera_hostgroups\G

Admin> select * from mysql_galera_hostgroupsG
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 20
reader_hostgroup: 30
offline_hostgroup: 9999
active: 1
max_writers: 1
writer_is_also_reader: 2
max_transactions_behind: 20
comment:

l writer_hostgroup : 쓰기 가능한 (read_only=0) 모든 구성원을 포함할 호스트 그룹의 ID

l backup_writer_hostgroup : 쓰기 백업 노드의 그룹 ID. 클러스터가 다중 쓰기 모드(read_only=0인 여러 노드가 있는 경우)에서 실행 중이고 max_writers가 전체 쓰기 노드 수보다 작은 수로 설정된 경우 추가 노드는 backup_writer_hostgroup 으로 이동된다.

l reader_hostgroup : 읽기 가능한 (read_only=1인 노드) 모든 구성원을 포함할 호스트 그룹의 ID

l offline_hostgroup : 클러스터에서 참여하지 않는 노드들에 대한 그룹ID. ProxySQL 모니터링에서 호스트가 OFFLINE인 것으로 확인되면 호스트가 offline_hostgroup으로 이동된다.

l Active : 호스트 그룹을 활성화하는 부울 값 (0 또는 1)

l max_writers : writer 호스트 그룹에서 허용되는 최대 노드 수를 제어한다. Writer_hostgroup 노드 수가 max_writers 수보다 클 경우 추가 노드는 backup_writer_hostgroup으로 이동된다.

l writer_is_also_reader : 1이면 writer_hostgroup의 노드가 reader_hostgroup에도 배치되어 읽기에 사용된다. 2로 설정하면 backup_writer_hostgroup의 노드가 writer_hostgroup의 노드 대신 reader_hostgroup에 배치된다.

l max_transactions_behind : 오래된 읽기를 방지하기 위해 노드가 SHUNNED되기 전에 클러스터의 노드가 대기할 수 있는 최대 쓰기 세트 수를 결정한다. (wsrep_local_recv_queue Galera 변수를 쿼리하여 결정됨).

l Comment : 사용자가 정의한 목적에 맞게 사용할 수 있는 텍스트 필드

ProxySQL은 MySQL 상태 및 변수를 모니터링하여 Galera 상태 확인을 수행한다.

l read_only : 설정값이 ON인 경우, writer_is_also_reader가 1이 아니면 ProxySQL은 정의된 호스트를 reader_hostgroup으로 그룹화한다.

l wsrep_desync : 설정값이 ON인 경우, ProxySQL은 노드를 사용할 수 없는 것으로 표시하여 offline_hostgroup으로 이동한다.

l wsrep_reject_queries : 설정값이 ON이면 ProxySQL은 노드를 사용할 수 없는 것으로 표시하고 이를 offline_hostgroup으로 이동한다. (특정 유지 관리 상황에서 유용함).

l wsrep_sst_donor_rejects_queries : 설정값이 ON이면 ProxySQL은 Galera 노드가 SST 기증자 역할을 하는 동안 해당 노드를 사용 불가로 표시하여 offline_hostgroup으로 이동한다.

l wsrep_local_state : 해당 값이 동기화를 의미하는 4 이외의 값을 반환하면 ProxySQL은 노드를 사용할 수 없는 것으로 표시하고 offline_hostgroup으로 이동한다.

l wsrep_local_recv_queue : 해당 값이 max_transactions_behind보다 높으면 노드가 회피된다.

l wsrep_cluster_status : 이 상태가 기본이 아닌 다른 상태로 반환되면 ProxySQL은 노드를 사용할 수 없는 것으로 표시하고 offline_hostgroup으로 이동한다.

ProxySQL 2.x는 mysql_galera_hostgroups의 매개변수와 mysql_query_rules 정책을 함께 결합함으로써 훨씬 더 다양한 Galera Cluster 구성에 대한 유연성을 갖게 되었다. 예를 들어 쿼리 규칙의 대상 호스트 그룹으로 정의된 단일 쓰기, 다중 쓰기 및 다중 읽기 호스트 그룹을 가질 수 있으며, 쓰기 수를 제한하고 오래된 읽기 동작을 보다 세밀하게 제어할 수 있다.

ProxySQL에서 max_writers 및 writer_is_also_reader 변수는 ProxySQL이 백엔드 MySQL 서버를 동적으로 그룹화하는 방법을 결정할 수 있으며 커넥션 분산 및 쿼리 라우팅에 직접적인 영향을 끼친다. 예를 들어 아래와 같이 MySQL 백엔드(노드) 서버가 등록되어 있다고 가정한다. 등록된 노드는 아래 스크립트로 확인 가능하다.

Admin> select hostgroup_id, hostname, status, weight from mysql_servers;

Admin> select hostgroup_id, hostname, status, weight from mysql_servers;
+--------------+--------------+--------+--------+
| hostgroup_id | hostname     | status | weight |
+--------------+--------------+--------+--------+
| 10           | DB1          | ONLINE | 1      |
| 10           | DB2          | ONLINE | 1      |
| 10           | DB3          | ONLINE | 1      |
+--------------+--------------+--------+--------+

그리고 현재 구성되어 있는 mysql_galera_hostgroup의 설정도 살펴본다.

Admin> select * from mysql_galera_hostgroups\G

Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 20
reader_hostgroup: 30
offline_hostgroup: 9999
active: 1
max_writers: 1
writer_is_also_reader: 2
max_transactions_behind: 20
comment:

현재 노드 설정에서 모든 호스트가 가동되어 실행 중임을 고려하면 ProxySQL은 호스트를 아래와 같이 다양한 시나리오로 그룹화할 수 있다.

위 그림에 따른 3가지 케이스의 특징을 한번 살펴본다.

Configuration	Description
writer_is_also_reader=0	l 호스트를 2개의 호스트 그룹(writer 및 backup_writer)으로 그룹화한다. l Writer는 backup_writer의 일부이다. l Write는 Reader가 아니므로 read_only=1로 설정된 호스트가 없기 때문에 호스트 그룹 30(Reader)에는 아무것도 없다. 읽기 전용 플래그를 활성화하는 것은 Galera에서 일반적인 관행이 아니다.
writer_is_also_reader=1	l 호스트를 3개의 호스트 그룹(writer, backup_writer 및 reader)으로 그룹화한다. l Galera의 변수 read_only=0은 영향을 미치지 않으므로 writer는 호스트 그룹 30(reader)에도 있다. l writer는 backup_writer의 일부가 아니다.
writer_is_also_reader=2	l writer_is_also_reader=1과 유사하지만 writer는 backup_writer의 일부이다.

위 그룹 구성에 따른 특성을 활용하면 사용자는 특정 워크로드에 맞는 호스트 그룹 대상을 다양하게 선택할 수 있다. "핫스팟" 쓰기는 다중 마스터 충돌을 줄이기 위해 하나의 서버로만 이동하도록 구성할 수 있다. 충돌하지 않는 쓰기는 다른 마스터에 균등하게 분배될 수 있다. 쓰기는 최신 서버로 전달될 수 있으며 분석 읽기는 슬레이브 복제본으로 전달될 수 있다.

[Galera 클러스터용 ProxySQL 배포]

아래 그림과 같이 ClusterControl에 의해 배포된 3노드 Galera Cluster가 구성되어 있다고 가정하고, 시나리오를 만족하기 위해 클러스터를 세팅하는 과정을 다루어 본다.

시나리오는 아래와 같다.

WordPress 애플리케이션은 Docker에서 실행되고 WordPress 데이터베이스는 베어메탈 서버에서 실행되는 Galera Cluster에서 호스팅 된다. 우리는 WordPress 데이터베이스 쿼리 라우팅을 더 잘 제어하고 데이터베이스 클러스터 인프라를 완전히 활용하기 위해 WordPress 컨테이너와 함께 ProxySQL 컨테이너를 실행하기로 결정했다. 읽기-쓰기 비율이 약 80%-20%이므로 ProxySQL을 다음과 같이 구성하려고 한다.
l 모든 쓰기를 하나의 Galera 노드로 전달(충돌 감소, 쓰기에 집중)
l 다른 두 Galera 노드에 대한 모든 읽기의 균형을 분배 (대부분의 워크로드에 대해 더 나은 분배).

위 시나리오를 만족할 수 있도록 ProxySQL을 구성한다. 먼저 컨테이너에 매핑할 수 있도록 Docker 호스트 내부에 ProxySQL 구성 파일을 만든다.

$ mkdir /root/proxysql-docker
$ vim /root/proxysql-docker/proxysql.cnf

아래와 같이 설정값을 입력한다. (코드에 대한 자세한 설명은 아래부분에서 하나씩 설명한다.)

datadir="/var/lib/proxysql"

admin_variables=
{
    admin_credentials="admin:admin"
    mysql_ifaces="0.0.0.0:6032"
    refresh_interval=2000
    web_enabled=true
    web_port=6080
    stats_credentials="stats:admin"
}

mysql_variables=
{
    threads=4
    max_connections=2048
    default_query_delay=0
    default_query_timeout=36000000
    have_compress=true
    poll_timeout=2000
    interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
    default_schema="information_schema"
    stacksize=1048576
    server_version="5.1.30"
    connect_timeout_server=10000
    monitor_history=60000
    monitor_connect_interval=200000
    monitor_ping_interval=200000
    ping_interval_server_msec=10000
    ping_timeout_server=200
    commands_stats=true
    sessions_sort=true
    monitor_username="proxysql"
    monitor_password="proxysqlpassword"
    monitor_galera_healthcheck_interval=2000
    monitor_galera_healthcheck_timeout=800
}

mysql_galera_hostgroups =
(
    {
        writer_hostgroup=10
        backup_writer_hostgroup=20
        reader_hostgroup=30
        offline_hostgroup=9999
        max_writers=1
        writer_is_also_reader=1
        max_transactions_behind=30
        active=1
    }
)

mysql_servers =
(
    { address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)

mysql_query_rules =
(
    {
        rule_id=100
        active=1
        match_pattern="^SELECT .* FOR UPDATE"
        destination_hostgroup=10
        apply=1
    },
    {
        rule_id=200
        active=1
        match_pattern="^SELECT .*"
        destination_hostgroup=30
        apply=1
    },
    {
        rule_id=300
        active=1
        match_pattern=".*"
        destination_hostgroup=10
        apply=1
    }
)

mysql_users =
(
    { username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
    { username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)

위 코드에서 살펴보면 mysql_galera_hostgroups 구성은 아래와 같이 정의되어 있다.

mysql_galera_hostgroups =
(
    {
        writer_hostgroup=10
        backup_writer_hostgroup=20
        reader_hostgroup=30
        offline_hostgroup=9999
        max_writers=1
        writer_is_also_reader=1
        max_transactions_behind=30
        active=1
    }
)

writer 그룹은 10, backup 그룹은 20, reader 그룹은 30으로 정의 되어있다. max_writers를 1로 설정하여 모든 쓰기가 전송되어야 하는 호스트 그룹 10에 대해 단일 쓰기로 작동하도록 하였다. 그런 다음 writer_is_also_reader를 1로 정의하여 모든 Galera 노드를 읽기 노드에 참여할 수 있도록 하였다. 이렇게 하면 읽기 요청은 모든 노드에 균등하게 배포할 수 있다. Offline 그룹은 9999이며 ProxySQL이 작동하지 않는 Galera 노드를 감지한 경우 offline_hostgroup으로 이동시킨다.

mysql_servers는 클러스터에 참여하는 노드 정보를 정의한다. 시나리오에서는 모든 노드를 쓰기 가능한 호스트 그룹인 10으로 MySQL 서버를 구성하였다.

mysql_servers =
(
    { address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)

위의 구성을 그림으로 표현하면 ProxySQL은 아래와 같이 호스트 그룹을 구성하고 인식한다.

mysql_query_rules 은 쿼리 라우팅을 정의한다. 요구 사항에 따라 모든 읽기는 작성자(호스트 그룹 20)를 제외한 모든 Galera 노드로 전송되어야 하며 다른 모든 것은 단일 작성자의 호스트 그룹 10으로 전달된다.

mysql_query_rules =
(
    {
        rule_id=100
        active=1
        match_pattern="^SELECT .* FOR UPDATE"
        destination_hostgroup=10
        apply=1
    },
    {
        rule_id=200
        active=1
        match_pattern="^SELECT .*"
        destination_hostgroup=20
        apply=1
    },
    {
        rule_id=300
        active=1
        match_pattern=".*"
        destination_hostgroup=10
        apply=1
    }
)

마지막으로 ProxySQL을 통해 전달될 MySQL 사용자를 정의한다.

mysql_users =
(
{ username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
{ username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)

우리는 transaction_persistent를 0으로 설정하여 사용자로부터 오는 모든 연결이 읽기 및 쓰기 라우팅에 대한 쿼리 규칙을 준수하도록 한다. 그렇지 않으면 연결이 하나의 호스트 그룹에 도달하게 되어 로드 밸런싱의 목적이 상실하기 때문이다. 모든 MySQL 서버에서 해당 사용자를 먼저 생성하는 것을 잊지 않도록 한다. ClusterControl를 활용해서 사용자를 추가하는 경우 [관리] -> [스키마 및 사용자 기능]을 사용하여 해당 사용자를 생성할 수 있다.

설정 파일 생성이 완료되었으면 이제 컨테이너를 실행한다. ProxySQL 컨테이너를 시작할 때 ProxySQL 구성 파일을 바인드 마운트로 매핑하기 때문에 아래와 같은 명령어로 실행한다.

$ docker run -d
--name proxysql2
--hostname proxysql2
--publish 6033:6033
--publish 6032:6032
--publish 6080:6080
--restart=unless-stopped
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf
severalnines/proxysql:2.0

마지막으로 ProxySQL 컨테이너 포트 6033을 가리키도록 WordPress에서 데이터베이스 연결 포트를 변경한다.

$ docker run -d
--name wordpress
--publish 80:80
--restart=unless-stopped
-e WORDPRESS_DB_HOST=proxysql2:6033
-e WORDPRESS_DB_USER=wordpress
-e WORDPRESS_DB_HOST=passw0rd
wordpress

지금까지의 서비스 구성을 그림으로 표현하면 아래 아키텍처와 같다.

ProxySQL 컨테이너를 영구적으로 유지하려면 /var/lib/proxysql/을 Docker 볼륨에 매핑하거나 바인드를 마운트 해야한다. 아래 스크립트는 컨테이너 실행시 설정 파일을 영구 저장소로 바인드하는 예제이다.

위와 같이 영구 저장소로 실행하면 컨테이너를 다시 시작 시 /root/proxysql/proxysql.cnf를 사용하지 않는 다는 것에 주의한다. 이는 /var/lib/proxysql/proxysql.db가 존재하는 경우 ProxySQL이 구성 파일에서 로드 옵션을 건너뛰고 대신 SQLite 데이터베이스에 있는 항목을 로드하는 ProxySQL 다중 계층 구성 때문이다. (–initial 플래그로 proxysql 서비스를 시작하면 설정 파일의 값으로 시작한다.) ProxySQL 구성 관리는 구성 파일을 사용하는 대신 포트 6032의 ProxySQL 관리 콘솔을 통해 수행해야 한다.

ProxySQL 서비스 시작 시 사용하는 구성파일에 대한 자세한 정보는 아래 글을 참고한다.

l ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까? : https://sungwookkang.com/1535

[Monitoring]

ProxySQL 프로세스 로그는 기본적으로 syslog에 기록되며 표준 docker 명령을 사용하여 볼 수 있다.

$ docker ps
$ docker logs proxysql2

현재 ProxySQL에서 운영중인 호스트 그룹을 확인하려면 runtime_mysql_servers 테이블을 쿼리한다. 아래 스크립트는 호스트 환경에서 컨테이너의 ProxySQL 관리 콘솔에 접속한다.

$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> '

$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> '
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname     | status |
+--------------+--------------+--------+
| 10           | 192.168.0.21 | ONLINE |
| 30           | 192.168.0.21 | ONLINE |
| 30           | 192.168.0.22 | ONLINE |
| 30           | 192.168.0.23 | ONLINE |
| 20           | 192.168.0.22 | ONLINE |
| 20           | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+

만약 특정 쓰기 노드가 다운되면 해당 노드는 offline_hostgroup (HID 9999)으로 이동된다. 예제에서는 192.168.0.21 노드가 다운되어 9999 그룹으로 이동되었다.

Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname     | status |
+--------------+--------------+--------+
| 10           | 192.168.0.22 | ONLINE |
| 9999         | 192.168.0.21 | ONLINE |
| 30           | 192.168.0.22 | ONLINE |
| 30           | 192.168.0.23 | ONLINE |
| 20           | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+

위의 토폴로지 변경 사항은 아래 그림과 같다.

ProxySQL에서 admin-web_enabled=true로 설정할 경우 웹 통계 UI를 사용할 수 있다. 웹 UI에 액세스하려면 포트 웹브라우저로 Docker 호스트6080 포트로 접속한다. (예, http://192.168.0.200:8060) 사용자 이름을 묻는 메시지가 표시되면 admin-stats_credentials에 정의된 자격 증명을 입력한다. 로그인하면 아래와 같은 통계 화면을 볼 수 있다.

MySQL 연결 풀 테이블을 모니터링하면 모든 호스트 그룹에 대한 연결 분포 개요를 확인할 수 있다.

Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host;

Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host;
+-----------+--------------+--------+----------+-------------+---------+
| hostgroup | srv_host     | status | ConnUsed | MaxConnUsed | Queries |
+-----------+--------------+--------+----------+-------------+---------+
| 20        | 192.168.0.23 | ONLINE | 5        | 24          | 11458   |
| 30        | 192.168.0.23 | ONLINE | 0        | 0           | 0       |
| 20        | 192.168.0.22 | ONLINE | 2        | 24          | 11485   |
| 30        | 192.168.0.22 | ONLINE | 0        | 0           | 0       |
| 10        | 192.168.0.21 | ONLINE | 32       | 32          | 9746    |
| 30        | 192.168.0.21 | ONLINE | 0        | 0           | 0       |
+-----------+--------------+--------+----------+-------------+---------+

위의 출력 값을 살펴보면 쿼리 규칙에 의해 호스트 그룹 30이 아무 것도 처리하지 않음을 알 수 있다.

Galera 노드와 관련된 통계는 mysql_server_galera_log 테이블에서 볼 수 있다.

> select * from mysql_server_galera_log order by time_start_us desc limit 3 \G

Admin> select * from mysql_server_galera_log order by time_start_us desc limit 3 \G
*************************** 1. row ***************************
                       hostname: 192.168.0.23
                           port: 3306
                  time_start_us: 1552992553332489
                success_time_us: 2045
              primary_partition: YES
                      read_only: NO
         wsrep_local_recv_queue: 0
              wsrep_local_state: 4
                   wsrep_desync: NO
           wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
                          error: NULL
*************************** 2. row ***************************
                       hostname: 192.168.0.22
                           port: 3306
                  time_start_us: 1552992553329653
                success_time_us: 2799
              primary_partition: YES
                      read_only: NO
         wsrep_local_recv_queue: 0
              wsrep_local_state: 4
                   wsrep_desync: NO
           wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
                          error: NULL
*************************** 3. row ***************************
                       hostname: 192.168.0.21
                           port: 3306
                  time_start_us: 1552992553329013
                success_time_us: 2715
              primary_partition: YES
                      read_only: NO
         wsrep_local_recv_queue: 0
              wsrep_local_state: 4
                   wsrep_desync: NO
           wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
                          error: NULL

쿼리 결과 내용은 특정 타임스탬프에 대한 모든 Galera 노드의 관련 MySQL 변수/상태 상태를 반환한다. 이 구성에서는 Galera 상태 확인이 2초마다 실행되도록 구성되어 있다. (monitor_galera_healthcheck_interval=2000). 따라서 클러스터에 토폴로지 변경이 발생하는 경우 최대 장애 조치 시간은 약 2초이다.

지금까지 MySQL Galera 클러스터 환경에서 ProxySQL을 조합하여 사용할 때, 쓰기, 읽기 그룹에 대한 정의와 ProxySQL을 컨테이너로 구성하는 과정을 다루었다. 실제 운영환경에서는 각자의 노드 구성과 SLA가 모두 다르기 때문에 위 내용을 이해하고 잘 활용할 수 있도록 한다.

[참고자료]

l How to Run and Configure ProxySQL 2.0 for MySQL Galera Cluster on Docker : https://severalnines.com/blog/how-run-and-configure-proxysql-20-mysql-galera-cluster-docker/

l ProxySQL 이란 무엇인가 : https://sungwookkang.com/1528

l MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기 : https://sungwookkang.com/1536

l ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까? : https://sungwookkang.com/1535

2023-08-10 / Sungwook Kang / http://sungwookkang.com

MySQL, MariaDB, Galera Cluster, 마리아디비, 마이에스큐엘, 갈레라 클러스터, MariaDB 복제, MariaDB Cluster, MySQL Cluster, MariaDB Replication, MySQL, ProxySQL, ProxySQL설정, ProxySQL 구성관리, ProxySQL 시작, Proxy Container

[Kubernetes] 쿠버네티스에서 파드 생성시 프라이빗 레지스트리 이미지 사용하기

SungWookKang — Wed, 9 Aug 2023 18:54:41 +0900

[Kubernetes] 쿠버네티스에서 파드 생성시 프라이빗 레지스트리 이미지 사용하기

l Kubernetes

Kubernetes 환경에서 pod를 생성할 때 Private Registry에서 이미지를 다운받아 실행하는 방법에 대해서 알아본다.

현재 구성되어 있는 실습 환경은 MAC OS + PODMAN + MINIKUBE이다. 일반적으로 많이 사용하는 docker 환경은 아니지만 사용법이 거의 유사하기 때문에 따라하는데 크게 문제가 없으리라 생각한다. Minikube 설치 및 Podman 설치는 공식 문서에 쉽게 설명되어 있기 때문에 여기에서는 다루지 않는다.

l Podman Installation Instructions : https://podman.io/docs/installation

l minikube start : https://minikube.sigs.k8s.io/docs/start/

실습 시나리오는 아래와 같다.

1. Dockerfile 작성

2. 컨테이너 이미지 빌드

3. Docker Hub의 개인 저장소에 이미지 푸시

4. 쿠버네티스에서 프라이빗 시크릿키 생성

5. YAML 파일 작성

6. Pod 생성

사용자 커스텀 이미지를 만들기 위해 Dockerfile을 작성한다. Dockerfile 작성에 관한 방법은 다른 문서를 참고한다. 도커 허브의 공식 이미지 저장소에서는 Dockerfile에 대한 샘플코드를 제공한다. 아래는 proxysql의 공식 저장소이다.

l https://hub.docker.com/r/proxysql/proxysql

Dockerfile 작성이 완료되었으면, 이미지를 빌드 한다. Podman 명령어는 도커 명령어와 거의 유사하기 때문에 큰 어려움 없이 사용할 수 있다. 아래 스크립트는 Dockerfile을 빌드하여 컨테이너 이미지를 생성하고, 현재 생성되어 있는 이미지를 확인한다.

podman build -t proxysql-sw:1.0.0 .

podman images

podman에서는 도커 레지스트리에 push하기 위해 로그인 과정이 필요하다. 도커 허브의 로그인은 아래와 같은 명령어를 사용한다. 로그인은 ID, 패스워드로 인증한다.

podman login docker.io

이미지를 푸시 하기 위해서는 이미지 ID가 필요하다. Podman images명령을 사용하여 확인한 이미지ID를 사용하여 도커 허브의 프라이빗 레지스트리로 푸시 한다.

podman push 561f3e4999fddocker.io/<개인저장소 경로>

쿠버네티스에서 파드 생성시 사용할 프라이빗 레지스트리에 대한 시크릿 키를 생성한다. 시크릿 키에 대한 생성은 여러 방법이 있지만 여기에서는 커맨드 라인에서 자격증명을 통한 시크릿 키를 생성한다. 아래 예제에서는 시크릿 키 이름은 regcred로 생성한다.

kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

l <your-registry-server> : 프라이빗 도커 저장소의 FQDN 주소로, 도커허브(DockerHub)는 https://index.docker.io/v1/ 를 사용

l <your-name> : 도커 사용자의 계정

l <your-pword> : 도커 사용자의 비밀번호

l <your-email> : 도커 사용자의 이메일 주소

키가 정상적으로 생성되었는지는 아래 명령으로 확인 가능하다. 명령을 실행하면 키에 대한 자세한 정보를 확인할 수 있다.

kubectl get secret regcred --output=yaml

쿠버네티스에서 파드 생성시 사용할 YAML 파일을 작성한다. YAML에서 시크릿 키를 사용할 수 있도록 imagePullSecrets 항목에서 시크릿키 이름을 입력한다.

apiVersion: v1
kind: Pod
metadata:
name: private-reg
spec:
containers:
- name: private-reg-container
image: <your-private-image>
imagePullSecrets:
- name: regcred

YAML파일을 사용하여 쿠버네티스 파드를 생성한다.

kubectl apply -f my-private-reg-pod.yaml

도커허브의 개인 저장소 이미지를 사용하여 파드가 정상적으로 생성된 것을 확인할 수 있다.

kubectl get pod

지금까지 도커 허브의 프라이빗 레지스트리에서 이미지를 받아 파드를 생성하는 방법에 대해서 알아보았다. 원래 나의 목적은 로컬(내 컴퓨터)에서 이미지를 빌드한 다음 로컬 저장소의 이미지를 사용하여 쿠버네티스 파드를 생성하려고 하였는데, podman에서 생성한 이미지를 minikube에서 찾지 못하여 (정확히는 내가 할 줄 모르는 것) 도커 허브를 사용하는 방향으로 실습하였다. 이후 작업으로 로컬 저장소에서 파드를 생성하는 방법을 추가적으로 알아볼 예정이다.

[참고자료]

l Podman Installation Instructions : https://podman.io/docs/installation

l minikube start : https://minikube.sigs.k8s.io/docs/start/

l docker hub : https://hub.docker.com/

l 프라이빗 레지스트리에서 이미지 받아오기 : https://kubernetes.io/ko/docs/tasks/configure-pod-container/pull-image-private-registry/

2023-08-09 / Sungwook Kang / https://sungwookkang.com

쿠버네티스, Kubernetes, 미니쿠베, minikube, 도커, 도커허브, 컨테이너, 도커파일, dockerfile, yaml, 도커 레지스트리, 프라이빗 레지스트리, podman, 파드맨, 도커빌드. 이미지빌드

MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기

SungWookKang — Mon, 7 Aug 2023 16:23:35 +0900

MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기

l Version : MySQL, MariaDB, Galera Cluster

Galera Cluster (이하 “갈레라 클러스터”)는 다중 마스터 동기 복제를 제공하는 솔루션으로 DB 간의 직접적인 데이터 공유가 없는 형태의 오픈소스 고가용성 솔루션이다. 현재 갈레라 클러스터는 MySQL Percona Xtradb 클러스터와 MariaDB 두 가지 버전을 지원한다. 특히 MariaDB에서는 Galera Cluster를 공식적으로 지원한다. 이번 포스트에서는 갈레라 클러스터의 개념과 장단점에 대해서 알아본다.

갈레라 클러스터는 동기 방식의 복제구조를 사용하는 멀티마스터 RDB 클러스터로 제공된다. 갈레라 클러스터는 인증 기반 복제를 제공하며 노드간 통신을 위해 wsrep API를 사용한다. 데이터 복제는 논리적으로는 완전 동기이지만 실제 write와 tablespace에 commit하는 과정은 별개이고 각 노드간에는 비동기로 동작한다. 그래서 갈레라 클러스터에서는 이러한 방식을 virtually synchronous replication이라 부른다.

[Galera Cluster 특징]

l 다중 쓰기 : Active-Active 방식의 다중 Master 구조이기 때문에 모든 노드에서 Read/Write 가능하다.

l 동기 복제 : 슬레이브 지연이 없고 노드 충돌시 데이터 손실이 없다.

l 일관적 데이터 유지 : 모든 노드는 항상 같은 데이터 상태를 유지 한다.

l 장애조치 : 노드 장애가 발생하였을 때 빠르게 모니터링 되어 전환되므로 서비스 중단이 최소화 된다. 멀티 포인트 쓰기를 지원하므로 전환이 쉽다. 특정 노드 장애가 전체 서비스에 영향을 미치지 않는다. 이론적으로 모든 노드가 쓰기 가능하기 때문에 모든 노드가 다운되기 전까지는 서비스 유지가 가능하다.

l 자동 노드 복제 : 노드를 추가하거나 관리를 위해 종료 또는 노드에서 제거 해야 할 경우 증분 데이터 또는 기본 데이터를 수동으로 백업할 필요가 없다. 갈레라 클러스터는 노드를 추가할 경우 자동으로 온라인 노드의 데이터를 가져오고 일관성을 유지한다.

[Galera Cluster 단점]

l 동기 복제 특성상 클러스터의 성능은 가장 성능이 낮은 노드에 의해 결정된다. 그래서 최대한 동일한 성능의 서버로 구성하는 것이 좋다.

l 동기 복제이기 때문에 쓰기가 많이 발생할 경우 다른 아키텍처(비동기 복제 등)보다 상대적으로 성능이 저하되며 스케일 아웃에 한계가 있다.

l 신규 노드가 조인되거나 대규모 노드 조인시 지연이 발생하면 데이터 전체를 복사(SST, 상태 스냅샷 전동) 하는 문제가 발생한다. 이때 데이터를 제공하는 서버를 Donor라고 하는데 Donor 노드는 복제 데이터를 전송하는 동안 읽기 및 쓰기 서비스가 중단된다.

l 인증 기반 복제를 사용하기 때문에 인증이 실패할 경우 데드락이 발생할 가능성이 있다.

[Galera Cluster 제약사항]

l MyISAM 일부와 InnoDB 스토리지 엔진 테이블만 지원한다.

l 노드 간의 쿼리 실행 순서를 피하기 위해 모든 테이블에서 기본키를 필수적으로 사용한다.

n 기본 키가 없는 테이블에서는 DELETE 작업이 지원되지 않는다.

n 기본 키가 없는 테이블의 행은 다른 노드에서 다른 순서로 나타날 수 있다.

l Query Cache를 비활성화한다

l XA 트랜잭션 (전역 트랜잭션)은 지원하지 않는다.

l 일반 쿼리 로그와 슬로우 쿼리 로그는 테이블로 보낼 수 없다. 이러한 로그를 활성화하는 경우 log_output=FILE을 설정하여 로그를 파일로 전달해야 한다.

Galera Cluster는 wsrep(Write-Set Replication) API를 통해 각 노드와 데이터를 동기화 한다. 여기서 wsrep API는 DBMS간 복제를 위한 인터페이스이며 실제 동기화 구현은 Galera Replication Plugin에서 이루어 진다.

각 노드에서 쓰기나 업데이트가 발생할 경우 노드간에 데이터를 복제하고 업데이트 내용을 GCache 영역에 저장한다. GCache는 복제된 트랜잭션을 위한 임시 저장소 역할을 한다.

Galera Cluster는 인증기반 복제를 사용한다. 인증 기반 복제의 주요 컨셉은 트랜잭션이 충돌이 없다고 가정하고 커밋 지점에 도달할 때까지 관례적으로 실행된다는 것이다. 이를 낙관적 실행이라고 한다.

Galera Cluster에서 인증 기반 복제 구현은 트랜잭션의 전역 순서에 따라 다르다. Galera Cluster는 복제 중에 각 트랜잭션에 전역 시퀀스 번호 또는 seqno를 할당한다. 트랜잭션이 커밋 지점에 도달하면 노드는 마지막으로 성공한 트랜잭션의 시퀀스 번호와 시퀀스 번호를 확인한다. 둘 사이의 간격을 통해 모든 트랜잭션은 해당 트랜잭션과 기본 키 충돌이 있는지 확인한다. 충돌이 감지되면 인증 테스트에 실패한다.

위 그림에서 데이터가 변경되고 커밋되기 까지의 순서를 나타내면 아래와 같다.

1. 클라이언트가 데이터를 수정하고 커밋 요청을 서버에 요청한다.

2. 서버는 커밋 요청을 받으면 실제 커밋을 실행하기 전에 트랜잭션 및 변경된 행의 기본 키에 의해 데이터베이스에 대한 모든 변경 사항이 쓰기 세트로 수집된다.

3. 데이터베이스는 이 쓰기 세트를 다른 모든 노드로 전송한다.

4. 쓰기 세트는 기본 키를 사용하여 결정적 인증 테스트를 거친다. 이 작업은 쓰기 세트를 생성한 노드를 포함하여 클러스터의 각 노드에서 수행된다.

5. 각 노드가 쓰기 세트를 적용할 수 있는지 여부를 결정한다.

6. 인증 테스트에 실패하면 노드는 쓰기 세트를 삭제하고 클러스터는 원래 트랜잭션을 롤백한다. 그러나 테스트가 성공하면 트랜잭션이 커밋되고 쓰기 세트가 클러스터의 나머지 부분에 적용된다.

Galera Cluster Replication의 Write 정책은 First Committer Win이다. 트랜잭션이 커밋되는 시점에 다른 노드에 유효한 트랜잭션인지 여부를 체크하는 방식으로 동작한다. 클러스터 내에서 트랜잭션은 모든 서버에 동시에 반영되거나 전부 반영되지 않는 경우 둘 중 하나로 동작한다. 이러한 이유로 Write 트랜잭션은 하나의 서버로 사용하는 것을 권장한다.

트랜잭션을 시작하는 시점(BEGIN)에는 자신의 노드에서는 Pessimistic Locking으로 동작하나, 노드 사이에서는 Optimistic Locking Model로 동작한다. 먼저 트랜잭션을 자신의 노드에 수행을 하고, 커밋을 한 시점에 다른 노드로부터 해당 트랜잭션에 대한 유효성을 확인한다. 일반적으로 InnoDB와 같이 트랜잭션을 지원하는 시스템인 경우 SQL이 시작되는 시점에서 Lock을 확인할 수 있으나, 갈레라 클러스터에서는 커밋되는 시점에 노드 간 트랜잭션 유효성 체크한다.

트랜잭션 커밋 또는 롤백 결정은 네트워크를 통한 다른 노드와 통신에서 결정된다. 결정 요소에는 아래 항목들의 상태가 포함된다.

l 네트워크 왕복 시간

l 타 노드에서 유효성 체크 시간

l 각 노드에서 데이터 반영 시간

Galera Cluster에 필요한 최소 노드 수는 2개이다. 그러나 최소 3개의 노드가 권장된다. 최대 노드 수 제한은 없다. 그러나 10개 이상의 노드가 있는 단일 클러스터는 네트워크 또는 인터넷에서 너무 많은 노드를 동기화하는 데 지연이 발생할 수 있다. 최대 노드 수 구성은 네트워크 구성에 따라 달라지므로 각자의 환경에 맞게 구성하도록 한다.

Galera Cluster는 트랜잭션 크기를 명시적으로 제한하지 않지만 쓰기 집합은 단일 메모리 상주 버퍼로 처리되므로 결과적으로 매우 큰 트랜잭션(예: LOAD DATA)은 노드 성능에 부정적인 영향을 미칠 수 있다. 이를 방지하기 위해 wsrep_max_ws_rows 및 wsrep_max_ws_size 시스템 변수는 기본적으로 트랜잭션 행을 128K로, 트랜잭션 크기를 2Gb로 제한한다. 필요한 경우 사용자는 이러한 제한을 늘릴 수 있다. (향후 버전에서는 트랜잭션 조각화에 대한 지원을 추가할 예정이라고 한다.)

MySQL 및 MariaDB에서 고가용성을 위한 솔루션으로 Galera Cluster에 대해서 살펴보았다. 다양한 솔루션이 있지만 Galera Cluster의 특징은 모든 노드가 마스터 역할로 클러스터에 참여하는 구조로 운영되며, 각 데이터베이스 사이의 연결이 아닌 외부 wsrep API를 통한 데이터 복제가 이루어진다는 점에서 흥미로웠다. 이후 클러스터 구성 방법과 장애조치시 마스터 선정, 옵션에 대한 설정 과정을 다른 포스트에서 다뤄볼 예정이다.

[참고자료]

l https://galeracluster.com/library/documentation/

l http://galeracluster.com/documentation-webpages/galera-documentation.pdf

l http://galeracluster.com/documentation-webpages/index.html

l https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html

l https://mariadb.com/kb/en/library/getting-started-with-mariadb-galera-cluster/

l https://severalnines.com/resources/whitepapers/galera-cluster-mysql-tutorial/

l https://www.slideshare.net/marcotusa/galera-explained-3

l MariaDB Galera Cluster - Known Limitations : https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/

l https://galeracluster.com/library/faq.html

l https://www.slideshare.net/AbdulManaf19/mariadb-galera-cluster-63088921

2023-08-07 / Sungwook Kang / http://sungwookkang.com

MySQL, MariaDB, Galera Cluster, 마리아디비, 마이에스큐엘, 갈레라 클러스터, MariaDB 복제, MariaDB Cluster, MySQL Cluster, MariaDB Replication

ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까?

SungWookKang — Fri, 4 Aug 2023 10:49:43 +0900

ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까?

l Version : MySQL, ProxySQL

ProxySQL에서 서버를 추가하거나, 사용자를 등록하는 등 설정을 변경하고 적용하려면 관리자 모드 접속을 통해서 필요한 내용을 수정하고, 수정한 내용을 서비스 중단 없이 runtime에 적용할 수 있다. 그리고 서비스 재시작시 기존의 설정을 유지하기 위해서는 현재 설정 값을 데이터베이스 또는 디스크로 저장하여 재사용 할 있다.

아래 그림을 참고하여 설명하면, 일반적으로 관리자 모드에 접속하여 수정하는 부분은 MEMORY영역이다. 그렇기 때문에 관리자에서 수정하였을 경우에는 아직 메모리에서만 적용된 것으로 서비스에 적용되지 않은 상태이다. (아마도 실수가 발생하였을 때 서비스 보호를 위해서 변경 사항을 자동으로 적용시키지 않는 모델로 디자인한 것 같다.) 그리고 LOAD 명령어를 사용하여 RUNTIME영역에 적용을 할 수 있다. RUNTIME에 적용되면 서비스에 반영되어 운영된다. 그리고 메모리 값을 수정하였더라도, 런타임 기준으로 메모리 값 롤백이 필요할 때 런타임의 값을 메모리로 SAVE하여 RUNTIME설정을 메모리로 저장할 수 있다. 이러한 과정을 각 영역별로 LOAD 및 SAVE할 수 있다.

ProxySQL은 서비스를 시작할 때 config 파일을 읽어들여 datadir의 위치를 확인한다. 그 다음에 datadir 경로에 위치한 데이터베이스 파일 또는 디스크 파일이 있는지 여부를 확인하여 해당 파일을 읽어 설정 값으로 사용한다. 일반적인 설치를 진행하였다면 config 파일은 아래 경로에 존재한다.

/etc/proxysql.cnf

datadir 경로에서 데이터베이스 파일이 발견되면 ProxySQL은 지속형 온디스크 데이터베이스(proxysql.db)를 읽어 메모리 구성을 초기화한다. 따라서 디스크는 메모리에 로드된 다음 런타임 구성으로 전파된다. 데이터베이스 파일이 없는 경우에는 config 파일의 설정 값을 읽어 메모리 내 데이터베이스에 적용한 다음 온디스크 데이터베이스에 저장되고 런타임에 적용한다.

설정 값을 사용할 때 데이터베이스 파일이 발견되면 config 파일의 설정 값은 사용되지 않는다는 점에 유의해야 한다. 즉, 정상적인 시작 중에 ProxySQL은 지속형 온디스크 데이터베이스에서만 메모리 내 구성을 초기화 한다.

ProxySQL을 시작할 때 config 파일의 설정값을 메모리 및 런타임에 사용하기 위해서는 아래와 같은 순서를 적용할 수 있다.

1. 최신의 Config 파일을 배포한다. 일반적인 설치를 진행하였다면 아래 경로에 설정 파일이 위치한다.

/etc/proxysql.cnf

2. 배포한 Config 파일에 적절한 권한 부여한다. 실습에서는 775 권한을 부여하였다.

sudo chmod 775 proxysql.cnf

3. 실행중인 ProxySQL 서비스를 중지한다. 서비스 중지전에 유입되는 트래픽은 다른 곳으로 라우팅 되도록 하여 서비스 장애가 발생하지 않도록 주의한다.

sudo service proxysql stop

4. 기존의 데이터베이스 설정이 사용되지 않도록 데이터베이스 파일을 삭제한다.

sudo rm -rf /var/lib/proxysql/proxy*

5. ProxySQL 서비스를 시작한다. 이때 initial 옵션을 함께 사용한다.

sudo service proxysql start initial

실제 현업에서 ProxySQL을 운영한다고 하면 필요에 따라 다수의 ProxySQL을 운영하는 환경이 발생한다. 이러한 환경에서는 각 서버의 설정 파일을 수정하고 이력을 관리하는 것이 매우 중요하다. 그렇기 때문에 직접 서버에 접속하여 설정 파일을 수정하는 것은 이력이 남지 않아 매우 불편하면서도 위험한 상황이 발생할 수 있다. 그래서 정책적으로 config파일을 기준으로 수정하고, 이력 관리는 Git 등을 사용하면 안전한 이력 관리를 할 수 있다. 그리고 서비스 시작 시 데이터베이스 정보가 아닌 config 값을 사용하면 혼란없이 다수의 서버 환경에서 안전한 관리가 가능하다.

[참고자료]

l Configuration system : https://github.com/sysown/proxysql/blob/master/doc/configuration_system.md

2023-08-04 / Sungwook Kang / http://sungwookkang.com

MySQL, ProxySQL, ProxySQL설정, ProxySQL 구성관리, ProxySQL 시작

MySQL HA + ProxySQL 환경에서 서비스 장애조치 구성

SungWookKang — Thu, 3 Aug 2023 01:19:10 +0900

MySQL HA + ProxySQL 환경에서 서비스 장애조치 구성

l Version : MySQL, ProxySQL

MySQL HA + ProxySQL 환경에서 장애조치가 어떻게 동작하는지 알아본다. 실습 환경은 아래 포스트를 참고하여 구성할 수 있도록 한다.

l ProxySQL 설치 (MySQL 설치부터, 복제 구성, ProxySQL 설정까지 한번에) : https://sungwookkang.com/1529

l MySQL HA 환경에서 Orchestrator를 활용한 클러스터 리팩토링 및 자동 장애조치 구성 : https://sungwookkang.com/1533

실습에 사용되는 서버 구성이다.

Server Name	IP	OS	Service Version
proxy-sql	172.30.1.49	Ubuntu 22.04.2 LTS	ProxySQL version 2.4.2-0-g70336d4, codename Truls
mysql-master	172.30.1.97	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
mysql-slave1	172.30.1.10	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
mysql-slave2	172.30.1.13	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
proxy-orchestrator	172.30.1.24	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33, container.d

MySQL HA 기본 구성으로 1대의 마스터 서버와, 2대의 슬레이브 서버가 GTID 기반으로 복제 구성이 되어 있다. 그리고 서버 장애시 역할 변경을 위해 오케스트레이터로 자동 failover를 구성해 놓은 상태이다.

ProxySQL에서는 각 노드의 서비스 상태를 헬스 체크하여 서비스에 사용할 서버를 판단한다. 아래는 노드의 서비스 상태를 체크하는 모듈이다.

l connect : 모든 노드(백엔드)에 연결하고 성공 또는 실패를 mysql_server_connect_log 테이블에 기록한다.

l ping : 모든 노드 (백엔드)에 ping을 보내고 성공 또는 실패를 mysql_server_ping_log 테이블에 기록한다. mysql-monitor_ping_max_failures에 하트비트가 없으면 MySQL_Hostgroups_Manager에 신호를 보내 모든 연결을 끊는다.

l replication lag : max_replication_lag가 0보다 큰 값으로 구성된 모든 노드(백엔드)에 대해 Seconds_Behind_Master를 확인하고 mysql_server_replication_lag_log 테이블에 확인을 기록한다. Seconds_Behind_Master > max_replication_lag인 경우 Seconds_Behind_Master < max_replication_lag까지 서버를 회피한다.

l read only : mysql_replication_hostgroup 테이블의 호스트 그룹에 있는 모든 호스트에 대해 읽기 전용을 확인하고, 상태값은 mysql_server_read_only_log에 기록된다. read_only=1이면 호스트가 reader_hostgroup으로 복사/이동되고, read_only=0이면 호스트가 writer_hostgroup으로 복사/이동된다.

이번 포스트에서 다루는 ProxySQL 장애조치 시나리오는 두 가지이다.

l 시나리오 1 : slave 서버에 장애가 발생하여 장애가 발생한 서버로는 read 트래픽을 요청하지 않는다.

l 시나리오2 : master 서버에 장애가 발생하여 slave 서버중 하나가 master로 승격되고, ProxySQL의 호스트 그룹에서 Write가 가능한 호스트 그룹을 변경한다.

시나리오에 따른 실습을 하기 전에 현재 구성되어 있는 ProxySQL에 접속하여 현재의 상태를 살펴본다. proxy-sql 서버에서 아래와 같은 스크립트를 실행하여, ProxySQL 관리 모드로 접속한다.

mysql -uadmin -padmin -h 127.0.0.1 -P6032 --prompt='admin> '

현재 호스트 그룹에 등록된 서버들의 목록을 확인할 수 있다. hostgroup_id = 1 은 write가 가능한 그룹이며, hostgroup_id = 2는 읽기가 가능한 그룹이다.

select * from mysql_servers;

아래 스크립트는 등록된 서버들의 커넥션 로그를 확인한다. 만약 여기서 커넥션 오류로그가 있다면 해당 서버와의 통신에 문제가 발생한 것이다.

select * FROM monitor.mysql_server_connect_log order by time_start_us desc limit 10;

위의 커넥션 로그가 실제 쿼리가 호출될 때 확인된다면, 아래는 서비스 헬스 체크를 위한 핑 로그이다.

select * from monitor.mysql_server_ping_log order by time_start_us desc limit 10;

ProxySQL의 클라이언트용 포트로 접속하여 현재 상태에서 정상적으로 모든 서버가 응답하는지 테스트한다.

mysql -uubuntu -p123456 -h127.0.0.1 -P6033 -e "SELECT @@hostname";

아래 스크립트에서는 현재 연결된 커넥션 풀에 대한 상태를 확인할 수 있다. 실제 연결에 문제가 발생할 경우 stats_mysql_connection_pool의 status 컬럼에 상태가 변경되는 것을 확인할 수 있다.

select * from stats_mysql_connection_pool;

시나리오1. slave 서비스 장애

slave 서버중 하나에 장애가 발생한 상황으로, 장애가 발생한 서버로는 읽기 요청을 하지 않도록 하여 서비스 장애를 예방한다.

mysql-slave2 서버에 접속하여, MySQL 서비스를 중지한다.

sudo systemctl stop mysql

sudo systemctl status mysql

서비스가 종료된 상태에서 ProxySQL 관리자의 mysql_servers 테이블 상태를 살펴보면 여전히 모든 서버가 ONLINE 상태로 보이는 것을 확인할 수 있다. 사실 이 테이블은 서버의 목록을 관리하는 것이지, 서버의 상태를 나타내지는 않는다. 다만 수동으로 status 값을 OFFLINE으로 변경하면, 서비스가 활성화 상태여도 해당 서버로 트래픽을 보내지 않는다.

select * from mysql_servers;

현재 실시간의 노드의 상태를 확인하려면 runtime_mysql_servers 테이블의 정보를 확인한다. 아래 스크립트를 사용하여 중지된 서버의 상태가 SHUNNED로 표시된 것을 확인할 수 있다.

select * from runtime_mysql_servers;

커넥션 풀 상태에서도 동일하게 SHUNNED으로 나타나는 것을 확인할 수 있다.

select * from stats_mysql_connection_pool;

커넥션 로그를 확인해보면 중지된 서버(mysql-slave2)의 커넥션 실패 로그를 확인할 수 있다.

select * FROM monitor.mysql_server_connect_log order by time_start_us desc limit 10;

핑 로그에서도 오류를 확인할 수 있다.

select * from monitor.mysql_server_ping_log order by time_start_us desc limit 10;

mysql-slave2 서버의 MySQL 서비스가 중지된 상태로, ProxySQL에서도 해당 서버의 문제점을 인지한 상태이다. 이제 클라이언트 연결을 통해서 실제 운영중인 서버로만 트래픽이 정상적으로 라우팅 되는지 확인한다. 테스트를 위해 proxy-sql 서버 콘솔에서 아래 스크립트를 여러 번 실행한다.

mysql -uubuntu -p123456 -h127.0.0.1 -P6033 -e "SELECT @@hostname";

문제의 서버를 제외하고 정상적인 서버로만 트래픽을 라우팅하는 것을 확인할 수 있다. ProxySQL에서는 이렇게 문제의 서버를 감지하여 트래픽을 보내지 않음으로써 서비스 장애를 예방할 수 있다.

다른 시나리오 테스트를 진행하기 위해 중지된 서버를 시작하여 클러스터를 원상 복구한다.

시나리오2. master 서버 장애

이번 시나리오는 master서버에 장애가 발생하여, 서비스가 다운되고, slave 서버 중 하나가 master로 승격되어 운영되는 환경이다. 이때 장애를 감지하고 자동으로 서버를 승격시키는 역할은 MySQL 오케스트레이터가 한다.

mysql-master 서버에 접속하여 MySQL 서비스를 중지한다. 오케스트레이터에서는 master 서버의 장애를 감지하고, 중지된 master 서버를 클러스터에서 격리한 후 slave 서버중 하나를 master로 승격여 클러스터 토폴로지를 재구성한다.

새로 구성된 클러스터를 살펴보면 이전 slave역할이었던 mysql-slave2(172.30.1.13)서버가 master로 승격된 것을 확인할 수 있다. 그리고 나머지 slave 서버가 새로운 master를 복제하고 있다.

ProxySQL에서도 커넥션 풀 로그를 확인해보면 기존의 master역할을 하던 mysql-master(172.30.1.97)에 문제가 있음을 인지한 것을 확인할 수 있다.

select * from stats_mysql_connection_pool;

실행중인 서버의 상태를 확인해봐도 문제를 인지한 것을 확인할 수 있다.

select * from runtime_mysql_servers;

proxy-sql에서 문제가 발생한 노드가 제외되고 서비스가 정상적으로 되는지 확인한다. 호스트 이름을 검색하는 쿼리를 실행해보면 문제없이 잘 작동한다

mysql -uubuntu -p123456 -h127.0.0.1 -P6033 -e "SELECT @@hostname";

하지만 현재 상태는 정상적인 서비스를 할 수 없는 큰 문제가 있다. 현재 클러스터 상태는 기존의 mysql-master (마스터 역할) 서버가 중지되고 mysql-slave2서버가 master 역할로 승격된 상태인데, mysql_servers 테이블의 정보에는 여전히 이전의 mysql-master 서버가 hostgroup_id=1에 등록되어 있다. 실질적으로 ProxySQL에서는 Write가 가능한 서버를 잘못 인식하고 있는 상태이다. 이 정보를 업데이트하지 않으면 write에 대해서는 계속해서 실패가 발생하게 된다.

이러한 서버 장애시 hostgroup_id를 자동으로 변경하기 위해 복제 호스트 그룹으로 관리할 수 있다. 단, 이렇게 하기 위해서는 역할에 따른 MySQL 서버의 Read only 속성값이 중요하다. master 역할 서버는 read_only =false로, slave 역할의 서버는 read_only=true 로 되어 있어야 한다. 그렇지 않으면 ProxySQL에서는 read_only=false 서버를 write가 가능한 서버로 인식하기 때문에 master-master구조로 인식되어 의도하지 않는 write 오류가 발생할 수 있다.

아래 스크립트는 write가 가능한 호스트들은 1 그룹으로, 읽기가 가능한 호스트들은 2 그룹으로 할당한다. 서버의 정보를 변경하였기에 해당 변경 사항이 런타임으로 적용될 수 있도록 LOAD 명령어도 함께 실행한다.

INSERT INTO mysql_replication_hostgroups VALUES (1,2,'read_only','1=write, 2=read');

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

기존의 클러스터 구성으로 원상 복구하고, mysql-master (마스터 역할) 서버를 중지하였을 때, 오케스트레이터에서 자동 장애 조치가 활성화되어 서비스가 중지된 master 서버는 클러스터에서 분리하고, 정상적인 slave 서버중 하나를 master로 승격한다. 그리고 ProxySQL에서는 slave에서 master로 승격된 서버를 houstgroup_id=1로 자동 할당되는 것을 확인할 수 있다.

런타임 서버 상태 테이블에서도 장애가 발생한 서버는 SHUNNED로 변경되어 서비스에서 제외된 것을 확인할 수 있으며, 새로운 master 서버가 hostgroup_id=1 변경된 것을 확인할 수 있다.

이번 실습을 통해서 mysql_servers의 테이블은 호스트의 상태 값을 관리하는 테이블이 아닌 호스트 그룹을 관리하기 위한 서버 목록 용도로 사용되는 것을 알 수 있었으며, 실제 서비스들의 상태나 운영가능한 호스트들이 목록은 runtime_mysql_servers 테이블에서 확인 가능한 것을 알 수 있었다.

MySQL 오케스트레이터와 ProxySQL을 조합하여 사용할 경우, 오케스트레이터에서는 자동으로 장애를 감지하고 클러스터 토폴로지 재구성으로 빠르게 역할을 승격하여 안정적인 서비스를 유지할 수 있고, ProxySQL에서는 오케스트레이션에서 승격시킨 서버의 상태를 확인하여 호스트 그룹의 정보를 자동으로 변경함으로써, 만약의 상태에도 안정적인 서비스가 가능한 구성을 만들 수 있다는 것을 확인할 수 있다.

[참고자료]

l Orchestrator : https://github.com/openark/orchestrator

l Failure detection : https://github.com/openark/orchestrator/blob/master/docs/failure-detection.md

l MySQL Orchestrator - HA(High Availability) - 2 - 리팩토링 Failover Automated Recovery : https://hoing.io/archives/91

l Configuration: failure detection : https://github.com/openark/orchestrator/blob/master/docs/configuration-failure-detection.md

l https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case : https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case

l Orchestrator: MySQL Replication Topology Manager : https://www.percona.com/blog/orchestrator-mysql-replication-topology-manager/

l Orchestrator and ProxySQL : https://www.percona.com/blog/orchestrator-and-proxysql/

2023-08-02 / Sungwook Kang / http://sungwookkang.com

MySQL, ProxySQL, MySQL Replication, MySQL HA, MySQL복제 오케스트레이션, MySQL복제설치, MySQL MHA, MySQL Orchestrator , MySQL장애조치, MySQL고가용성

MySQL HA 환경에서 Orchestrator를 활용한 클러스터 리팩토링 및 자동 장애조치 구성

SungWookKang — Thu, 27 Jul 2023 23:09:46 +0900

MySQL HA 환경에서 Orchestrator를 활용한 클러스터 리팩토링 및 자동 장애조치 구성

l Version : MySQL, Orchestrator

MySQL HA 환경에서 Orchestrator(이하 ‘오케스트레이터’)를 활용하여 클러스터 리팩토링 및 장애조치 방법에 대해서 알아본다. 이번 실습을 진행하기 위해서는 MySQL HA 및 Orchestrator 구성이 완료되어 있어야 한다. 아래 링크를 참고하여 HA구성 및 Orchestrator를 구성할 수 있도록 한다.

l ProxySQL 설치 (MySQL 설치부터, 복제 구성, ProxySQL 설정까지 한번에) : https://sungwookkang.com/1529

l MySQL 고가용성 운영을 위한 Orchestrator 설치 : https://sungwookkang.com/1532

실습에 사용되는 서버 구성이다.

Server Name	IP	OS	Service Version
proxy-sql	172.30.1.49	Ubuntu 22.04.2 LTS	ProxySQL version 2.4.2-0-g70336d4, codename Truls
mysql-master	172.30.1.97	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
mysql-slave1	172.30.1.10	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
mysql-slave2	172.30.1.13	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
proxy-orchestrator	172.30.1.24	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33, container.d

MySQL HA 기본 구성으로 1대의 마스터 서버와, 2대의 슬레이브 서버가 GTID 기반으로 복제 구성이 되어 있다.

이번 포스트에서 4개의 시나리오를 구성해 보았으며, 각 시나리오별로 실습 과정을 다루었다.

시나리오1. Slave Refactoring

Slave간에 복제 토폴로지 리팩토링으로, 슬레이브1, 슬레이브2가 마스터에서 싱크하던 환경에서, 슬레이브2가 슬레이브1에서 복제를 싱크할 수 있도록 토폴로지를 변경한다.

시나리오2. Master Refactoring (Promote)

슬레이브 서버를 마스터로 승격시키고, 기존의 마스터를 슬레이브로 역할을 전환한다.

시나리오3. Master – Master Refactoring

슬레이브 서버중 하나를 마스터로 승격시켜 두 대의 마스터로 구성한다.

시나리오4. Master Failover

기존의 운영중이던 마스터 서버를 강제로 중지하여 장애 상황을 구현한 다음, 현재 슬레이브로 운영되던 서버중 하나가 새로운 마스터가 되어 장애조치 된다. 그리고 나머지 슬레이브 서버는 새로운 마스터 서버와 복제 싱크를 한다.

실습환경 살펴보기

오케스트레이터 대시보드에 접속하면 현재 구성되어 있는 클러스터 목록을 볼 수 있다. 여기에서 숫자 3과 1이 보이는데, 3은 현재 구성된 클러스터의 전체 서버 개수이며, 2는 슬레이브 서버 개수이다.

클러스터를 클릭해보면 현구 구성되어 있는 클러스터 토폴로지를 확인할 수 있다. 각 시나리오에 따라 서버의 역할이 변경되기 때문에, 현재 구성되어 있는 서버이름과 역할을 혼돈하지 않도록 주의한다.

시나리오1. Slave Refactoring

mysql-slave2(172.30.1.13)서버를 드래그하여 mysql-slave1(172.30.1.10) 서버에 드롭한다. 이때 드롭 할 위치가 중요하다. 서버의 중간쯤으로 이동하면 드롭하는 서버 정보에 relocate라고 표시가 되는데 이때 드롭한다.

Relocate에 대한 변경 사항에 대해서 경고 팝업이 나타나고 OK를 클릭하면 변경 사항이 적용된다.

클러스터 토폴로지 구조가 변경된 것을 확인할 수 있다.

mysql-slave2(172.30.1.13) 서버에 접속하여 호스트 이름 및 복제 상태를 조회해 보면, 현재 mysql-slave1(172.30.1.10) 서버를 마스터 호스트로 연결되어 있는 것을 확인할 수 있다.

select @@host;
show slave status\G;

시나리오를 처음 상태로 원상복구하려면 mysql-slave2(172.30.1.13)를 드래그하여 mysql-master(172.30.1.97)에 드롭 한다.

Relocate에 대한 변경 사항에 대해서 경고 팝업이 나타나고 OK를 클릭하면 변경 사항이 적용된다.

클러스터 토폴로지 구조가 변경된 것을 확인할 수 있다.

mysql-slave2(172.30.1.13) 서버에 접속하여 호스트 이름 및 복제 상태를 조회해 보면, 현재 mysql-master(172.30.1.97) 서버가 마스터 호스트로 연결되어 있는 것을 확인할 수 있다.

시나리오2. Master Refactoring (Promote)

슬레이브 서버를 마스터로 승격시키고, 기존의 마스터를 슬레이브로 역할을 전환한다.

mysql-slave1(172.30.1.10)을 드래그 하여 mysql-master(172.30.1.97)로 드롭 한다. 이때 드롭하는 위치를 현재 마스터보다 조금 앞으로 위치하여 PROMOTE AS MASTER가 표시될 때 드롭 한다. (마스터 보다 뒤에 할 경우 relocate로 표시된다.)

Takeover에 대한 경고 팝업이 나타나고 OK를 클릭하면 변경 사항이 적용된다.

변경사항을 적용하였을 때, 대시보드 화면이 바로 갱신이 안되는 경우가 있다. 이때 새로고침을 하면 변경사항이 정상적으로 나타난다. 현재 구성되어 있는 토폴로지 상태를 보면, mysql-slave1(172.30.1.10) 서버가 master 역할을 하며, mysql-master(172.30.1.97)서버가 slave 역할을 하는 것으로 역할 체인지가 된 것을 확인할 수 있다. 하지만 mysql-master(172.30.1.97) 서버를 보면 역할 변경 후 새로운 마스터에 대한 복제 구성이 되지 않아서 오류로 표시되고 있다.

복제 시작을 위해 slave역할의 mysql-master(172.30.1.97) 서버에서 메뉴 아이콘을 클릭하면 설정 팝업이 나타나는데, [Start replication]을 클릭한다.

복제가 정상적으로 구성되고 모든 클러스터가 정상으로 표시되는 것을 확인할 수 있다.

다음 실습을 준비하기 위해 원래 클러스터 토폴로지 구조로 원상복구를 한다. 원상복구 방법은 앞에서 했던 방법과 동일하게 진행한다.

시나리오3. Master – Master Refactoring

슬레이브 서버중 하나를 마스터로 승격시켜, 두 대의 마스터로 구성한다.

mysql-master(172.30.1.97) 서버를 드래그 하여 mysql-slave1(172.30.1.10)에 드롭 한다. 이때 MAKE CO MASTER가 표시되면 드롭 한다.

make-co-master에 대한 경고 팝업이 나타나고 OK를 클릭하면 변경 사항이 적용된다.

실행이 완료되면 클러스터 토폴로지 구성이 master – master 로 변경된 것을 확인할 수 있다.

정확히는 master-master 구조만 만들어진 상황으로, 완벽한 master-master 작동을 하는 것은 아니다. 환경은 구성되었지만 mysql-slave(172.30.1.10) 서버는 현재 Read Only 상태이다. [Set writeable]를 클릭하여 쓰기 상태로 변경해야 사용가능한 master-master 환경이 된다.

master-master 구조에서 master-salve로 원복하기 위해서는 mysql-master(172.30.1.97) 서버에서 설정 아이콘을 클릭한다. 팝업이 나타나면 Master 항목에서 [Reset replica]를 클릭한다.

이전과 같은 상태로 클러스터 토폴로지가 구성된 것을 확인할 수 있다.

시나리오4. Master Failover

현재 master역할을 하고 있는 mysql-master(172.30.1.97) 서버에 접속하여 MySQL 서비스를 강제로 중지한다.

hostname

sudo systemctl stop mysql

MySQL 서비스가 중지되고 오케스트레이터가 장애 상황을 인지하면 아래와 같이 대시보드 상태가 변경된다. 파란색 숫자3은 현재 구성되어 있는 클러스터 서버 개수이며, 빨간색 숫자2는 슬레이브 개수이며 복제 불가능을 표시하고 있다. 검은색 1은 응답 없는 서버 개수를 나타낸다.

해당 클러스터를 클릭해서 상세 대시보드를 살펴보면, 현재 mysql-master(172.30.1.97) 서버가 응답 없음을 나타내고 있으며, 슬레이브는 복제가 되지 않는 것을 확인할 수 있다. 우측의 느낌표를 클릭하면 각 노드의 에러 메시지를 상세하게 확인할 수 있다.

오류 메시지는 오케스트레이터의 로그 파일에서도 확인할 수 있다. 특별히 경로를 변경하지 않았으면 아래 경로에서 확인 가능하다. 만약 경로 확인이 필요하면 설정 파일에서 확인할 수 있다.

/tmp/recovery.log

[수동 Failover]

오케스트레이터의 장애조치 모드 기본값은 수동이다. 수동으로 장애조치는 관리자가 문제를 인지하고 직접 장애 조치를 진행해야 한다. 현재 응답이 없는 mysql-master(172.30.1.97) 서버에서 [Recover]를 클릭한다. Failover 가능한 서버 목록에서, mysql-salve1(172.30.1.10)서버로 장애조치를 진행한다.

장애조치를 실행하게 되면, 응답 없는 서버를 기존의 클러스터에 분리된다. 기존 서비스가 중지된 mysql-master 노드는 기존 클러스터에서 분리된 것을 확인할 수 있다.

클러스터를 클릭하여 상세 내용을 보면 mysql-slave1(172.30.1.10) 서버가 master역할을 하고, mysql-slave2(172.30.1.13) 서버가 slave역할을 하는 것을 확인할 수 있다.

mysql-master(172.30.1.97) 서버를 복구했다는 가정하에 mysql-master(172.30.1.97) 서비스를 다시 시작한다.

MySQL 서버가 정상적으로 실행되었으며 현재는 독립적으로 실행되고 있기 때문에, 기존의 복제 클러스터에 조인하기 위해서는 현재 master 역할로 운영중인 mysql-slave1(172.30.1.10) 서버로 복제를 연결한다.

복제가 성공적으로 연결되고, 복제 싱크가 완료되면 오케스트레이터 대시보드에서도 클러스터가 정상적으로 연결되어 운영되는 것을 확인할 수 있다.

[자동 failover]

기본 모드가 수종이기 때문에, 자동으로 장애조치를 하기 위해서는 파라메터 수정이 필요하다. 아래 경로의 설정파일에서 수정할 수 있다. 설정 파라메터의 종류가 많기 때문에 주의해서 살펴본다.

vi /usr/local/orchestrator/orchestrator.conf.json

변경전	변경후
"RecoveryPeriodBlockSeconds": 3600, "RecoveryIgnoreHostnameFilters": [], "RecoverMasterClusterFilters": [ "_master_pattern_" ], "RecoverIntermediateMasterClusterFilters": [ "_intermediate_master_pattern_" ],	"RecoveryPeriodBlockSeconds": 10, "RecoveryIgnoreHostnameFilters": [], "RecoverMasterClusterFilters": [ "" ], "RecoverIntermediateMasterClusterFilters": [ "" ],

설정 변경을 완료하였으면, 오케스트레이터는 설정 파일에 대한 변경사항을 런타임중에 적용할 수 있다. 대시보드 상단 메뉴에서 [Home] - [Status]를 클릭한다. Status페이지에서 [Reload congifuration]을 클릭하여 설정을 로드 한다.

자동 장애조치 테스트를 위해 현재 master로 운영중인 서버의 MySQL을 강제로 중지한다.

Master서버가 중지되고 오케스트레이터에서 장애 상황을 인지한 다음 자동으로 장애조치가 완료되면 대시보드에서 아래와 같이 두 개의 클러스터를 볼 수 있다. 장애가 발생한 서버는 기존 클러스터에서 분리가 되었다.

각 클러스터를 클릭해서 상태를 살펴보면, 기존의 slave 서버중에 하나가 master로 승격되고, 나머지 슬레이브가 새로운 마스터에 조인되어 싱크되는 것을 확인할 수 있다.

분리된 장애 서버에서는 Recover를 클릭해도 클러스터에서 분리된 상태이기 때문에 failover할 수 있는 서버 목록을 찾을 수 없다고 표시된다.

지금까지 MySQL HA환경에서 오케스터레이터를 활용하여 토포로지 리팩토링 및 장애조치 하는 방법에 대해서 살펴보았다. 장애조치를 진행할 때 운영중인 서버중 하나가 랜덤하게(정확히는 씽크가 가장 빠른 서버) 마스터로 승격되는 것을 확인하였는데, 이 또한 파라메터를 수정하여 다양한 조건을 부여하여 우선순위조건을 조정할 수 있다. 앞애서도 살펴보았듯이 파라메터의 종류가 매우 많다. 상세한 내용은 다른 포스트에서 하나씩 살펴볼 예정이다.

[참고자료]

l Orchestrator : https://github.com/openark/orchestrator

l Failure detection : https://github.com/openark/orchestrator/blob/master/docs/failure-detection.md

l MySQL Orchestrator - HA(High Availability) - 2 - 리팩토링 Failover Automated Recovery : https://hoing.io/archives/91

l Configuration: failure detection : https://github.com/openark/orchestrator/blob/master/docs/configuration-failure-detection.md

l https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case : https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case

l Orchestrator: MySQL Replication Topology Manager : https://www.percona.com/blog/orchestrator-mysql-replication-topology-manager/

l Orchestrator and ProxySQL : https://www.percona.com/blog/orchestrator-and-proxysql/

2023-07-27 / Sungwook Kang / http://sungwookkang.com

MySQL, ProxySQL, MySQL Replication, MySQL HA, MySQL복제 오케스트레이션, MySQL복제설치, MySQL MHA, MySQL Orchestrator, MySQL장애조치, MySQL고가용성

MySQL 고가용성 운영을 위한 Orchestrator 설치

SungWookKang — Tue, 25 Jul 2023 23:48:42 +0900

MySQL 고가용성 운영을 위한 Orchestrator 설치

l Version : MySQL, Orchestrator

데이터베이스를 운영할 때 단일 장애 포인트(SPOF, Single Point Of Failure)를 예방하기 위해서 고가용성(HA, High-Available)은 매우 중요한 부분이다. 그렇기 때문에 클러스터링, 복제 등 고가용성으로 구성된 다수의 데이터베이스를 효율적으로 관리하기 위해 다양한 솔루션들이 존재한다.

이번 포스트는 MySQL 및 MariaDB의 고가용성을 효율적으로 운영하기 위한 솔루션인 Orchestrator(이하 ‘오케스트레이터’)에 대해서 알아본다. 오케스트레이터는 MySQL 고가용성 및 복제 관리 도구로, 서비스로 실행되며 명령줄 액세스, HTTP API 및 웹 인터페이스를 제공한다.

l Orchestrator : https://github.com/openark/orchestrator

오케스트레이터의 주요 기능으로는 아래와 같다.

l Discovery : 토폴로지를 통해 지속적으로 클러스터의 복제 상태 및 구성과 같은 기본 MySQL 정보를 읽어 오케스트레이션에 매핑한다. 장애가 발생하였을 때 복제 문제를 포함하여 토폴로지의 자세한 정보를 시각화로 제공한다.

l Refactoring : 복제 서버의 Binlog file:position, GTID, Pseudo GTID등 다양한 정보를 수집한다. 복제 토폴로지에서 리팩토링은 GUI에서 복제본을 다른 마스터 아래로 끌어서 놓는 방식으로 안전하게 진행할 수 있다. 오케스트레이터는 비정상적인 리팩토링 시도를 거부하며 다양한 명령줄 옵션을 통해 세밀한 제어가 가능하다.

l Recovery : 전체적인 접근 방식을 사용하여 마스터 및 중간 마스터 오류를 감지한다. 토폴로지 자체에서 얻은 정보를 기반으로 다양한 장애 시나리오를 인식한다. 장애가 인식되면 자동 또는 수동 복구를 수행하도록 구성할 수 있다. 복구 프로세스는 오케스트레이터의 토폴로지 이해와 리팩토링 수행 능력을 활용하며, 구성이 아닌 상태를 기반으로 한다. 오케스트레이터는 자체 복구시 토폴로지를 조사/평가하여 최상의 복구 방법을 선택한다.

오케스트레이터는 다양한 인터페이스를 지원하는데 명령줄 인터페이스(CLI, Command Line Interface)를 활용하여 디버그 메시지 등을 수집하고 자동화된 스크립팅을 제어할 수 있다. 그 외에도 다양한 Web API (HTTP Get access) 및 웹 인터페이스를 제공한다.

l Highly available

l Controlled master takeovers

l Manual failovers

l Failover auditing

l Audited operations

l Pseudo-GTID

l Datacenter/physical location awareness

l MySQL-Pool association

l HTTP security/authentication methods

Orchestrator를 사용하려면 우선 MySQL복제 환경이 구성되어 있어야 한다. 오케스트레이터 구성에서 GTID 사용을 권장하고 있으나, Binlog position 사용시 Pseudo GTID를 사용하면 된다. MySQL 복제 구성은 아래 링크를 참고한다.

l ProxySQL 설치 (MySQL 설치부터, 복제 구성, ProxySQL 설정까지 한번에) : https://sungwookkang.com/1529

오케스트레이터를 구성할 서버 정보들이다. 위 링크에서 구성한 환경을 기반으로 진행한다.

Server Name	IP	OS	Service Version
proxy-sql	172.30.1.49	Ubuntu 22.04.2 LTS	ProxySQL version 2.4.2-0-g70336d4, codename Truls
mysql-master	172.30.1.97	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
mysql-slave1	172.30.1.10	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
mysql-slave2	172.30.1.13	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33
proxy-orchestrator	172.30.1.24	Ubuntu 22.04.2 LTS	mysql Ver 8.0.33, container.d

proxy-orcherator서버에는 오케스트레이터가 설치되어 운영된다. 오케스트레이터에서 필요한 정보를 저장하기 위해 오케스트레이터용 리포지토리 MySQL을 설치한다.

sudo apt-get install mysql-server

MySQL설치가 완료되면 오케스트레이터가 사용할 계정 및 데이터 베이스를 생성한다. 테스트 용도이기 때문에 편의상 전체 권한을 부여한다. 실제 업무에서 사용할 때에는 보안 정책에 따라 오케스트레이터에 필요한 권한만 할당한다.

--데이터베이스 생성
CREATE DATABASE IF NOT EXISTS orchestrator;

--사용자 생성
CREATE USER 'orchestrator'@'%' IDENTIFIED BY 'orchestrator';
--GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator'@'%';
--GRANT SELECT ON mysql.slave_master_info TO 'orchestrator'@'%';

GRANT ALL PRIVILEGES ON *.* TO 'orchestrator'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

이번 포스트에서는 컨테이너로 빌드된 오케스트레이터를 설치하기 때문에, 컨테이너를 실행할 수 있는 도커 패키지를 설치한다.

--시스템 패키지 업데이트
sudo apt-get update

--필요한 패키지 설치
sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

--Docker의 공식 GPG키를 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

--Docker의 공식 apt 저장소를 추가
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

--시스템 패키지 업데이트
sudo apt-get update

--Docker 설치
sudo apt-get install docker-ce docker-ce-cli containerd.io

--Docker 서비스 실행 확인
sudo systemctl status docker

도커 설치가 완료되었으면, 도커 허브에서 오케스트레이터 컨테이너를 다운로드 한다.

ü https://hub.docker.com/r/openarkcode/orchestrator

아래 스크립트를 실행하면 도커 이미지가 다운로드 되며, 현재 호스트에 저장되어 있는 도커 이미지를 확인할 수 있다.

sudo docker pull openarkcode/orchestrator
sudo docker images

아래 스크립트를 사용하여 도커를 실행한다.

sudo docker run -d --name orchestrator -p 3000:3000 openarkcode/orchestrator

오케스트레이터 서비스가 정상적으로 실행되었으면, 웹 브라우저를 사용하여 오케스트레이터 대시보드로 접속한다.

http://172.30.1.24:3000/

상단의 [Cluster] – [Discover]에서 MySQL 클러스터를 등록할 수 있다. 기본값으로 호스트 이름으로 등록하게 되어 있다. 호스트 이름으로 MySQL 서버들을 검색하려면 proxy-orchstrator (오케스트레이터의 호스트 서버) 서버의 /etc/hosts 파일에 호스트 정보를 등록한다.

서버 이름이 아닌 서버IP로 클러스터 서버를 찾기 위해서는 아래와 같이 설정 파일을 수정하여 사용할 수 있다. 기본적으로 설정 파일은 아래 경로에 있다.

/usr/local/orchestrator/

컨테이너 환경에서는 컨테이너 내부에서 파일 수정을 하는 것은 좋은 방법은 아니지만 실습 편의상 컨테이너 내부 쉘로 접근해서 수정하였다. 실제 서비스 환경에서는 컨테이너 특성상 데이터가 휘발되기 때문에 반드시 설정파일 따로 보관할 수 있도록 한다. 아래 스크립트는 실행 중인 컨테이너의 ID를 확인하고, 해당 컨테이너 쉘로 접근한다.

sudo docker ps -a
sudo docker exec -it 93c5bfafa537 /bin/bash

설정파일이 위치한 경로로 이동하여 설정 파일을 수정한다.

cd /usr/local/orchestrator/
sudo cp orchestrator-sample.conf.json orchestrator.conf.json
vi orchestrator.conf.json

오케스트레이터 서버가 MySQL 클러스터 서버들에게 접속할 수 있는 계정과 비밀번호를 입력한다. 사용자 환경에 맞게 수정하여 사용한다.

"MySQLTopologyUser": "orc_client_user",
"MySQLTopologyPassword": "orc_client_password",

오케스트레이터 서버가 orchester 데이터베이스 접속할 수 있는 계정과 비밀번호를 입력한다. 오케스트레이터용 리포지토리 MySQL 설치 단계에서 생성한 계정을 입력하도록 한다.

"MySQLOrchestratorHost": "127.0.0.1",
"MySQLOrchestratorPort": 3306,
"MySQLOrchestratorDatabase": "orchestrator",
"MySQLOrchestratorUser": " orchestrator ",
"MySQLOrchestratorPassword": " orchestrator ",

호스트 이름 대신 IP로 검색할 수 있도록 옵션을 수정한다.

변경 전	"HostnameResolveMethod": "default", "MySQLHostnameResolveMethod": "@@hostname",
변경 후	"HostnameResolveMethod": "none", "MySQLHostnameResolveMethod": "",

GTID를 사용하지 않고 binlog position을 사용할 경우 failover를 위해서 PeseudoGTID를 활성화 하기위해 아래 파리메터를 입력한다. 해당 파라메터는 설정 파일에 없으므로 직접 추가해야 한다.

"AutoPseudoGTID": true,

각종 로그파일은 아래 경로에서 확인할 수 있다. 필요시 사용자 경로에 맞게 수정하여 사용할 수 있다.

"OnFailureDetectionProcesses": [
"echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countSlaves}' >> /tmp/recovery.log"
],
"PreGracefulTakeoverProcesses": [
"echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /tmp/recovery.log"
],
"PreFailoverProcesses": [
"echo 'Will recover from {failureType} on {failureCluster}' >> /tmp/recovery.log"
],
"PostFailoverProcesses": [
"echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostUnsuccessfulFailoverProcesses": [],
"PostMasterFailoverProcesses": [
"echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Promoted: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostIntermediateMasterFailoverProcesses": [
"echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
],
"PostGracefulTakeoverProcesses": [
"echo 'Planned takeover complete' >> /tmp/recovery.log"
],

설정값 변경이 완료되었으면 해당 사항을 저장하고 오케스트레이터 서비스를 재시작한다. 오케스트레이터 대시보드에 접속하여 IP로 Discover를 등록할 수 있다. 서버는 master 역할 서버만 입력한다.

정상적으로 등록이 완료되면 아래와 같이 등록된 서버가 나타난다.

해당 서버를 클릭하면 현재 구성된 토폴로지 및 상태를 나타내는 대시보드를 볼 수 있다,

대시보드에 나타난 서버들을 클릭해보면 현재 상태의 상세 정보를 확인할 수 있으며, 일부 제어를 할 수 있는 메뉴가 나타난다.

[참고자료]

l Orchestrator : https://github.com/openark/orchestrator

l MySQL Orchestrator - HA(High Availability) - 1 - 기능 설명 및 설치 : https://hoing.io/archives/72

l https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case : https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case

l Orchestrator: MySQL Replication Topology Manager : https://www.percona.com/blog/orchestrator-mysql-replication-topology-manager/

l Orchestrator and ProxySQL : https://www.percona.com/blog/orchestrator-and-proxysql/

2023-07-25 / Sungwook Kang / http://sungwookkang.com

MySQL, ProxySQL, MySQL Replication, MySQL HA, MySQL복제 오케스트레이션, MySQL복제설치, MySQL MHA, MySQL Orchestrator

ProxySQL Internals 및 시스템 구성 둘러보기

SungWookKang — Mon, 24 Jul 2023 21:23:09 +0900

ProxySQL Internals 및 시스템 구성 둘러보기

l Version : ProxySQL

이번 포스트에서는 ProxySQL의 인터널 구조와 설정 파일의 구조에 대해서 살펴본다. 상세한 인터널 구조를 모두 설명하지는 않으며 전체적인 구조 및 특징만 소개하도록 한다. 세부적인 내용은 다른 포스트에서 하나씩 다뤄볼 예정이다.

ProxySQL이 시작되면 즉시 새 프로세스를 생성한다. 상위 프로세스는 엔젤 프로세스(와치독과 비슷한 의미로 해석됨)로 작동하고 ProxySQL이 크래시 되었을 때 수 밀리초 내에 서비스를 다시 시작한다. MySQL에 비유하면 mysqld_safe와 매우 유사하다.

ProxySQL에는 기본적으로 두 개의 포트가 필요하다. 트래픽을 수신하는 6033 포트와 ProxySQL을 관리하기 위한 게이트웨이 역할을 하는 6032포트이다. 명령줄 관리 인터페이스(CLI)는 MySQL 클라이언트에서 액세스할 수 있다. 대부분의 구성은 SQL을 사용하여 수행된다. ProxySQL이 구성을 저장하는 데 사용하는 기본 데이터베이스는 SQLite이지만 가능한 한 MySQL에 가까운 환경을 만들기 위해 노력한 흔적을 볼 수 있다. 그 예로 일부 MySQL 구문을 사용하여 ProxySQL 구성을 확인하거나(SHOW GLOBAL VARIABLES) 새 구성을 설정 (SET GLOBAL variable_name = value) 할 수 있다. 백엔드 구성은 테이블에 저장된다. 모든 변경 사항은 SQL(INSERT, UPDATE, DELETE)을 통해 이루어진다.

l Query processor/rules engine : ProxySQL은 MySQL 프로토콜(쿼리)을 해석한다. 규칙 엔진은 들어오는 트래픽을 일치시키고 쿼리를 캐시할지 또는 호스트 그룹 대상에 쿼리를 차단, 경로 재지정, 쿼리 재작성 또는 미러링 할지 여부를 정의한다.

l User authentication : 기본 데이터베이스에 대한 사용자 자격 증명이 해시되어 프록시에 저장된다.

l Hostgroup manager : 트래픽을 보낼 서버 그룹을 관리하고 해당 상태를 추적한다.

l Connection pool : 백엔드 데이터베이스에 대한 연결을 관리한다. 연결 풀은 백엔드를 향해 설정되며 모든 애플리케이션에서 공유/재사용된다.

l Monitoring : 백엔드를 모니터링하고 지표를 수집한다. 모니터링을 하면서 응답하지 않는 호스트 또는 복제 지연에 대해 필요에 따라 트래픽을 제어한다.

Query Processor는 SQL 트래픽을 분석하고 이해할 수 있으므로 광범위한 라우팅을 수행할 수 있다. 스키마, 사용자, 호스트, 포트 또는 정규 표현식과 같은 다양한 속성으로 쿼리를 일치시킬 수 있다. 이렇게 하면 변경하려는 쿼리와 관련하여 상당한 유연성을 얻을 수 있다. 예를들어 쿼리캐시는 쿼리 대기 시간을 줄일 수 있도록 정의된 시간(TTL) 동안 캐시할 수 있다. 이러한 기능은 일반적으로 응용 프로그램에 추가 복잡성을 도입하는 외부 캐싱 계층의 필요성을 제거할 수도 있다. 또한 MySQL 쿼리 캐시(결국 8.0에서 제거됨)보다 훨씬 나은 솔루션일 수도 있다. 그리고 사용자 정의에 따라 쿼리를 제한할 수도 있다. 예를들어 성능에 영향을 미치는 무거운 쿼리들을 초당 한 번 또는 분당 한 번만 실행되도록 할 수 커스텀하게 설정할 수 있다. 쿼리 미러링기능도 있지만 아직은 모든 트래픽이 미러되는 것은 아니기 때문에 큰 기대를 할 정도는 아니다. 그러나 특정 상황에서 매우 유용하게 활용하 수 있다. 주어진 쿼리에 대해 프로덕션 호스트뿐만 아니라 별도의 위치로 보내서 슬로우 로그에서 캡처하거나 일부 디버깅을 수행할 수 있다. 쿼리 재작성을 통해 쿼리를 즉석에서 재작성할 수 있다. 간단한 FORCE INDEX로 문제를 해결할 수 있지만 앱 수정, 테스트, 새 코드 롤 등의 시간 소모적인 프로세스를 거치지 않고는 문제를 추가할 수 없는 상황에서, ProxySQL에서 쿼리를 다시 작성하면서 인덱스 힌트 등을 추가할 수 있다.

ProxySQL은 매우 복잡한 구조를 가진것 처럼 보이지만, 시스템을 구성하고 사용하는데 있어서는 4개의 계층(Runtime, Memory, Disk, Configuration file)을 제공하여 쉽게 사용할 수 있다. 특징으로는 설정에 대해서 즉시 업데이트가 되고, 데몬의 재시작 없이 적용할 수 있다. 또한 잘못 구성되었을 경우에도 쉽게 롤백 할 수 있다.

RUNTIME

Runtime은 ProxySQL 기동 및 운영에 사용된다. 요청을 처리하는 스레드에서 사용하는 ProxySQL의 메모리 내 데이터 구조를 나타낸다. 여기에는 사용된 전역 변수의 값, 호스트 그룹으로 그룹화된 백엔드 서버 목록 또는 프록시에 연결할 수 있는 MySQL 사용자 목록이 포함된다. 운영자는 RUNTIME 구성 섹션의 내용을 직접 수정할 수 없다. 하위 레이어를 수정하고 그 내용을 적용시킬 수 있다.

MEMORY

MEMORY(메인이라고도 함)는 MySQL 호환 인터페이스를 통해 외부에 노출되는 메모리 내 SQLite3 데이터베이스를 나타낸다. 사용자는 이 인터페이스에 MySQL 클라이언트를 연결하고 다른 테이블과 데이터베이스를 쿼리할 수 있다. 이 인터페이스를 통해 사용할 수 있는 구성 테이블은 다음과 같다.

l mysql_servers : ProxySQL에서 중계할 서버들의 목록을 관리한다. 중계 대상 서버를 백엔드 서버라고 부른다.

l mysql_users : ProxySQL에 연결할 수 있는 사용자 및 자격 증명 목록으로, ProxySQL은 이러한 자격 증명을 사용하여 백엔드 서버에도 연결한다.

l mysql_query_rules : 다른 백엔드 서버로 트래픽을 라우팅하기 위한 규칙 목록으로 이러한 규칙으로 인해 쿼리를 다시 작성하거나 결과를 캐싱할 수도 있다.

l global_variables : 런타임에 조정할 수 있는 프록시 전체에서 사용되는 전역 변수 목록이다. 아래 그림은 글로벌 전역 변수 예시이다.

l mysql_collations : 프록시가 작업할 수 있는 MySQL 데이터 정렬 목록으로 클라이언트 라이브러리에서 직접 추출된다.

l debug_levels (디버그 빌드에서만 사용 가능) : ProxySQL이 세부 수준과 함께 내보내는 디버그 문의 유형 목록이다. 이를 통해 다양한 문제를 디버깅하기 위해 로그에 어떤 종류의 명령문이 있는지 런타임에 쉽게 구성할 수 있다. 성능에 영향을 줄 수 있으므로 디버그 빌드에서만 사용할 수 있다.

DISK

DISK는 기본 위치가 $(DATADIR)/proxysql.db인 온디스크 SQLite3 데이터베이스를 나타낸다. ProxySQL 자체 데이터베이스가 실제로 동작하는 곳의 이름이 memory인 이유는, 실제로 in-memory 형태의 SQLite3 데이터베이스가 상주하고 있기 때문이다. ProxySQL 서비스를 다시 시작하면 유지되지 않은 메모리 내 구성이 손실되므로 구성을 DISK에 유지하는 것이 중요하다.

CONFIG

CONFIG 파일은 전형적인 구성 파일이다. Memory에서 운영중인 설정 파일을 덤프할 수 있다. 서비스를 시작하는 동안 ProxySQL은 구성 파일(있는 경우)을 읽어, 지정된 경로에서 내부 데이터베이스 파일을 찾으려고 시도한다. 지정된 경로에 데이터베이스 파일을 발견되면 ProxySQL은 디스크의 데이터베이스를 사용하여 메모리 구성을 초기화한다. 즉, 디스크 구성이 MEMORY에 로드되고 RUNTIME에도 전파된다. 데이터베이스 파일을 찾을 수 없는 경우(예: ProxySQL이 처음으로 실행 중이거나 데이터베이스가 삭제된 경우) 구성 파일의 정보가 MEMORY에 로드되고 DISK 데이터베이스에 저장되며 RUNTIME에도 전파된다.

l Initial startup (옵션 –initial) : ProxySQL을 처음 시작하는 동안 메모리 및 런타임 구성이 구성 파일에서 채워지고 그 후 모든 구성이 ProxySQL의 내부 데이터베이스에 저장된다. –initial 옵션은 SQLite 데이터베이스 파일을 원래 상태(즉, 구성 파일에 정의된 상태)로 재설정하고 기존 SQLite 데이터베이스 파일의 이름을 바꾸는 플래그 와 함께 proxysql을 실행하여 초기 구성을 강제로 다시 발생시킬 수 있다. 롤백이 필요한 경우 사용한다.

l Reload startup (옵션 –reload flag) : ProxySQL 바이너리가 --reload플래그와 함께 실행되면 구성 파일의 구성을 데이터베이스 파일의 내용과 병합하려고 시도한다. 그런 다음 새로 병합된 구성을 사용하여 시작된다. 충돌이 있을 때 ProxySQL이 두 구성 소스를 성공적으로 병합할 것이라는 보장은 없으며 사용자는 항상 병합이 예상대로 실행되었는지 확인해야 한다.

l Runtime ProxySQL Configuration : 런타임 시 구성 설정은 ProxySQL(기본적으로 6032)의 ProxySQL 관리 포트를 통해 수행된다. MySQL 호환 클라이언트로 연결하면 다양한 기본 ProxySQL 구성 및 통계 테이블을 쿼리하기 위한 표준 MySQL 스타일 인터페이스가 표시된다.

계층 간에 구성을 이동하기 위해 관리 인터페이스를 통해 사용할 수 있는 다양한 관리 명령 세트가 있다. 각 레이어간 이동 및 명령어은 아래 링크를 참고한다.

l Moving config between layers : https://github.com/sysown/proxysql/blob/master/doc/configuration_system.md

[참고자료]

l Database load balancing for MySQL and MariaDB with ProxySQL : https://severalnines.com/resources/whitepapers/database-load-balancing-for-mysql-and-mariadb-with-proxysql/

l Multi layer configuration system : https://proxysql.com/documentation/configuring-proxysql/

l Configuration system : https://github.com/sysown/proxysql/blob/master/doc/configuration_system.md

2023-07-24 / Sungwook Kang / http://sungwookkang.com

MySQL, ProxySQL, MySQL Replication, MySQL HA, Replication, MySQL복제, 마스터 슬레이브, ProxySQL설치, MySQL복제설치, 쿼리룰설정 ,ProxySQL Internals, ProxySQL Architecture, ProxySQL 아키텍처, ProxySQL 인터널스