リストアする機会はバックアップを取る機会よりも少ない。こまめにとられたバックアップをいざリストアしようとしてエラーが出てハマって焦るというのはデータベースあるあるの筆頭と言ってよい。リストアできないバックアップほど人の心をむしばむものは無い。リストアできれば助かるのに、そこにデータがあるのに、手が届かない。そんな悲しい思いをしなくて済むように、リストアのエラー解決TIPSは広く共有されるべきだ。今回はPostgreSQLのバックアップリストアでハマって1日つぶしてしまって泣きそうになったのでちょっと備忘録として残しておきたいと思う。書いておかないと半年後にまた同じ問題で半日つぶすことになってしまうだろう。ブログに備忘録を書くのはとても役に立つのだ。皆様にもお勧めしたい。PostgreSQLのバックアップPostgreSQLのバックアップはpg_dumpコマンドで取得するが、オプションによって大きく二つに分かれる。平文のSQLで取得してpsqlコマンドでリストアする方法と、アーカイブ形式で取得してpg_restoreコマンドでリストアする方法だ。アーカイブ形式でのバックアップリストアは、いろいろ高機能だがリソースをたくさん食い要求されるサーバースペックも高くなるので、今回はSQLで取得するスクリプト方式で取得し、psqlコマンドでリストアする方法をとっていた。具体的にはこんなコマンドだ。fabulousDB"ローカルのソケットからの接続はピア認証になるようにpg_hba.confで設定しているので、ユーザーpostgresになってpg_dumpコマンドを発行している。リストア時にデータベース”fabulousDB”をDROPし、”CREATE”しなおしてからデータを流し込むSQLを吐き出すようにしている。指定した通り平文のSQLでバックアップを取得する。リストアの失敗しかしこれをリストアしようとすると失敗する。リストア時に発行したコマンドは以下の通りだ。$backup_file先ほどと同じく、ユーザー”postgres”でpsqlコマンドを発行している。単純に、データーベース”fabulousDB”に対して、バックアップSQLをリダイレクトで流し込んでいる。リストアされる環境には、バックアップを取得した環境と同じ名前のDBが存在しなければならない。普通ならこれですんなりリストアされるはずだが、今回は本番環境のfabulousDBを、検証環境でリストアしようとして失敗し、以下の例に挙げるようなエラーに遭遇した。ON_ERROR_STOP=1′′を指定しておくと一つ目のエラーで止まってくれるので、エラーの羅列を眺めなくても済む。なんだか無効なコマンドが発行されてるっぽいので、文字コードの問題かと思ったが、クライアントもDBもちゃんとUTF8で統一されている。出力されたバックアップのSQLを覗いてみると、どうやらCOPYコマンドのところで失敗している。\Nというのは、カラムに空白を入れるときの指定だ。これがどうやら単独のコマンドとして認識されてしまいそんなコマンドはないよと言われているようだ。検索エンジンに思いついた単語や出たエラーをぶち込むと、同じお悩みの人がたくさんいて、そのことごとくに”COPY”コマンドじゃなくて”INSERT”コマンドを使うようにpg_dumpのオプションに”–inserts”を使え!という解決策ばかり出てきた。それはしたいことと違う。COPYコマンドが使えないのかというのが問題なのだ。INSERTできたとしても、COPY出来ないなら検証環境と本番環境に差異が出てしまう。そんな中、一筋の光明が見えた、以下のリンクのスレッドだ。dump上記のスレッドでは”uuid-ossp”が足りないので”postgresql-contrib”をインストールして追加すれば治るとのことだった。私の環境では”uuid-ossp”は使ってないので、本番環境と検証環境でEXTENSIONの差異を見比べてみる。psqlコマンドでpostgresqlのコマンドラインに入って”\dx”でEXTENSIOnの一覧を確認する。