PostgreSQLレプリケーション
私たちは常にオフィスでこれを打ち負かしており、その問題は増え続けています。 PostgreSQLレプリケーションをどのように処理しますか？私は必ずしも高度なクラスターについて話しているわけではなく、マスタースレーブ、マスターマルチスレーブ、およびマスターマスターでそれを単純に保ちます。 MySQLの設定は、通常は非常に簡単です。フェイルオーバーは、完全ではないにしても簡単です。特に、構成がいかに簡単であるかがわかります。私たちはSlonyを試してみましたが、少しやりすぎです（スキーマの変更には介入が必要、新しいデータベースには介入が必要など）。 PGPool2は、ノードがダウンし、レプリケーションを同期化するための適切な方法（すべてをダウンさせて、落ちたノードを再シードする以外）が見つからなくなるまで、かなり良かったです。基本的にここに私が通常探しているものがあります：
- 簡単なセットアップ（セットアップは難しいが、拡張は簡単）
- 単純なフェイルオーバー
- 落ちたノードを元に戻すには、時間が必要です（つまり、mysqlのように、サーバーがダウンし、起動して、レプリケーションが追いつくのを待ちます）。
- スキーマを変更してもレプリケーションが中断されない
- サーバーへの新しいデータベースの追加はシームレスです（つまり、mysqlのように、DBサーバー全体を複製できるため、マスター上に新しいデータベースが作成され、自動的にスレーブに伝播されます）。
MySQLはこれらのほとんどをかなりうまく処理しますが、私はPostgreSQLにある程度の愛着を持っています。その上、これが唯一の選択肢である状況がいくつかあり、レプリケーションをミックスに追加したいと考えています。あなたは現在何を使っていますか、そしてあなたの解決策についてどう思いますか？これはMySQL対PostgreSQLの投稿ではありません。私が始めようとしているのはそれではないためです。 :)
短い答え-オンラインの読み取り専用スレーブが必要な場合、PostgreSQLにはまだそのようなソリューションはありません。
PostgreSQL 9.0（Spring/Summer 2010）に含まれている、この領域で現在進行中の2つの主要な開発プロジェクトがあります。
- 同期レプリケーション：
http://wiki.postgresql.org/wiki/NTT's_Development_Projects
- ホットスタンバイスレーブのみを読み取ります。
http://wiki.postgresql.org/wiki/Hot_Standby
これは、組み合わせて、MySQLスタイルのレプリケーションの使いやすさから、MySQLが持っているバグ/問題を除いた使いやすさを実現することを目的としています。
これらはすべて、2008年にPostgreSQLコアチームのマニフェストによって開始されました。
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php
最大のユーザーベースを持つ今日のPostgreSQLレプリケーションソリューションは、Slony-I（書き込みにコストがかかり、スキーマを変更する手間がかかる）、WAL shipping/walmgr（スレーブはオンラインでは使用できません）、およびSkype/SkytoolsのpgQ/londiste（完成したソリューションよりも多くのツール/ビルディングブロック）。
Log Shipping、walmgr、Slony-Iについていくつか書きました。
http://blogs.AMD.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=2 詳細については。
そして、リングに別の解決策を投げる：rubyrep。
要件と比較するには：
- 簡単なセットアップ
はい、それが実際にrubyrepの主な焦点です。 - 単純なフェイルオーバー
はい。実際、rubyrepはマスターマスターレプリケーションを実行します。フェイルオーバーする場合、アクションはまったく必要ありません。他のデータベースを使い始めるだけです。 - スキーマを変更してもレプリケーションが中断されない
はい。
主キー以外の変更の場合、レプリケーションは停止する必要さえありません（ただし、スキーマが両側で同時に変更されていることを確認してください）
テーブルを追加/削除するには、レプリケーションデーモンを再起動するだけです。テーブルの主キー列を変更するだけで、少し手間がかかります。 - サーバーへの新しいデータベースの追加はシームレスです（つまり、mysqlのように、DBサーバー全体を複製できるため、マスター上に新しいデータベースが作成され、自動的にスレーブに伝播されます）。
これは限られた方法でのみサポートされます。各rubyrepセットアップは一度に1つのデータベースのみを複製します。 （ただし、複数のデータベースのレプリケーションを設定するのは非常に簡単です。）
ホットリードスレーブを要件とすることについては言及しなかったので、共有ストレージまたはDRBDでHeartbeatを使用することを提案します。それは正しいことを行うだけであり、管理は簡単です。これは、古いMicrosoft SQL ServerクラスタリングのLinux版です。 1つのノードはアクティブで、もう1つのノードはパッシブですが、データは2つのノードで共有されます。 SQLベースのレプリケーションはすべてブロックレベルで下位で処理されるため、SQLベースのレプリケーションについて心配する必要はありません。
真剣に、それはあなたがスレーブを読む必要がないなら断然最良の解決策です。 WALアーカイブの内容は最高の状態であり、サーバーの再起動のために出荷プロセスを中断した場合は、すべてを再度セットアップする必要があります。 slonyとlondisteはマスタードをカットしません。メインのソースツリーに留まり、商用化しない場合は、Heartbeatが最適です。
非同期マスター/スレーブ複製が必要な場合は、Londiste（Skypeのskytoolsパッケージの一部）wiki.postgresql.org/wiki/Londiste_Tutorialを検討してください
インストールは簡単で、新しいDBの追加は簡単で、レプリケーションは「追いつく」だけです。
ただし、フェイルオーバーは組み込まれていません。アプリケーションの接続文字列を変更するか、別のソフトウェア層の背後にあるDB接続を難読化する必要があります。
スキーマの変更は簡単です。他はもっと難しいです。アプリケーションによって異なります。 skytoolsの次のバージョン（バージョン3.0）は、DDLを処理し、フェイルオーバーを容易にする機能を含む予定です。
Slonyが痛すぎて使用できないことがわかったので、Londisteに移動しました。
あなたの要件から、PITRはあなたの問題を解決する最も簡単な方法のようです：
オンラインバックアップとポイントインタイムリカバリ（PITR）
スレーブサーバーにクエリを実行する必要があるとは言わなかったので、PITRがちょうど良いかもしれません。
これは、バージョン8.0以降のPostgreSQLの標準部分であるため、おそらくそれを起動して実行するために必要なものがすべて揃っています。
命令が冗長すぎる場合は、ホットスタンバイデータへの作成/フェイルオーバープロセスの単一コマンドタスクを作成する SkyTools WalMgr を確認してください。
より複雑なレプリケーションシナリオの場合、私はSlony-1で良い経験をしましたが、PostgreSQLには多くの優れたレプリケーション/ HAオプションが用意されています。
「新しいデータベースの追加」を除いて、Mammoth Replicatorを試すことができます（ https://projects.commandprompt.com/public/replicator ）。オープンソースで、セットアップが簡単で、フェイルオーバーをサポートしています。主な制限は、単一データベースであり、DDL変更を複製できないことです。どちらもTODOリストに含まれています。
あなたが探しているものを提供するための無料/オープンソースの方法は本当にありません。すぐに使えるものが必要な場合は、さまざまなサードパーティの商用レプリケーションソリューションをご覧ください。
これでis書き込みヘッドログ（WAL）配送を使用してPostgresで独自のレプリケーションをロールバックすることができます。
http://www.postgresql.org/docs/8.3/interactive/warm-standby.html
これは基本的に、セカンダリノードを継続的リカバリモードにして、{短い間隔}ごとにトランザクションログをインポートできる場所です。 Postgresの設定には「スタブ」があり、WALが完了したときにPostgresが完了したときに特定のことができるようになっています。それが、そのセットアップが前提とするものであり、それらの「スタブ」を利用します。
ただし、マスターマスターや循環レプリケーションを行うことはできません。
いずれにせよ、それは間違いなく冗長性のために機能しますが、「簡単なセットアップ」、「単純なフェイルオーバー」、「シームレス」などとは呼びません。
ここでディスカッションを参照してください。
http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html
そして
Bucardo Version Oneの競合他社は、ページの下の方にあります。
私は現在タングステンレプリケーターを調べていますが、まだ明確な結論には程遠いですが、おそらく一見の価値があります。
Postgres-R は有望に見えましたが、プロジェクトがまだ生きているかどうかはわかりません。