忍者ブログ
データベースエンジニアのための実践ブログ。Oracle・PostgreSQL・MySQLなどの環境構築、実行計画の読み方やチューニングといった現場で役立つノウハウ、DB基礎知識までを発信しています。

【PostgreSQL】Ubuntu + PostgreSQL スクリプト実行ガイド 〜 .sql ファイルの作成から psql での実行・検証まで 〜

本ガイドでは、Ubuntu環境において PostgreSQL のスクリプトファイル(.sql)を作成し、ターミナルから psql コマンドを使って実行する手順を解説する。

対話型シェルにログインして実行する基本方法から、シェルスクリプトなどの自動化(バッチ処理)に組み込む際の本質的な外部実行プロセスまで、ステップバイステップで検証を進めていく。


1. 開発環境の準備(ターミナルの操作)

まずはUbuntu環境に PostgreSQL が導入されているか確認する。未インストールの場合は、パッケージ管理システムの apt を用いて以下の通り導入を行う。

■ インストールの確認と実行

# パッケージインデックスの更新とインストール
sudo apt update
sudo apt install -y postgresql postgresql-contrib

# データベースサービスの起動ステータス確認
sudo systemctl status postgresql

2. スクリプトファイルの作成

検証用の作業ディレクトリを作成し、テストとして「Hello World」の文字列を出力するだけのシンプルなSQLファイルを用意する。

■ 作業フォルダの作成と移動

mkdir ~/psql-study && cd ~/psql-study

■ テスト用SQLファイルの作成(コマンドラインより生成)

echo "SELECT 'Hello World' AS message;" > hello.sql

3. PostgreSQLへのログイン

UbuntuにおけるPostgreSQLの初期設定では、データベースの最高管理権限は postgres という名前のOSユーザーに紐づけられている。
そのため、以下のようにOSの管理者権限を介して psql シェルへログインする。

■ 管理者権限(スーパーユーザー)でのログイン

sudo -u postgres psql

※ sudo -u postgres を付与することで、ログインパスワードの入力を求めることなく、安全にPostgreSQLの内部プロンプトへ入ることができる。


4. ファイルの実行(対話モードでの実践)

psql の対話型プロンプト内で、先ほど作成した外部の .sql ファイルを読み込んで実行させる。

■ スクリプトの実行メタコマンド

プロンプト postgres=# が表示されている状態で、ファイルを指定して以下のインクルードコマンドを入力する。

postgres=# \i hello.sql

■ 期待される実行出力

   message    
-------------
 Hello World
(1 row)

無事に結果が得られたら、以下のメタコマンドで対話型シェルを終了(離脱)する。

postgres=# \q

5. 本質的な「検証」:OSコマンドラインからの非対話実行

実際のシステム運用や、シェルスクリプト(Cronジョブなど)による自動バッチ処理にSQLを組み込む際、わざわざ対話モードに手動ログインするのは現実的ではない。
そこで、プロンプトに入らず、Ubuntuのコマンドラインから直接SQLファイルを流し込んで結果を得る方法を検証する。

ターミナル上で、ディレクトリが ~/psql-study にあることを確認し、以下のコマンドを実行する。

sudo -u postgres psql -f hello.sql

■ 技術解説:-f オプションの役割

-f(file)オプションを使用することで、指定したファイルの中身を直接PostgreSQLのエンジンにパイプラインで流し込み、実行結果をそのまま標準出力(stdout)としてターミナルへ戻すことができる。

この非対話コマンドが正常に通れば、「SQLファイルの外部実行プロセス」がUbuntu環境において正しくセットアップできている証明となる。これをベースに、シェルスクリプトでのデータ抽出や定期バックアップタスク等への応用が可能だ。


PR

【PostgreSQL】論理レプリケーションを自前で動かしてみた実録


実際に手を動かすのが一番。ということで、PostgreSQLの論理レプリケーションをローカル環境で構築してみました。パブリッシャー(出す側)とサブスクライバー(受ける側)のやり取りを、実際にコマンドを叩きながら追いかけます。

1. 設定の落とし穴:wal_levelの変更

【 現場の感触 】 最初のハードルは設定変更です。デフォルトでは論理レプリケーション用のログが出ないので、`postgresql.conf` を書き換えます。再起動が必要なので、本番環境なら「ちょっと待って」となるところですね。

# wal_level を logical にして再起動!
show wal_level;

[ 結果 ]
wal_level
-----------
logical ← これで準備完了。

2. パブリケーションの作成と権限の「儀式」

【 現場の感触 】 テーブルを作ってデータを放り込みます。ここで大事なのは「主キー(PK)」があること。論理レプリケーションでは「どの行を更新するか」を特定するためにPKが必須です。あとは接続用の専用ユーザーを作って、権限を付与します。この「運び屋」を作る作業がレプリケーションっぽさを感じさせます。

-- 全テーブルを対象にパブリケーション作成
CREATE PUBLICATION pub FOR ALL TABLES;

-- レプリケーション専用の「運び屋」ユーザーを作る
CREATE ROLE repluser LOGIN REPLICATION PASSWORD 'repluser';
GRANT pg_read_all_data TO repluser;

3. 同期開始!サブスクリプションの威力

【 現場の感触 】 サブスクライバー側で接続情報を指定してサブスクリプションを作成。実行した瞬間に、既存のデータが「バッ」と流れてくるのは見ていて気持ちいいものです。試しにデータを1行追加すると、即座に反映されるのが確認できました。まさにリアルタイム!

-- サブスクライバー側で実行(ここで同期が始まる)
CREATE SUBSCRIPTION sub CONNECTION 'host=... user=repluser...' PUBLICATION pub;

-- パブリッシャー側で insert
insert into sample_table values(3, 'ccc');

-- サブスクライバー側で確認
select * from sample_table; → ちゃんと 3 | ccc が反映されている!

4. 応用:同期を止めても「裏で溜まっている」

【 現場の感触 】 運用でよくある「一時停止(DISABLE)」も試しました。停止中にパブリッシャー側でガシガシ更新('ddd'を追加)しても、サブスクライバー側は静かなまま。でも、再度「ENABLE」にした瞬間、溜まっていた更新が追い付いてくる。この確実性が論理レプリの頼もしいところです。

★ 検証のまとめ:
1. DISABLEにすると、サブスクライバー側はピタッと止まる。
2. パブリッシャー側の変更は破棄されず、裏(スロット)に保持される。
3. ENABLEに戻すと、未反映分が高速に流し込まれる。


実際にやってみると、コマンド一発で同期が制御できる手軽さと、内部でWALがしっかり管理されている安心感がよく分かりました。バージョン間のデータ移行や、特定のデータ集約には最高に便利そうです。