ステータス:非推奨

この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。

理由:
Ubuntu 12.04は2017年4月28日に保守終了(EOL)に達しました and no longer receives security patches or updates. This guide is no longer maintained.

代わりに参照してください:このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。

序章


PostreSQL、またはpostgresは、Webサイトまたはアプリケーションに関連付けられたデータを整理および管理できる一般的なデータベース管理システムです。 レプリケーションは、高可用性と冗長性を実現するために、データベース情報を2番目のシステムにコピーする手段です。

postgresシステムでレプリケーションを設定する方法はたくさんあります。 このチュートリアルでは、ホットスタンバイを使用してレプリケーションを構成する方法について説明します。これには、構成が比較的簡単であるという利点があります。

これを行うには、2つのUbuntu12.04VPSインスタンスが必要です。 1つはマスターデータベースサーバーとして機能し、もう1つは複製するスレーブとして機能します。

PostgreSQLソフトウェアをインストールする


このセクションの手順は、マスターサーバーとスレーブサーバーの両方で実行する必要があります。

postgresソフトウェアは、Ubuntuのデフォルトのリポジトリで利用できます。 これらのコマンドを使用して適切なパッケージをインストールします。

sudo apt-get update
sudo apt-get install postgresql postgresql-contrib postgresql-client

PostgreSQLは、初期データベースを処理するために「postgres」というユーザーを作成します。 ファイルの転送を容易にするために、サーバー間のsshアクセスを構成します。

最初にキーファイルを転送できるように、postgresユーザーのパスワードを設定する必要があります。 必要に応じて、後でパスワードを削除できます。

sudo passwd postgres

次のようにpostgresユーザーに切り替えます。

sudo su - postgres

postgresユーザーのsshキーを生成します。

ssh-keygen

続くすべてのプロンプトに対して「ENTER」を押します。

次のように入力して、キーを他のサーバーに転送します。

ssh-copy-id IP_address_of_opposite_server

これで、postgresユーザーとして2つのサーバー間で自由にSSH接続できるようになります。

マスターサーバーを構成する


まず、マスターサーバーを構成します。 これらのコマンドはすべて、postgresユーザーで実行する必要があります。

まず、レプリケーションにのみ使用できる「rep」というユーザーを作成します。

psql-c「CREATEUSERrepREPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTEDPASSWORD'yourpassword ';」

パスワードを使用したいものに変更します。

次に、postgres構成ディレクトリに移動します。

cd /etc/postgresql/9.1/main

作成したユーザーでアクセスファイルを変更します。

nano pg_hba.conf

ファイルの下部のではなくの任意の場所に、新しいユーザーがこのサーバーにアクセスできるようにする行を追加します。

ホストレプリケーション担当者IP_address_of_slave /32 md5

ファイルを保存して閉じます。

次に、メインのpostgres構成ファイルを開きます。

nano postgresql.conf

これらのパラメータを見つけます。 コメントされている場合はコメントを外し、以下にリストされている内容に従って値を変更します。

 listen_addresses ='localhost、 IP_address_of_THIS_host ' wal_level ='hot_standby' archive_mode = on archive_command='cd。'  max_wal_senders = 1 hot_standby = on

ファイルを保存して閉じます。

マスターサーバーを再起動して、変更を実装します。

service postgresql restart

スレーブサーバーを構成する


postgresデータベースソフトウェアをシャットダウンして、スレーブサーバーで開始します。

service postgresql stop

postgresファイルに同様の構成変更を加えるので、構成ディレクトリに変更します。

cd /etc/postgresql/9.1/main

アクセスファイルを調整して、他のサーバーがこれに接続できるようにします。 これは、後でスレーブをマスターに変える必要がある場合に備えています。

nano pg_hba.conf

繰り返しますが、この行をファイルの最後ではない場所に追加します。

ホストレプリケーション担当者IP_address_of_master /32 md5

ファイルを保存して閉じます。

次に、postgres構成ファイルを開きます。

nano postgresql.conf

マスターサーバーに設定したものと同じ構成オプションを使用して、スレーブサーバーのアドレスを反映するようにIPアドレスのみを変更できます。

 listen_addresses ='localhost、 IP_address_of_THIS_host ' wal_level ='hot_standby' archive_mode = on archive_command='cd。'  max_wal_senders = 1 hot_standby = on

ファイルを保存して閉じます。

初期データベースの複製:


スレーブがマスターを複製する前に、構築するための初期データベースをスレーブに与える必要があります。 これは、マスターサーバーからログを読み取り、変更を独自のデータベースに適用するためです。 そのデータベースがマスターデータベースと一致する必要があります。

マスターサーバーでは、内部のpostgresbackupstartコマンドを使用してバックアップラベルコマンドを作成できます。 次に、データベースデータをスレーブに転送し、内部バックアップ停止コマンドを発行してクリーンアップします。

 psql -c「selectpg_start_backup('initial_backup');」  rsync -cva --inplace --exclude =  pg_xlog  /var/lib/postgresql/9.1/main/ slave_IP_address :/var/lib/postgresql/9.1/main/ psql -c“ select pg_stop_backup();”

rsyncコマンドで証明書ファイルの変更中にエラーが発生した可能性がありますが、これで問題ありません。 これで、マスターのデータがスレーブにあるはずです。

次に、スレーブでリカバリファイルを構成する必要があります。 スレーブでデータディレクトリに移動します。

cd /var/lib/postgresql/9.1/main

ここでは、recovery.confという名前のリカバリファイルを作成する必要があります。

nano recovery.conf

以下の情報を入力してください。 マスターサーバーのIPアドレスと、作成したrepユーザーのパスワードを必ず変更してください。

standby_mode ='on' primary_conninfo ='host = master_IP_address port = 5432 user = rep password = yourpassword ' trigger_file ='/tmp/postgresql.trigger.5432'

ファイルの最後の行trigger_fileは、構成全体の中で最も興味深い部分の1つです。 スレーブマシンのその場所にファイルを作成すると、スレーブはマスターとして機能するように自身を再構成します。

これにより、特にマスターサーバーがまだ実行されている場合は、現在のレプリケーションが中断されますが、マスターサーバーがダウンした場合に実行する必要があります。 これにより、スレーブは書き込みの受け入れを開始できます。 次に、マスターサーバーを修正し、それをスレーブに変えることができます。

これで、スレーブサーバーを起動するための要素が揃っているはずです。 タイプ:

service postgresql start

ログをチェックして、問題がないかどうかを確認する必要があります。 これらは、ここの両方のマシンにあります。

less /var/log/postgresql/postgresql-9.1-main.log

マスターサーバーに正常に接続していることがわかります。

レプリケーションをテストする


マスターサーバーに変更を加えてからスレーブにクエリを実行することで、サーバーが正しく複製されているかどうかを直接確認できます。

マスターサーバーで、postgresユーザーとして、次のように入力してpostgresシステムにログインします。

psql

プロンプトが変わり、データベースソフトウェアと通信していることを示します。

いくつかの変更を作成するためのテストテーブルを作成します。

CREATE TABLE rep_test (test varchar(40));

これで、次のコマンドを使用してテーブルにいくつかの値を挿入できます。

INSERT INTO rep_test VALUES ('data one');
INSERT INTO rep_test VALUES ('some more words');
INSERT INTO rep_test VALUES ('lalala');
INSERT INTO rep_test VALUES ('hello there');
INSERT INTO rep_test VALUES ('blahblah');

次のように入力して、このインターフェイスを終了できます。

\q

次に、スレーブで、同じ方法でデータベースインターフェイスに入ります。

psql

これで、マスターデータベースに入力したデータがスレーブに複製されているかどうかを確認できます。

SELECT * FROM rep_test;

      test       
-----------------
 data one
 some more words
 lalala
 hello there
 blahblah
(5 rows)

素晴らしい! データはマスターサーバーとスレーブサーバーの両方に書き込まれています。

スレーブのテーブルにさらにデータを挿入できるかどうかを見てみましょう。

INSERT INTO rep_test VALUES ('oops');

ERROR:  cannot execute INSERT in a read-only transaction

ご覧のとおり、スレーブにデータを挿入することはできません。 これは、データが一方向にのみ転送されているためです。 データベースの一貫性を保つために、postgresはスレーブを読み取り専用にする必要があります。

結論


これで、マスターとスレーブのPostgreSQLサーバーが効果的に通信するように構成されているはずです。 データベースへの書き込みとデータベースへのクエリを行うアプリケーションがある場合は、常にマスターに書き込むように負荷分散スキームを設定できますが、読み取りはマスターとスレーブの間で分割されます。 これにより、データベースの相互作用のパフォーマンスが向上する可能性があります。

ジャスティン・エリングウッド