MariaDB10.1→10.4アップグレード

弊社のデータベースサーバーMariaDBはCoreOS Container Linuxサーバー上のDockerコンテナで稼働しています。
また、DockerコンテナのOSは軽量版LinuxのAlpine Linuxを使用しています。

データベースのデータは永続化ボリュームとして別途データ用サーバーの領域をNFSでマウントしてDockerコンテナに渡しています。

MariaDB 10.2ではNFS上のボリュームをデータベース領域として使用すると

[ERROR] InnoDB: Could not set the file size of './ibtmp1'. Probably out of disk space

のエラーが発生して起動に失敗します。

https://gitlab.alpinelinux.org/alpine/aports/issues/9046https://jira.mariadb.org/browse/MDEV-16015によると解決策はMriaDB 10.1にダウングレードするしかないとありましたので、今まではAlpine Linux 3.8とMriaDB 10.1.41の組み合わせで使用していました。

2020年1月にFedora CoreOSが一般提供され、CoreOS Container Linuxは2020年5月でサポートが終了するとアナウンスがあり、弊社でもFedora CoreOSへの切り替えを進めているところです。

現在のAlpine Linuxは3.12に、MriaDBは10.4.13になっていて、さすがにこれはマズいなということで最新版へのアップグレードを行うことにしましたが、Alpine Linux 3.12になってもNFS上のボリュームをデータベース領域として使用するとエラーになります。

今後もエラーが解消する見込みもなさそうですので、MariaDB自体をデータ用サーバーで稼働させ、NFS上のボリュームをデータベース領域としないようにして対応することにしました。

これで、データベース本体のアップグレードはできたのですが、MariaDB 10.1からフルバックアップしてMariaDB 10.4にリストアしようとすると

ERROR 1050 (42S01) at line xxx: Table 'user' already exists

のエラーになります。

バックアップされたSQLを確認しても

DROP TABLE IF EXISTS user;

がきちんと入っています。

インターネットで『MariaDB 10.4 mysql.user』をキーワードで検索してみるとユーザ認証を管理するテーブルがmysql.userからmysql.global_privに変更になり、mysql.userはViewで残っているとのことです。
Viewなので当然DROP TABLEは効果がなく、already existsになります。

MariaDB 10.1データベースのフルバックアップからMariaDB 10.4ヘのリストアは無理そうなので、下記サイトを参考にしてユーザーデータベースのみをバックアップして、データベースユーザーが別途GRANTで登録するSQLを作成し、無事MariaDBのアップグレードが完了しました。

とはいえ、考えてみればアップグレードに関わらず、それが正しいバックアップ&リストアであるように思えます。

参考サイト:
https://dba.stackexchange.com/questions/69598/how-can-i-mysqldump-all-databases-except-the-mysql-schema/69667#69667
https://serverfault.com/questions/8860/how-can-i-export-the-privileges-from-mysql-and-then-import-to-a-new-server/399875#399875

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)