負荷のかかったPostgreSQL 9.0から9.2への移行

すべての人に良い一日を！
ご存知のように、最近リリースされたPostgreSQL 9.2は、多くの興味深い有用な機能を備えています。 考え直すことなく、ストリーミングレプリケーションクラスターを9.0から9.2にアップグレードすることにしました。 いくつかの状況がなければ、すべてがうまくいくでしょう：

• これは、大規模な毎日の出席を伴う生産です。
• ダウンタイムは除外されます。

まあ、それはさらにおもしろい...どうやってそれをやったのか、そしてそれから何が読まれたのか。

なんでこんなこと？

• PostgreSQL 9.2でパンを導入したい;
• フラッシュウィザードを使用したPostgreSQLウィザードのサーバーへの転送。

与えられた：

• 3台のハードウェアサーバー。そのうち2台はマスター+スレーブ9.0の束をホストし、もう1台はフラッシュキャッシュを備えた空いているサーバーをホストします。
• バンドルは、ネイティブストリーミングレプリケーションを使用して複製されます。
• アプリケーションを備えた4つのバックエンドとsphinxを備えたマシンは、データベースサーバーを常に使用しています。

問題点：

• パッケージを9.0から9.2にアップグレードしただけではクラスターは機能しません（クラスターを再初期化または更新する必要があります）。
• pg_upgradeは、クラスターを停止しないと使用できません。
• ダウンタイムのため、再初期化と後続のpg_restoreも実行できません。
• 最初にウィザードを更新してから、スレーブを更新することはできません。 メジャーバージョン間のストリームレプリケーションは機能しません。

どうやって道を見つけたのですか？
Skytools-3.0パッケージのLondisteを使用して終了しました。これは、8.4から9.0に既に移行したため、経験があります。 Londisteを使用した複製は、クラスター内の個々のテーブルとデータベースを複製できるため便利です（たとえば、ストリーミング複製、クラスター全体の複製）。 さらに、最後の動きに関して、ストリーミングレプリケーションが可能になりました。 そして、これも問題ではありません。 Londisteを介して複製されたデータは、ストリーミング複製を使用して、新たに発生したスレーブ9.2に直ちに複製されます。 優れたスキームが出てきます。9.2にレプリケートしたら、スレーブ9.2でデータを透過的に埋めます。 したがって、問題のスキームとアルゴリズム：



1.管理部：

• マスターとスレーブを上げる9.2。 標準ポートがすでに使用されているため、スレーブ9.2はポート6543で起動されます（図を参照）。
• それらの間のストリーミング複製を上げます。
• 新しく構成されたウィザード9.2にSkytoolsをインストールします。
• Londisteを構成します。 マスター9.0からプロバイダーを作成し、マスター9.2からサブスクライバーを作成します。
• マスター9.2 londisteとpgqdで開始し、londisteに組み込まれたツールを使用してバンドルの操作性を確認します。
• プロバイダー側​​では、すべてのテーブルとシーケンスをレプリケーションに追加します（レプリケーション可能なテーブルは主キーを持つテーブルのみです。キーのないテーブルがある場合は、そこにキーを作成するか、手動で転送する必要があります...そこにキーを作成するよりも手渡しが安価なスキーム）;
• 手動で転送する必要があるスキームとテーブルを決定します。
• サブスクライバーで、テストテーブルのレプリケーションを開始し、ログによって、プロバイダー9.0からのデータがサブスクライバー9.2に移動し、ストリーミングレプリケーションを介してスレーブ9.2に到達することを確認します。

したがって、技術的な側面からはすべて準備ができています。 現在、レプリケーションの進行と切り替えの瞬間を計画することが残っています。 土曜日が切り替え日として選択されます。 問題が発生した場合、日曜日が残ります。 イベントを準備段階と切り替え段階の2つの段階に分けました。 切り替えはどのように実行されますか？ これを行うために、新しい9.2バンドルに2つの新しいDNS名db-masterとdb-slaveを導入しました。 適切なタイミングで、これらの名前をバックエンド構成に書き込み、アプリケーションを再起動します。
準備計画の活動のいくつかはすでに上記で説明されていますが、完全を期すために、それでも簡単に残しておきます。

金曜日まで：

• 新しいクラスターpg-9.2を作成します。
• pg-9.0とpg-9.2の間でlondisteを設定します。
• 隣接ポートで新しいslave.pg-9.2を上げ、master.pg-9.2でストリーミングレプリケーションを構成します。
• マスター9.0およびスレーブ9.0からの平日の新しいpgfouineレポートを準備します。 上位のクエリプランを比較するにはレポートが必要です。
• 主キーの作成を必要としないすべてのスキームをlondisteプロバイダーに追加します。
• すべてのバックエンドから、新しいPostgreSQLインスタンスに接続する機能を確認してください。
• 新しいデータベース、接続制限、自動バキューム設定の構成を再確認してください。
• 新しいデータベースの監視を設定します（pg_stat *テーブルをプルする自己記述bashスクリプトと組み合わせてzabbixを使用します）。
• 新しいデータベースに新しいDNS名db-masterおよびdb-slaveを作成します。
• 土曜日の作業について編集者に警告する（これは単にトップへの警告であるため、準備ができていて、何かが起こっても質問をしませんでした）。

金曜日：

• 夜間のインポートを無効にします（これは地獄のようなデータインポートです。メカニズムはlondisteレプリケーションを100％破壊するようなものです。これはプロジェクトの内部キッチンですが、どのプロジェクトも同様のコンポーネントを持つことができるため、操作の目的に影響するすべての要素（データベース） ）;
• londistを介してデータ転送を開始します。 サブスクライバーにテーブルが追加されると、コピーによってレプリケーションメカニズムが開始されます。その後、テーブルの一貫した状態が修正され、レプリケート可能と見なされます）。
• 手動転送のスキームのリストを準備します。

土曜日：これは切り替えの日です。

• マスターとスレーブから9.2までの上位10件のクエリを確認します（ゲームはろうそくに値しないのでしょうか？）。
• スキームを手動で転送するためのコマンドを準備します（コンソールで愚かにそれらを叩き、適切なタイミングでEnterを押します）。

11.00-12.00編集の一時停止：

• クラウン、バックグラウンドタスクのデーモンを停止し、アクティブなタスクの完了を待ちます。
• 綿密な編集（現時点では、アプリケーションがアプリケーション側からデータベースに書き込むことは不可能です。この方法により、サイトのクライアントからデータベースを編集したり、バックエンドでアプリケーションを再起動したときにデータが不整合になるリスクを回避できます）;
• 残りの回線を新しいデータベースにダンプします。

12.00-12.30の切り替え：

• londisteレプリケーションの折りたたみ（テーブル、シーケンス、ノードの表示、londisteおよびpgqdの停止）;
• バックエンドの設定を修正します。
• バックエンド（nginx +パッセンジャー）でアプリケーションを再起動します。
• sphinxの構成を更新して再起動します。

それだけです その後、外部レコード全体（レコードソースはサイト上のクライアント）がクラスター9.2に移動したため、londisteを介したレプリケーションは一貫しなくなります。

• バックグラウンドタスクデーモンの構成を修正して実行します。 クラウンを実行します。
• 編集を開く;
• すべてのコントロールを開き、可能性のある妨害を探します。

切り替え後：

• 夜間インポートを有効にします。
• Cronログ、バックグラウンドタスクのデーモンログ、レプリケーションログを確認します。

移動後

• このために、db-slaveを標準ポートに転送します。
• スレーブと連携するバックエンドを切り替えて、マスターと連携します。
• pg-9.0をオフにします。
• 新しいpg-9.2をフルメモリで動作するように設定します（ホスト上に2つのPostgreSQLインスタンスがあったことは忘れられないため、メモリをそれらの間で分割する必要がありました）。
• ポート5432でdb-slaveを実行し、バックエンドとスフィンクスからの接続を確認します。
• 整合性とレプリケーションの遅延を確認します。
• バックエンド側にスレーブを配置します。

ロールバック。 何かがうまくいかない場合の計画：

• 編集を閉じる;
• バックグラウンドタスクとクラウンのデーモンを停止し、アクティブなタスクの完了を待ちます。
• 構成内のデータベースサーバー名を元の名前に修正し、バックエンドを再起動し、バックグラウンドタスクのデーモンを起動します。
• sphinxの構成をロールバックします。
• 編集を開きます。

実際にはアルゴリズム全体。 もちろん、イベントの過程で、すべてが一般的な計画どおりに進んだわけではありません。 幸いなことに、ロールバック計画に頼る必要はありませんでした。
何がうまくいかなかったのかを話せば、ほんの数点しかありません。
最初の段落は、最近開始されたサービスと、回線を手動で転送するためのメカニズムに関するものです（一般的には回避することが望ましい）。 サービスに関するいくつかの言葉：pgqの作業に基づくサービスが失敗しました。pgqスキームを複製する方法は完全には明確ではありませんでした（pgq自体は複製メカニズムの一部でした）。 手動の移行でも状況は修正されなかったため、スキームを再初期化し、サービスを再起動する必要がありました（これは重要ではありませんが、依然として妨害です）。
回路の転送について...練習により、回路の転送が必ずしも希望どおりに行われないことが示されています。 レプリケーションセットアップの初期段階でデータベーススキーム全体が作成されることを考慮すると、将来、既存のオブジェクトまたは個別のデータの上にスキームを転送する必要があり、転送中に次のようなエラーが発生する可能性があります。
エラー：テーブルでの挿入または更新が外部キー制約に違反しています
詳細：テーブルにキーが存在しません。
したがって、回線の転送は次のように行うのが最適であるという結論が得られます。
宛先データベースの既存の空のスキーマの名前を変更し、ソースからスキーム全体を転送し、宛先データベースから古い名前を変更したスキームを削除します。 スキームのIDの確認は、bashコンストラクトを通じて実行できます。 両方のホストでコマンドを起動し、コンプライアンスの出力を比較します（diffを使用）

# for i in schema_1 schema_2 schema_3; do psql -ltAF. -U postgres -c "\dt $i." db_name |cut -d. -f1,2 ; done |while read line ; do echo "$line" - $(psql -qAtX -U postgres -c "select count() from $line" db_name); done 

最後に、もちろん、いくつかのサービス/バックエンドが既に新しいデータベースに切り替えられており、他の部分がまだではない場合、データベースのレコードが表示される可能性のあるすべての場所を数回チェックし、切り替えるときに記録の可能性を除外する必要があることに注意したいです。 さらに議論すれば、理論的にはボリュームを完全に読み取り専用に変換し、切り替え（mount / dmsetup / blockdev）を実行できます。

さて、少しのグラフ。
1. NewRelic。 バックエンドの切り替えプロセス


2. Zabbix。 PG 9.0での毎日のサーバー操作（9月10日月曜日）


3. Zabbix。 PG 9.0を実行するサーバーの昼間（9月10日月曜日）


4. Zabbix。 PG 9.2 + FlashCacheによる毎日のサーバー操作（9月17日月曜日）


5. Zabbix。 PG 9.2 + FlashCacheを使用したサーバーの昼間（9月17日月曜日）


Zabbixのグラフィックスの最大の悪は、iowaitを反映した黒い線です。 ご覧のとおり、フラッシュキャッシュの使用により、ハードドライブの負荷が大幅に削減されました。

技術的な詳細を気にする人：
PostgreSQLでのスレッドレプリケーションの設定方法については、 こちらをご覧ください 。
Skytools-3を使用してPostgreSQLクラスター間でテーブルレプリケーションがどのように構成されているかを確認するには、 こちらをご覧ください 。

これは、あるサブボトニックの物語です。 ご清聴ありがとうございました！