10.6에서 11.4로 한 번에 건너뛰어도 되나?

기술적으로 시도할 수는 있지만 MariaDB는 메이저 버전을 한 단계씩 올리는 방식을 권한다. 10.6에서 10.11, 10.11에서 11.4로 나눠 올리면서 각 버전의 변경 사항 문서를 순서대로 반영하면 my.cnf 옵션 제거나 동작 변경을 놓칠 위험이 줄어든다. 공식 문서도 이 구간을 단계별로 안내한다.

mariadb-upgrade는 서버 기동 전에 돌리나 후에 돌리나?

새 버전 바이너리로 서버를 먼저 기동한 다음에 실행한다. mariadb-upgrade는 실행 중인 서버에 접속해 mysql 데이터베이스의 시스템 테이블을 갱신하고 CHECK TABLE FOR UPGRADE를 돌리기 때문이다. 데이터 디렉터리에 쓰기 권한이 있는 계정으로 실행해야 한다.

11.4에서 mysql_native_password가 사라졌나?

아니다. 제거된 쪽은 MySQL이다. MySQL은 8.4에서 기본 비활성, 9.0에서 제거했지만, MariaDB 11.4에서는 mysql_native_password가 그대로 유효하다. old_passwords=0이고 플러그인을 지정하지 않으면 이 방식이 기본으로 쓰인다. 따라서 10.6의 native password 계정은 11.4에서도 그대로 접속된다.

업그레이드 후 특정 쿼리가 느려지면 원인이 뭔가?

옵티마이저가 11.0에서 다시 작성돼 실행 계획이 달라졌을 가능성이 크다. 같은 쿼리가 다른 인덱스나 조인 순서를 타면서 느려질 수 있다. 부하가 큰 쿼리는 업그레이드 전후로 EXPLAIN 결과를 비교하고, 운영 반영 전에 복제 서버에서 실제 쿼리를 흘려 검증하는 것이 좋다.

메이저 업그레이드 후 10.6으로 되돌릴 수 있나?

11.4 서버가 이미 만진 데이터 디렉터리를 10.6 바이너리에 그대로 물릴 수는 없다. 데이터 파일과 시스템 테이블이 새 버전으로 바뀌기 때문이다. 롤백은 사실상 백업 복원이다. 업그레이드 전에 떠 둔 데이터 디렉터리 사본이나 논리 백업으로 복구해야 하므로, 시작 전 백업 확보가 필수다.

MariaDB 10.6에서 11.4 업그레이드

운영 중인 MariaDB 10.6이 슬슬 손이 가는 시점이 왔다. 10.6도 LTS라 아직 지원 기간이 남았지만, 11.4가 새 LTS로 자리를 잡으면서 신규 장비는 11.4로 깔고 기존 장비만 10.6에 남는 상황이 생긴다. 버전이 갈리면 my.cnf 관리도 두 벌이 되고, 나중에 한꺼번에 올리려다 더 크게 고생한다. 그래서 여유 있을 때 미리 11.4로 맞춰두는 편을 택했고, 그 과정을 정리했다.

결론부터 말하자면, 10.6에서 11.4로 가는 핵심은 세 가지다. 패키지를 교체하고 새 서버를 기동한 뒤 mariadb-upgrade로 시스템 테이블을 갱신하는 것, 11.x에서 사라진 my.cnf 옵션을 미리 걷어내는 것, 그리고 실패했을 때 되돌릴 백업과 절차를 손에 쥐고 시작하는 것이다. 메이저 업그레이드는 데이터 파일을 하위 버전으로 되돌릴 수 없으므로, 롤백은 곧 백업 복원이라고 보고 준비해야 한다.

1. mariadb-upgrade가 하는 일

mariadb-upgrade는 메이저 버전을 올린 직후 mysql 데이터베이스의 시스템 테이블을 새 버전 구조로 갱신하고, 사용자 테이블에 대해 CHECK TABLE ... FOR UPGRADE를 돌려 호환성이 깨진 테이블이 있으면 ALTER TABLE ... FORCE로 재작성하는 도구다. 새 바이너리로 서버를 띄운 다음에 실행한다는 순서가 중요하다. 데이터 디렉터리에 쓰기 권한이 있는 계정으로 돌려야 한다.

마이너 버전 업그레이드에서는 실행해도 바꿀 게 없으면 아무 일도 하지 않는다. 반대로 10.6에서 11.4처럼 메이저 경계를 넘을 때는 반드시 실행한다.

2. 업그레이드 전 상태 확인

먼저 지금 버전과 데이터 위치, 실행 계정을 확인한다.

$ mariadb --version
mariadb from 10.6.18-MariaDB, client 15.2 for Linux (x86_64)

$ sudo systemctl status mariadb
● mariadb.service - MariaDB 10.6 database server
     Active: active (running)

MariaDB [(none)]> SELECT @@version, @@datadir;
+-----------------+-----------------+
| @@version       | @@datadir       |
+-----------------+-----------------+
| 10.6.18-MariaDB | /var/lib/mysql/ |
+-----------------+-----------------+

버전 번호는 저장소 상태에 따라 다를 수 있다. 여기서 잡아둔 데이터 디렉터리 경로는 뒤에서 백업과 롤백에 그대로 쓴다.

상태 확인과 백업에서 시작해 롤백 준비까지 이어지는 여섯 단계 절차 그림. — 10.6에서 11.4로 올릴 때 백업 확보부터 롤백 대비까지 밟는 단계를 요약했다.

3. 백업부터 확보한다

메이저 업그레이드는 시스템 테이블을 제자리에서 고치기 때문에, 절반쯤 진행된 상태에서 문제가 생기면 손으로 되돌리기 어렵다. 시작 전에 논리 백업과 물리 백업 중 최소 하나, 가능하면 둘 다 떠 둔다.

# 논리 백업 (복원 유연성이 좋다)
$ mariadb-dump --all-databases --single-transaction \
    --routines --events --triggers > /backup/full_10_6.sql

# 물리 백업 (덩치 큰 DB에서 빠르다)
$ mariadb-backup --backup --target-dir=/backup/mb_10_6 \
    --user=root

물리 파일도 통째로 복사해 두면 마음이 편하다. 서버를 멈춘 상태에서 데이터 디렉터리를 압축해 다른 위치에 둔다. 이 사본이 있으면 최악의 경우 패키지를 10.6으로 되돌리고 데이터를 그대로 얹어 복구할 수 있다.

$ sudo systemctl stop mariadb
$ sudo tar czf /backup/datadir_10_6.tar.gz -C /var/lib mysql

제거, 이름 변경, 기본값 변경으로 나눈 my.cnf 옵션 목록 표. — 11.4로 넘어오며 제거되거나 이름과 기본값이 바뀐 my.cnf 옵션을 모았다.

4. my.cnf 옵션 호환성 점검

11.x로 넘어오면서 사라지거나 이름이 바뀐 옵션이 있다. 이 값들이 my.cnf에 남아 있으면 새 서버가 unknown variable로 기동을 거부한다. 막상 올려보면 여기서 가장 자주 걸린다. 그래서 패키지를 바꾸기 전에 설정부터 손본다.

10.6에서 11.4 사이에 제거된 대표 옵션은 다음과 같다.

innodb_defragment와 관련 옵션 전체(innodb_defragment_fill_factor, innodb_defragment_frequency, innodb_defragment_n_pages 등). InnoDB 조각 모음 방식이 더 이상 지원되지 않는다.
old_alter_table. alter_algorithm으로 대체됐다.
debug_no_thread_alarm. 사용되지 않는 코드라 제거됐다.
optimizer_adjust_secondary_key_costs. 11.4에서는 효과가 없다.

이름이 바뀌어 사용은 되지만 경고를 내는 옵션도 있다. tx_isolation은 transaction_isolation으로, tx_read_only는 transaction_read_only로 바꿔 쓴다. 기본값이 달라진 것도 있는데, innodb_purge_batch_size가 300에서 1000으로 올라갔다. 명시적으로 300을 박아뒀다면 왜 그랬는지 다시 판단한다.

설정 파일 어디에 무엇이 들어 있는지부터 훑는다.

$ grep -rInE 'innodb_defragment|old_alter_table|tx_isolation|tx_read_only|debug_no_thread_alarm|optimizer_adjust_secondary_key_costs' \
    /etc/mysql/ /etc/my.cnf /etc/my.cnf.d/ 2>/dev/null
/etc/mysql/mariadb.conf.d/50-server.cnf:88:innodb_defragment = 1

걸린 줄은 주석 처리하거나 지운다. 확신이 안 서는 옵션은 11.4를 임시로 다른 장비에 올려 SELECT @@해당변수로 존재 여부를 먼저 확인하는 방법이 안전하다.

5. 예약어 충돌은 이 구간에선 걱정이 적다

예약어는 테이블이나 컬럼 이름으로 쓴 단어가 새 버전에서 예약어가 되면 백틱 없이는 쿼리가 깨지는 문제다. 다만 10.6에서 11.4 사이에는 새로 추가된 예약어가 사실상 없다. OFFSET은 이미 10.6에서 예약어가 됐고, VECTOR는 11.7부터라 11.4에는 해당하지 않는다. 그래서 이 업그레이드 구간에서는 예약어 때문에 깨질 가능성이 낮다.

그래도 10.6보다 낮은 버전에서 넘어왔거나 오래된 스키마라면 한 번 점검해 손해 볼 게 없다. 최신 MariaDB에는 예약어 목록을 담은 INFORMATION_SCHEMA.KEYWORDS 테이블이 있어 서버가 인식하는 예약어를 직접 뽑아볼 수 있다.

MariaDB [(none)]> SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS
    -> WHERE RESERVED = 1 ORDER BY WORD;

예약어를 식별자로 써야 한다면 항상 백틱으로 감싼다. 특히 ALTER문에서 빼먹기 쉽다.

-- 이렇게 감싼다
ALTER TABLE t1 ADD `system` VARCHAR(64);

-- 이건 문법 에러
ALTER TABLE t1 ADD system VARCHAR(64);

6. 패키지 교체와 서버 기동

MariaDB는 메이저 버전을 한 단계씩 올리는 방식을 권한다. 10.6에서 11.4로 바로 건너뛰기보다, 10.11을 거쳐 올라가면서 각 버전의 변경 사항 문서를 순서대로 반영하는 편이 사고가 적다. 공식 문서도 10.6에서 10.11, 10.11에서 11.4로 나눠 안내한다. 아래는 11.4 저장소로 교체하는 예다.

# 1) 서버 정지
$ sudo systemctl stop mariadb

# 2) 저장소를 11.4로 교체 (mariadb_repo_setup 사용 예)
$ curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | \
    sudo bash -s -- --mariadb-server-version="mariadb-11.4"

# 3) 패키지 갱신
$ sudo apt update && sudo apt install --only-upgrade mariadb-server

# 4) 새 서버 기동
$ sudo systemctl start mariadb

데이터 디렉터리와 설정은 그대로 두고 바이너리만 새 버전으로 바뀐다. 기동에 실패하면 journalctl -u mariadb -n 50으로 로그를 본다. 대부분 4번에서 걸러내지 못한 옵션 때문이다.

$ mariadb --version
mariadb from 11.4.3-MariaDB, client 15.2 for Linux (x86_64)

7. mariadb-upgrade 실행

새 서버가 뜬 것을 확인했으면 시스템 테이블을 갱신한다. 실행이 필요한지 먼저 물어볼 수도 있다. --check-if-upgrade-is-needed는 업그레이드가 필요하면 0, 필요 없으면 1을 반환한다. 반환값 방향이 직관과 반대라는 점만 기억하면 된다.

$ mariadb-upgrade --check-if-upgrade-is-needed; echo "exit=$?"
exit=0

$ sudo mariadb-upgrade --user=root
Major version change detected, running mysql_upgrade
Phase 1/8: Checking and upgrading mysql database
...
Phase 7/8: Running 'FLUSH PRIVILEGES'
Phase 8/8: Checking and upgrading tables
OK

이미 같은 버전으로 한 번 돌렸는데 다시 강제로 검사하려면 --force를 붙인다. 사용자 테이블은 그대로 두고 mysql DB의 시스템 테이블만 손보려면 --upgrade-system-tables를 쓴다. 여기서 한 번 걸린 적이 있는데, 데이터 디렉터리 소유권이 mysql이 아닌 계정으로 꼬여 있으면 쓰기가 막힌다. sudo로 root 접속하거나 소유권을 mysql:mysql로 맞추면 풀린다.

8. mysql_native_password 인증 확인

MySQL 8.4에서 mysql_native_password가 기본 비활성으로 바뀌고 9.0에서 제거되면서, 이 플러그인이 곧 사라진다고 오해하는 경우가 있다. MariaDB는 다르다. 11.4에서도 mysql_native_password는 그대로 살아 있고, 계정 생성 시 플러그인을 지정하지 않고 old_passwords=0이면 이 방식이 쓰인다. 즉 10.6에서 11.4로 올려도 기존 native password 계정은 그대로 접속된다.

업그레이드 후 각 계정이 어떤 플러그인을 쓰는지 확인해 둔다.

MariaDB [(none)]> SELECT user, host, plugin FROM mysql.user;
+-------------+-----------+-----------------------+
| user        | host      | plugin                |
+-------------+-----------+-----------------------+
| mariadb.sys | localhost | mysql_native_password |
| root        | localhost | unix_socket           |
| appuser     | %         | mysql_native_password |
+-------------+-----------+-----------------------+

root가 unix_socket인 것은 최근 MariaDB 기본값이다. OS의 root 계정으로 로컬 접속할 때만 통과되므로, 원격 관리 도구가 root 비밀번호로 붙던 환경이라면 이 부분을 먼저 챙긴다. 보안을 더 조이려면 애플리케이션 계정을 ed25519로 옮기는 것을 권한다. MariaDB는 native password를 새 설치의 고보안 용도로는 권하지 않는다.

-- 애플리케이션 계정을 ed25519로 전환하는 예
ALTER USER 'appuser'@'%' IDENTIFIED VIA ed25519 USING PASSWORD('새비밀번호');

단, 드라이버와 커넥터가 ed25519를 지원해야 한다. 클라이언트 호환이 걸리면 native password를 유지하는 편이 현실적이다.

9. 쿼리 플랜 변화에 주의

옵티마이저가 11.0에서 크게 다시 쓰였다. 그래서 10.6에서 잘 돌던 쿼리가 11.4에서 다른 실행 계획을 타면서 느려지거나 빨라질 수 있다. 업그레이드 자체가 실패하는 문제는 아니지만, 운영 부하가 걸린 뒤에 드러나면 곤란하다. 부하가 큰 주요 쿼리는 미리 EXPLAIN으로 계획을 비교해 두면 좋다.

MariaDB [app]> EXPLAIN SELECT ...;

이 점 때문에도 운영 반영 전에 복제 서버 한 대를 먼저 11.4로 올려 실제 쿼리를 흘려보고 검증하는 방식을 권한다.

10. 롤백 계획

메이저 업그레이드는 데이터 파일 포맷과 시스템 테이블이 새 버전으로 바뀐다. 11.4 서버가 만진 데이터 디렉터리를 그대로 10.6 바이너리에 물릴 수는 없다. 그래서 롤백은 사실상 백업 복원이다. 계획은 이렇게 세운다.

3번에서 떠 둔 데이터 디렉터리 사본 또는 논리 백업을 복원 지점으로 삼는다.
롤백 시 서버를 멈추고 패키지를 10.6으로 되돌린 뒤, 새 서버가 건드리지 않은 데이터 사본을 데이터 디렉터리에 되돌린다.
가능하면 복제 서버를 먼저 올려 검증하고, 원본은 마지막에 승격하는 순서로 진행한다. 이러면 문제가 생겨도 원본 10.6이 살아 있어 되돌릴 필요조차 없다.

# 물리 사본으로 되돌리는 예
$ sudo systemctl stop mariadb
$ sudo mv /var/lib/mysql /var/lib/mysql.broken
$ sudo tar xzf /backup/datadir_10_6.tar.gz -C /var/lib
# 이후 10.6 패키지로 다운그레이드하고 기동

업그레이드가 성공한 뒤에도 백업 사본은 며칠 남겨둔다. 옵티마이저 변화로 인한 지연 문제는 시간이 지나 부하가 실려야 드러나기도 한다.

11. 마무리 확인

업그레이드가 끝났으면 버전, 프로세스, 접속, 주요 테이블 상태를 한 번에 훑는다.

$ mariadb -e "SELECT @@version;"
$ systemctl is-active mariadb
$ mariadb -e "SHOW GLOBAL STATUS LIKE 'Uptime';"
$ mariadb -e "CHECK TABLE app.orders;"

정리하면, 10.6에서 11.4 업그레이드는 백업 확보, my.cnf에서 제거된 옵션 정리, 패키지 교체 후 mariadb-upgrade 실행, 인증 플러그인과 쿼리 플랜 확인, 그리고 백업 복원 기반 롤백 계획으로 이어진다. 복제 서버에서 먼저 검증하는 순서를 지키면 운영 위험을 크게 줄일 수 있다.