kubernetes上のDBMS バックアップ&リストア

PostgreSQLやMySQLなどのデータベースのバックアップ&リストアにはいくつか方法がありますが、SQL形式の論理バックアップを取得する方法が一般的です。

とくに、DBMSを別のサーバーに構築したいケースでは、バックアップファイルを現行のサーバーからダウンロードする必要があります。

kubernetes環境に構築したデータベースでは、単純にpodコンテナ内でバックアップファイルを取得してもファイルを外部に取り出すことができません。

このような場合、kubectlのport-forward機能を利用することで、一般的なバックアップ手順と同様にリモートクライアントからバックアップ&リストアを行えます。

kubectl port-forwardは、podのポートをクライアント機のローカルホストポートに転送する機能を提供します。

ポート転送をセットアップできたら、mysqldumpやpg_dumpコマンドでローカルホストに接続するだけでサーバーのDBMSに接続できます。

前提条件

  • kubernetes上で動作中のMySQLサーバー・PostgreSQLサーバーがある
  • バックアップファイルを取得するクライアント機で、kubernetesを操作できるkubectlコマンドが動作している
  • クライアントにmysqlコマンド・psqlコマンドのツール群がセットアップしてある

kubectl port-forwardの使い方

kubectl port-forwardコマンドは以下のような書式になっています。

kubectl port-forward pod名 クライアントのポート番号:podのポート番号

pod名はkubectl get podsコマンドで確認できます。また、ポート番号はPodまたはReplication Controllerの起動用設定ファイルで指定した番号です。

たとえば、デフォルト設定のMySQL・PostgreSQLの場合のコマンド例は以下のような形式になります。

kubectl port-forward mysql-pd-1de3 3306:3306

kubectl port-forward postgres-pd-3gw4 5432:5432

このコマンドを実行すると、接続状態でプロンプトが占有された状態になるため、別のターミナルからバックアップ・リストア操作を行います。

作業が完了したら、kubectl port-forward実行中のプロンプト上でCtrl-cを入力することでポート転送を切断して終了できます。

MySQL、PostgreSQLのバックアップ

バックアップ・リストアの手順は通常のMySQL、PostgreSQLの操作と同じです。接続先としてローカルホストを指定することがポイントです。

pg_dump -U DBユーザー名 -h localhost DB名 > バックアップファイル名

mysqldump -u DBユーザー名 -p -h 127.0.0.1 DB名 > バックアップファイル名

MySQLは接続ホストに”localhost”を指定するとポート接続ではなくUnixソケットを使おうとするため、IPアドレスで指定します。

また、同様にpsqlコマンド・mysqlコマンドを用いてリストアも実行可能なほか、DDLなどのSQLによる一般的なDB管理操作も行えます。

port-forwardが動作しない場合の代替インポート

データベースのリストアについては、何らかの理由でport-forwardを動作させられない場合の代替手段としてバックアップファイルをコンテナイメージに同梱する、という手もあります。

詳細は、 kubernetesへのDBファイル・インポート手順を参照してください。

port-forwardが不安定な場合の代替バックアップ

port-forward経由のバックアップが完了しない事象に遭遇することがあります。

この場合、コンテナにシェルログインして、ホストのファイルシステムにpg_dump / mysqldumpしたうえで、ホスト側でバックアップファイルを受け渡す、という手段が残っています。(コンテナへのシェルログインの詳細については、 docker execを使いこなすを参照してください)。

コンテナ→ホストのファイル取り出しには、Volumeマウントしたディレクトリにダンプファイルを置く必要があるため、あらかじめVolumeを設定しておくことが重要です。

port-forwardではネットワーク・パイプ上にダンプデータが流れるため、クライアントとの接続状態が不安定な場合、バックアップコマンドが途中でハングアップするケースがあります。

コンテナ上のバックアップ操作では、コンテナ動作さえ健全であればホストへのファイル出力までは比較的安定しています。

Google Kubernetes Engineを利用していてDBサーバーがどのVMインスタンスで動作しているかを知りたい場合、DBデータを置いているpersistentDiskをWebコンソールで確認することでインスタンスを特定できます。

リストア後のパスワード変更

データベースのdockerイメージには特権ユーザーのパスワードを環境変数で指定するものが多くあります。

初期セットアップでは環境変数経由のパスワードがセットされるのですが、既存のデータベースからpg_dumpallコマンドなどでバックアップ・リストアした場合、バックアップ時のパスワードがデータベースに指定されているケースがあります。

このようなケースでパスワード変更するには、SQLコマンドのALTER USERなどDB操作が必要なため注意が必要です。

⁋ 2016/02/20↻ 2024/12/18
中馬崇尋
Chuma Takahiro