워드프레스 마리아DB 업그레이드

Docker Compose로 운영 중인 워드프레스의 DB를 MariaDB 10.6.4에서 12.3 LTS로 올렸다. 태그만 바꾸면 끝날 줄 알았는데 생각보다 챙길 게 몇 가지 있어서 정리해 둔다.

환경

호스트: Fedora Server + Docker
공식 wordpress 이미지 + 공식 mariadb 이미지 (docker compose)
DB 데이터는 Docker named volume에 저장
워드프레스 7.1.4, MariaDB 10.6.4

왜 올려야 했나

워드프레스는 7.1.4가 현재 최신 안정 버전이라 손댈 게 없었다. 문제는 DB 쪽이었다. MariaDB 10.6 LTS는 2026년 7월 6일에 커뮤니티 지원이 끝났고, 8월에 나온 10.6.28이 마지막 릴리스다. 나는 그보다 한참 전인 10.6.4를 쓰고 있었다.

어떤 버전으로 갈까: 13.0 vs 12.3

최신은 13.0인데, 이건 LTS가 아니라 rolling 릴리스다. “stable”은 성숙도를 말하는 거고, rolling은 다음 버전이 나오면 지원이 끝난다는 뜻이다.

버전	종류	커뮤니티 지원 종료
13.0	Rolling	2026-12-31
12.3	LTS	2029-06-12
11.4	LTS	2029-05-29
11.8	LTS	2028-06-04
10.11	LTS	2028-02-16

워드프레스는 최신 DB 기능을 쓸 일이 거의 없으니 몇 달마다 메이저 버전을 따라갈 이유가 없다. 그래서 12.3 LTS로 정했다.

주의할 점이 하나 있다. 지금 mariadb:latest는 13.0을 가리킨다. compose에 latest를 써 두면 다음 pull에서 rolling 버전으로 넘어가 버리니까 12.3처럼 버전을 고정하는 게 좋다.

-ubi, -ubi10 태그는 뭐지?

태그 목록을 보면 12.3.3-ubi와 12.3.3-ubi10이 있다. UBI는 Red Hat Universal Base Image 기반 이미지다. -ubi는 그 시리즈의 기본 UBI 버전을 가리키는 별칭이라, 12.x에서는 -ubi10과 같은 이미지다(digest가 같다). 접미사가 없는 기본 태그는 Ubuntu 기반이다. 특별한 이유가 없으면 그냥 mariadb:12.3을 쓰면 된다. 호스트가 Fedora라고 컨테이너까지 UBI로 맞출 필요는 없다.

1. 백업

먼저 SQL 덤프를 뜬다.

docker compose exec db mariadb-dump -uroot -p --all-databases --routines --events > backup.sql

named volume이라 디렉터리를 바로 복사할 수가 없다. 그래서 임시 컨테이너로 볼륨을 통째로 tar로 묶어 둔다. Fedora에서는 SELinux 때문에 마운트에 :z를 붙여야 Permission denied가 안 난다.

docker volume ls          # 볼륨 이름 확인 (보통 프로젝트명_볼륨명)
docker compose stop

docker run --rm -v VOL:/data:ro -v "$PWD":/backup:z alpine \
  tar czf /backup/db_data.tar.gz -C /data .

10.6 초기 버전에서 올라오면 InnoDB change buffer 손상 문제가 생길 수 있다. 이 경우는 in-place 업그레이드로 해결이 안 되고 덤프를 다시 넣는 수밖에 없어서, 덤프는 꼭 떠 두는 게 좋다.

2. compose 수정

db:
  image: mariadb:12.3
  environment:
    MARIADB_AUTO_UPGRADE: "1"
    # 기존 MYSQL_* 환경변수는 그대로 동작
  healthcheck:
    test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]

MARIADB_AUTO_UPGRADE: 컨테이너가 뜰 때 mariadb-upgrade를 자동으로 실행한다.
11.x부터는 이미지에서 mysql, mysqladmin 같은 옛 이름의 바이너리가 빠졌다. healthcheck에서 mysqladmin ping을 쓰고 있었다면 healthcheck.sh로 바꿔야 한다.

docker compose up -d
docker compose logs -f db

3. 트러블슈팅: mysql.column_stats 에러

DB는 정상으로 올라왔고 워드프레스 관리자 화면에도 DB 버전이 12.3.3으로 잘 나왔다. 그런데 로그에 이런 에러가 계속 쌓였다.

[ERROR] Incorrect definition of table mysql.column_stats: expected column 'hist_type' at position 9 to have type enum('SINGLE_PREC_HB','DOUBLE_PREC_HB','JSON_HB'), found type enum('SINGLE_PREC_HB','DOUBLE_PREC_HB').
[ERROR] Incorrect definition of table mysql.column_stats: expected column 'histogram' at position 10 to have type longblob, found type varbinary(255).

시스템 테이블(mysql.*)이 아직 10.6 구조 그대로라서 나는 에러다. 데이터가 손상된 건 아니라서 서비스는 문제없이 돌아간다. 원인은 mariadb-upgrade가 제대로 돌지 않은 것이다.

수동으로 돌리면 해결된다. 이미 업그레이드된 걸로 판단하고 건너뛰는 경우가 있으니 --force를 붙였다.

docker compose exec db mariadb-upgrade -uroot -p --force
docker compose restart db

삽질 포인트가 두 개 있었다.

환경변수는 restart로 반영되지 않는다. MARIADB_AUTO_UPGRADE를 나중에 추가했다면 docker compose up -d로 컨테이너를 다시 만들어야 적용된다. docker compose exec db env | grep AUTO_UPGRADE로 들어갔는지 확인할 수 있다.
restart는 이전 로그를 지우지 않는다. 고친 뒤에도 에러가 계속 보이길래 안 고쳐진 줄 알았는데, 예전 로그였다. 새로 나는 것만 보려면 --since를 쓴다.

docker compose logs --since 2m db | grep -i column_stats

롤백 방법 (안 쓰긴 했지만)

change buffer 에러 같은 게 나서 새로 초기화해야 한다면, 볼륨을 비우고 12.3으로 띄운 다음 덤프를 넣으면 된다. docker compose down -v는 워드프레스 볼륨까지 같이 지우니까 쓰면 안 된다.

docker compose down
docker volume rm VOL
docker compose up -d db
docker compose exec -T db mariadb -uroot -p < backup.sql
docker compose up -d

10.6.4로 되돌릴 때는 볼륨을 다시 만들고 tar를 풀어 넣은 다음 이미지 태그를 원래대로 돌리면 된다.

docker volume rm VOL && docker volume create VOL
docker run --rm -v VOL:/data -v "$PWD":/backup:z alpine \
  tar xzf /backup/db_data.tar.gz -C /data

마무리

결과적으로 태그 변경 + mariadb-upgrade로 끝났다. 이제 2029년까지는 12.3.x 패치 버전만 따라가면 된다. 백업 파일(backup.sql, db_data.tar.gz)에는 사용자 정보도 들어 있으니까, 며칠 지켜본 뒤 지우거나 웹에서 접근할 수 없는 곳에 보관하자.

Claude가 작성함