PostgreSQLデータベースを復元するときに権限の問題を解決する方法

次のコマンドを使用して、Postgresデータベースのクリーンな所有者バックアップをダンプしました

pg_dump sample_database -O -c -U

後で、データベースを復元すると

psql -d sample_database -U app_name

ただし、データを復元できないいくつかのエラーが発生しました。

ERROR:  must be owner of extension plpgsql
ERROR:  must be owner of schema public
ERROR:  schema "public" already exists
ERROR:  must be owner of schema public
CREATE EXTENSION
ERROR:  must be owner of extension plpgsql

プレーンテキストのSQL pg_dump生成を詳しく調べたところ、SQL が含まれていることがわかりました

CREATE SCHEMA public;
COMMENT ON SCHEMA public IS 'standard public schema';
CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';

原因は、ユーザーapp_nameがpublicスキーマとを変更する権限を持っていないことplpgsqlです。

この問題を解決するにはどうすればよいですか？

この問題を解決するには、適切な所有権を割り当てる必要があります。特定のユーザーのすべての権限関連の問題を解決する必要がありますが、コメントに記載されているように、これは本番環境では使用しないでください。

root@server:/var/log/postgresql# sudo -u postgres psql
psql (8.4.4)
Type "help" for help.

postgres=# \du
               List of roles
    Role name    | Attributes  | Member of
-----------------+-------------+-----------
 <user-name>    | Superuser   | {}
                 : Create DB
 postgres       | Superuser   | {}
                 : Create role
                 : Create DB

postgres=# alter role <user-name> superuser;
ALTER ROLE
postgres=#

したがって、スーパーユーザーアカウントでデータベースに接続し、ステートメントsudo -u postgres psqlを実行しALTER ROLE <user-name> Superuser;ます。

覚えておいて、これはマルチサイトのホスティングサーバー上の最善の解決策ではありませんので、代わりに個々の役割を割り当てることを見てみましょう：https://www.postgresql.org/docs/current/static/sql-set-role.htmlとHTTPS ：//www.postgresql.org/docs/current/static/sql-alterrole.html。

AWS RDSユーザーこれを取得しているのは、スーパーユーザーではなく、awsのドキュメントによると、スーパーユーザーになれないためです。これらのエラーを無視する必要があることがわかりました。

Google Cloud Platformを使用しているユーザーの場合、エラーが発生するとインポートプロセスが停止します。個人的に、発行したpg_dumpコマンドに応じて2つの異なるエラーが発生しました。

1- The input is a PostgreSQL custom-format dump. Use the pg_restore command-line client to restore this dump to a database.

DBをプレーンテキスト以外の形式でダンプしようとしたときに発生します。つまり、コマンドに-Fpまたは--format = plainパラメーターがない場合。ただし、コマンドに追加すると、次のエラーが発生する可能性があります。

2- SET SET SET SET SET SET CREATE EXTENSION ERROR: must be owner of extension plpgsql

これは、GCPドキュメントで提供されているコマンド、この現在のスレッドからのヒント、またはこちらの Google Postgresチームからのアドバイスに従って解決できなかった権限の問題です。次のコマンドを発行することをお勧めします：

pg_dump -Fp --no-acl --no-owner -U myusername myDBName > mydump.sql

私の場合、トリックを実行した唯一のことは、ダンプファイルを手動で編集し、plpgsqlに関連するすべてのコマンドをコメント化することでした。

これがGCPに依存する魂に役立つことを願っています。

更新：

特にいくつかのダンプは巨大になる可能性があるため、拡張子をコメントアウトしたファイルをダンプする方が簡単です。 pg_dump ... | grep -v -E '(CREATE\ EXTENSION|COMMENT\ ON)' > mydump.sql

plpgsqlに絞り込むことができます。 pg_dump ... | grep -v -E '(CREATE\ EXTENSION\ IF\ NOT\ EXISTS\ plpgsql|COMMENT\ ON\ EXTENSION\ plpgsql)' > mydump.sql

この場合、エラーメッセージは無視しても安全です。パブリックスキーマにコメントを追加しなかったり、plpgsql（既にインストールされているはずです）をインストールしても、実際には問題は発生しません。

ただし、完全に再インストールする場合は、適切な権限を持つユーザーが必要です。もちろん、これはアプリケーションが日常的に実行しているユーザーであってはなりません。

より短い答え：それを無視してください。

このモジュールは、SQL言語を処理するPostgresの一部です。エラーは、「heroku pg：pull」などのリモートデータベースのコピーの一部としてポップアップすることがよくあります。SQLプロセッサを上書きせず、警告を出します。

-L取得したファイルを指定して、pg_restoreでフラグを使用してみてくださいpg_dump -Fc

-Lリストファイル--use-list = list-file

list-fileにリストされているアーカイブ要素のみを復元し、ファイルに表示されている順に復元します。-nや-tなどのフィルタースイッチを-Lと共に使用すると、復元されるアイテムがさらに制限されます。

list-fileは通常、前の-l操作の出力を編集することによって作成されます。行は移動または削除できます。また、行の先頭にセミコロン（;）を配置してコメント化することもできます。例については、以下を参照してください。

https://www.postgresql.org/docs/9.5/app-pgrestore.html

pg_dump -Fc -f pg.dump db_name
pg_restore -l pg.dump | grep -v 'COMMENT - EXTENSION' > pg_restore.list
pg_restore -L pg_restore.list pg.dump

ここでは、コメントのみを出力することにより、逆が正しいことがわかります。

pg_dump -Fc -f pg.dump db_name
pg_restore -l pg.dump | grep 'COMMENT - EXTENSION' > pg_restore_inverse.list
pg_restore -L pg_restore_inverse.list pg.dump
--
-- PostgreSQL database dump
--

-- Dumped from database version 9.4.15
-- Dumped by pg_dump version 9.5.14

SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET client_min_messages = warning;
SET row_security = off;

--
-- Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner: 
--

COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';


--
-- PostgreSQL database dump complete
--

AWSを使用している人にとって、これCOMMENT ON EXTENSIONはスーパーユーザーとしてのみ可能であり、ドキュメントでわかっているように、RDSインスタンスはAmazonによって管理されます。そのため、レプリケーションなどを壊さないようにするために、ユーザー（インスタンスの作成時に設定したrootユーザーであっても）には完全なスーパーユーザー権限がありません。

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html

DBインスタンスを作成すると、作成したマスターユーザーシステムアカウントがrds_superuserロールに割り当てられます。rds_superuserロールは、事前定義されたAmazon RDSロールであり、PostgreSQLスーパーユーザーロール（ローカルインスタンスでは通常、postgresという名前）に似ていますが、いくつかの制限があります。PostgreSQLスーパーユーザーロールと同様に、rds_superuserロールはDBインスタンスに対して最も多くの権限を持っているため、ユーザーがDBインスタンスに最も多くのアクセス権を必要としない限り、このロールをユーザーに割り当てないでください。

このエラーを修正するには、を使用--して、次を含むSQLの行をコメント化しますCOMMENT ON EXTENSION

復元を行う前に、postgres（admin）ユーザーを使用してスキーマをダンプし、再作成して、使用する権限を付与します。1つのコマンドで：

sudo -u postgres psql -c "DROP SCHEMA public CASCADE;
create SCHEMA public;
grant usage on schema public to public;
grant create on schema public to public;" myDBName

私にとっては、pgAdminを使用してデータベースを設定していましたが、データベースの作成中に所有者を設定するだけでは不十分でした。私は「パブリック」スキーマにナビゲートし、所有者もそこに設定する必要がありました（元々は「postgres」でした）。

問題をCOMMENT ONステートメントに絞り込み（以下のさまざまな回答に従って）、ダンプファイルの作成元であるソースデータベースへのスーパーユーザーアクセス権を持つユーザーの場合、最も簡単な解決策は、コメントがダンプに含まれないようにすることです。ダンプされているソースデータベースからそれらを削除することにより、最初のファイル...

COMMENT ON EXTENSION postgis IS NULL;
COMMENT ON EXTENSION plpgsql IS NULL;
COMMENT ON SCHEMA public IS NULL;

その場合、将来のダンプにはCOMMENT ONステートメントが含まれません。