Tihiroの頭を休めるIT教室

少しだけ頭使って後は根性

cronで実行するスクリプト内で環境変数を参照できない。

ググるとシバン行を追加したり(-lをつけて)、とか色々方法があるみたいですがうまく動作しませんでした。

ので、結論的には

source ~/.bash_profile

シェルスクリプトの先頭行に書き込むことで、(正しいかどうかは別物ですが)無事にcronから実行するシェルスクリプト内で環境変数を参照できるようになりました。

スプリットブレインの解消方法

概要

君もなったことがあるだろう? そう、スプリットブレインにね!

環境

DRBD 9.0 Pacemaker 1.1

cat /proc/drbd
pacemakerd --version

でDRBDとPacemakerのバージョンを確認。

解消する

まずはリソースの確認

ls /etc/drbd.d/*.res

-> xxx.resのxxxがリソース名。

そしてクラスタ状態の確認

pcs status

-> 正しくクラスタの状態(マスタとスレーブのサーバー)が想定通りになっているのか確認。

同期状態の確認(各サーバーで実施)

drbdadm cstate all
drbdadm role all

-> マスタにしたいのが正しくマスタになっているかどうかを確認する。なっていないのなら

pcs cluster standby node_name

とかでマスタとスレーブの状態を想定通りにする。

failcountの確認とクリア

pcs resource failcount show resource_name
pcs resource cleanup resource_name

クリアしておかないと正しくリソース(?)が起動しない。

スプリッドブレインからの復帰

セカンダリ側から念のため作業

セカンダリとなる側(つまり、変更点があっても破棄される側)では、以下のコマンドを実行するらしい。

drbdadm secondary resource_name

drbdadm -- --discard-my-data connect resource_name

誤ってプライマリ側でやっちゃうと目も当てられない。ホントにそのサーバーがセカンダリかどうか確認してからやってください。

プライマリー側も作業

drbdadm connect resource_name

まとめ

クラスタ環境超怖い。

PostgreSQLでの権限エラーへの対応

概要

タイトルの通り、権限エラーが発生したときのお話です。

環境

内容

user_nameっていうユーザで、新しく作成したデータベースにログインして

SELECT * FROM table_name;

ってすると

ERROR:  リレーション"table_name"は存在しません 行 1: SELECT * FROM table_name;

ってなった。

SELECT * FROM public.table_name;

ってしたら

ERROR:  スキーマpublicへのアクセスが拒否されました 行 1: SELECT * FROM public.table_name;

となった。

だから

GRANT ALL ON SCHEMA public TO user_name;

ってしたら、うまくいった。

まとめ

というお話だったのさ。

PostgreSQLでスキーマに対する全ての権限をユーザーに設定するときの注意点

概要

いわゆる、GRANTさんの話。スキーマに対する権限を付与するときの注意点です。

環境

内容

スキーマに対する全ての権限を付与しようと思って

GRANT ALL ON SCHEMA schema_name TO role_name;

としても、スキーマ内のテーブルへの権限はつかない。ので注意が必要です。

具体的に言うと、GRANTしたあとにスキーマ内のテーブルをSELECTしようとして

SELECT * FROM schema_name.table_name

ってしたら、

permission denied for relation table_name;

が発生する。悔しい。

これを回避するには

スキーマ内の全テーブルに対する権限を付与してやる必要がある。つまりは

GRANT ALL ON ALL TABLES IN SCHEMA schema_name TO role_name;

っていうこと。

んでも、これの後に追加されたテーブルに対しては権限がつかない。悔しい。

じゃあどうすればいいの?

ってなる。個人的には

GRANT schema_owner_role TO role_name;

ってな感じで、スキーマの所有者のロールを継承させることで解決している。

まとめ

権限って目に見えないから苦手。

pg_dumpとEXTENSION

概要

pg_dumpに-nをつけてスキーマ単位でのダンプを取得した際に、拡張機能がダンプに含まれないことについての脳内放出。

環境

PostgreSQL 10.5ぐらい

実際にやってみる

対象

項目
データベース名 test
スキーマ public

やってみた

CREATE EXTENSION tablefunc;
SELECT * FROM pg_extension; # tablefuncが作成されたことを確認。

して

pg_dump -U postgres -d test -n public > c:/temp/public.dmp

してみたあと

DROP DATABASE test;
CREATE DATABASE test;

でtestデータベースを再作成して

psql -U postgres -d test -f c:/temp/public.dmp

でリストアすると

SELECT * FROM pg_extension; # tablefuncが復元されないことを確認。

となります。

このあたりの挙動はおそらく

51.22. pg_extension

の「extnamespaceは、拡張がそのスキーマに属することを意図したものではありません」というとことか

37.15. 関連するオブジェクトを拡張としてパッケージ化

スキーマに関して説明されている部分が、そういうわけになるのかなぁ、とぼんやり。

じゃあどうすればいいの?

データベース単位でダンプするしかないようです。

まとめ

ダンプをリストアした後の検証ってほんと大事。リストアしたけどリストアされていませんでした、って後からわかってもどうしようもないですから。

pg_restoreのオプションで-dとか-cとか-Cとかが難しい。

概要

pg_restoreのオプションの挙動に理解が追いつかないので、脳内アウトプット。ので、内容が不正確な可能性が大いにあります。

環境

PostgreSQL 10.5ぐらい

難しいの

-d オプション

リストア先のデータベースの名前を指定する。 つまりは、-d db_nameとした場合、db_nameにリストアする。 ただし、これは-Cオプションと併用しない場合の話。

-Cオプションと併用すると、db_nameに接続して、ダンプ内に書かれているデータベースをCREATEしてリストアする。

しかし、スキーマ単位のダンプをリストアしようとしたり、-nオプションと併用すると、やっぱりdb_nameにリストアしちゃう。

ちなみに、-dオプションをつけ忘れた場合は、標準出力にリストア(SQL表示)される。

わかりにくい。

-c オプション

このオプションをつけると、テーブルに対してDROP→CREATEしてからリストアする模様。 存在しないテーブルもダンプ内に含まれている場合はCREATEしてくれる。 ただし、リストア対象に関係ないものは当然削除しない。

-C オプション

リストア対象を作成してからリストアするというオプション。 リストア対象のデータベースとかスキーマとかをCREATEしてからリストアする模様。

-cオプションと併用するとデータベースとかスキーマとかをDROP→CREATEという動きになる?

んでも、よく(依存関係などがあると?)DROPに失敗する。その場合はデータのリストアも失敗する? 雰囲気的にはデータは追加されてもよいと思うけど、エラー時の挙動がよくわかんない。

リストア対象に関係ないものを削除したい(ダンプの状態にデータベースを戻したい)とか思って-cと-Cの両方をつけても上手く行かない場合が多い(経験上)。

まとめ

-cと-Cオプションを併用したときの挙動が理解できていない。ので、理解できていないうちは使用しないのが無難かも。