Kubernetes / コンテナ環境で MariaDB の /var/lib/mysql を永続化する

Kubernetes や Docker で MariaDB / MySQL をコンテナ化する場合、/var/lib/mysql をどのように永続化するかが重要になります。コンテナ自体は起動できても、データディレクトリを外部ボリュームにした瞬間に初期化で止まることがあります。

問題になったこと

MariaDB コンテナを自作していた時、単体では正常に起動するのに、/var/lib/mysql を外部ボリュームへ出すと初期データの書き込みが途中で止まり、Pod が起動しなくなりました。

原因はパーミッション

原因は複雑な Kubernetes 固有の問題ではなく、ボリューム上の所有者と権限でした。データベースコンテナは、起動時に /var/lib/mysql へ初期データを書き込みます。この時、コンテナ内の実行ユーザーがボリュームへ書けないと初期化に失敗します。

確認すること

• コンテナ内で MariaDB / MySQL がどの UID / GID で動くのか確認する。
• PersistentVolume / hostPath / NFS など、実際の保存先の所有者と権限を確認する。
• 初回起動時に作成されるファイルが途中で止まっていないか確認する。
• root で書けるかではなく、DB プロセスの実行ユーザーで書けるかを見る。

確認コマンド

kubectl describe pod <mariadb-pod>
kubectl logs <mariadb-pod>
kubectl exec -it <mariadb-pod> -- id
kubectl exec -it <mariadb-pod> -- ls -ld /var/lib/mysql

まとめ

Kubernetes の永続化トラブルは、StorageClass や PV / PVC の問題に見えて、実際には単純なパーミッションであることがあります。特に MariaDB / MySQL の /var/lib/mysql は初期化時に書き込みが発生するため、ボリュームの所有者、権限、実行ユーザーを最初に確認するのが近道です。

関連記事

Kubernetes 上に Harbor を構築する – Helm で内部コンテナレジストリを運用する意味 Kubernetes に Docker / Podman のような stop/start がない理由 Kubernetes クラスタの初期化 – kubeadm reset の基本 Kubernetes disk-pressure で Pod が起動しない場合 Kubernetes コントロールプレーンノードを追加できない場合 – kubeadm-certs を再生成する Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか