Ubuntu12.04VPSのPostgreSQLでマスタースレーブレプリケーションを設定する方法
ステータス:非推奨
この記事では、サポートされなくなったバージョンの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サーバーが効果的に通信するように構成されているはずです。 データベースへの書き込みとデータベースへのクエリを行うアプリケーションがある場合は、常にマスターに書き込むように負荷分散スキームを設定できますが、読み取りはマスターとスレーブの間で分割されます。 これにより、データベースの相互作用のパフォーマンスが向上する可能性があります。