弊社のデータベースサーバー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/9046やhttps://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
コメント