![19
Copyright ? 2012 NTT DATA Corporation
レプリケーションの監視
=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
procpid | 26531
usesysid | 10
usename | postgres
application_name | tokyo
client_addr | 192.168.1.2
client_hostname |
client_port | 39654
backend_start | 2012-02-01 18:54:49.429459+09
state | streaming
sent_location | 0/406E7CC
write_location | 0/406E7CC
flush_location | 0/406E7CC
replay_location | 0/406E1B0
sync_priority | 1
sync_state | sync
レプリケーションの進捗
マスタはどこまでWALを送信したか?
スタンバイがどこまでWALを
書き込み/フラッシュ/リカバリしたか?
レプリケーション接続情報
スタンバイのIPアドレス、ポート番号、
レプリケーションに使用するユーザ名、
レプリケーションの開始日時など
レプリケーションの状態
どの同期モードで動作中か?
スタンバイはマスタに追いつき中か?済か?](https://image.slidesharecdn.com/postgresql-141001030359-phpapp02/85/PostgreSQL-19-320.jpg)
![[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ～AlwaysOn＋Qシステムで完全無停止運用～ by Nobuyuki Sa...](https://cdn.slidesharecdn.com/ss_thumbnails/c33sqlserversasaki-131128193643-phpapp01-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to 笔辞蝉迟驳谤别厂蚕尝レプリケーション彻底绍介 (20)
![[db tech showcase Tokyo 2015] B24:最高峰の可用性 ～NonStop SQLが止まらない理由～ by 日本ヒューレット?パ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015b24nonstop-sqlhp-150619075240-lva1-app6892-thumbnail.jpg?width=560&fit=bounds)
More from NTT DATA OSS Professional Services (20)
笔辞蝉迟驳谤别厂蚕尝レプリケーション彻底绍介
- 1. Copyright ? 2012 NTT DATA Corporation 2012年10月18日 NTTデータ/JPUG 藤井雅雄 笔辞蝉迟驳谤别厂蚕尝レプリケーション彻底绍介
- 2. 2 Copyright ? 2012NTT DATA Corporation 謝辞 本資料は、NTT OSSセンタ様の以前の講演資料を ベースにしております。ご提供承諾いただきありがとう ございます。
- 3. 3 Copyright ? 2012NTT DATA Corporation 目次 ? レプリケーションとは? ? PostgreSQLレプリケーション 1. 特徴 2. 同期/非同期 3. 利用事例
- 4. Copyright ? 2012 NTT DATA Corporation 4 レプリケーションとは?
- 5. Copyright ? 2012 NTT DATA Corporation 5 レプリケーションとは? クライアント クライアント 更新 更新 DBサーバ 更新 複製 DBサーバ 更新 中継サーバ 複数のサーバにデータベースを自動的に複製する機能
- 6. Copyright ? 2012 NTT DATA Corporation 6 なぜレプリケーションが必要か? 24時間365日システムを安定運用するのに必要! 高可用性 負荷分散 1台が故障しても、別サーバが処理を引き継げる システム全体としてDBサービスが停止するのを回避できる SQL実行の負荷を複数のサーバに分散できる 負荷が一箇所に集中しないので、システム全体として性能向上できる クライアント クライアント SQL SQL SQL 高可用 負荷分散 DBサーバ DBサーバ
- 7. Copyright ? 2012 NTT DATA Corporation 7 PostgreSQLレプリケーションの歴史 2007 2008 2009 2010 2012 2011 9.0(2010/9リリース) ? 非同期レプリケーション 9.1(2011/9) ? 同期レプリケーション ? レプリケーション監視機能強化 ? 物理バックアップ取得ツール 9.2(2012/9) ? カスケードレプリケーション ? スタンバイからの 物理バックアップ取得 ? 同期モードの拡張 Slony-I Bucardo Londiste Sequoia PGCluster PostgresForest Postgres-R Mammoth PL/Proxy pgpool-II rubyrep Postgres-XC GridSQL syncreplicator レプリケーションツールが乱立! 当初コミュニティはPostgreSQL本体にレプリケーション機能を組み込まない方針だったが、 ユーザの声を受けて、9.0から本体にレプリケーション機能を搭載! 以降、レプリケーションは着実に進化中
- 8. Copyright ? 2012 NTT DATA Corporation 8 PostgreSQLレプリケーションの特徴
- 9. Copyright ? 2012 NTT DATA Corporation 9 シングルマスタ/マルチスタンバイ構成 シングルマスタ マルチスタンバイ マルチスタンバイ 複製 複製 更新SQL 参照SQL 参照SQL 参照SQL マスタ1台からスタンバイ複数台へのレプリケーション カスケードレプリケーション マスタは更新と参照SQL両方、スタンバイは参照SQLのみ実行可能 ?参照系処理のスケールアウトに利用可能
- 10. 10 Copyright ? 2012 NTT DATA Corporation スタンバイで実行可能/不可能なSQL オンライン?バックアップ –(論理) pg_dump –(物理) pg_basebackup メンテナンス?コマンド –VACUUM, ANALYZE ※マスタからメンテナンスの実行結 果が複製されるため、スタンバイ では実行不要 実行可能 クエリ?アクセス –SELECT –PREPARE, EXECUTE –カーソル操作 実行不可能 データ操作言語(DML) –INSERT, UPDATE, DELETE –SELECT FOR UPDATE データ定義言語(DDL) –CREATE, DROP, ALTER 一時テーブル
- 11. Copyright ? 2012 NTT DATA Corporation 11 ログシッピング マスタからスタンバイにトランザクションログ(WAL)を転送 スタンバイはリカバリモード 転送されたWALをリカバリすることで、スタンバイはデータベースを複製 マスタ スタンバイ リカバリ 更新SQL クライアント WAL書き込み WAL転送 WAL書き込み
- 12. 12 Copyright ? 2012 NTT DATA Corporation ログシッピングによる制約 マスタとスタンバイでは以下2点が同じでなければならない ? ハードウェアとOSのアーキテクチャ ? PostgreSQLのメジャーバージョン ?異なる環境間のレプリケーション(ローリングアップグレード)には Slony-Iを利用 マスタ スタンバイ 64ビットOS PostgreSQL9.2.1 PostgreSQL9.1.0 32ビットOS 64ビットOS PostgreSQL9.2.0 NG NG OK 2 1
- 13. 13 Copyright ? 2012 NTT DATA Corporation データベースクラスタ単位のレプリケーション データベースクラスタ単位 テーブル単位 マスタ スタンバイ マスタ スタンバイ すべてのデータベースオブジェクトが基本的にレプリケーション対象 ?テーブル単位のレプリケーション指定は不可 ?テーブル単位のレプリケーションにはSlony-Iを利用
- 14. 14 Copyright ? 2012 NTT DATA Corporation (参考)UNLOGGED TABLE WALを書かないテーブルを作成可能! ?レプリケーション対象にならない ?更新性能が著しく向上 ?クラッシュ時にテーブルが空になる ?信頼性より性能を必要とするテーブルに有効 通常のテーブル 更新 UNLOGGED TABLE WALの書き込みとレプリケーションがなく 非常に高速! 更新 書き込み WAL領域 スタンバイ レプリケー ション
- 15. Copyright ? 2012 NTT DATA Corporation 15 レプリケーション構成への移行が容易 テーブル定義の変更不要 ? 例)テーブルにプライマリキーを定義する必要がない SQLの書き換え不要 ? 例)実行するまで結果が確定しないSQLを矛盾なく実行可能 ? PostgreSQLがサポートするすべてのSQLをマスタで実行可能 クライアント PostgreSQL単体 クライアント マスタ スタンバイ 容易な移行
- 16. Copyright ? 2012 NTT DATA Corporation 16 SQLの振り分け PostgreSQLはSQLの振り分け機能を提供しない ? クライアント側で振り分けを独自実装 ? 振り分けを行うソフトウェア(pgpool-II)を利用 クライアント クライアント 更新SQL 参照SQL マスタ 更新SQL 更新/参照SQL 振り分けソフト スタンバイ 参照SQL マスタ スタンバイ 独自に実装 振り分けソフトの利用
- 17. 17 Copyright ? 2012 NTT DATA Corporation (参考)pgpool-IIによるSQLの振り分け BEGIN → SELECT → SELECT (一時テーブル) → SELECT FOR UPDATE → UPDATE → SELECT → COMMIT → マスタ スタンバイ マスタ マスタ マスタ マスタ マスタ トランザクション内の参照SQLも スタンバイに振り分け スタンバイで実行できない 参照SQLはマスタに振り分け 更新SQLはマスタに振り分け 更新SQL後の参照SQLは マスタに振り分け。 更新SQLの実行結果を、 参照SQLがすぐに参照する 必要があるため スタンバイの遅れが閾値を 超えていたら、マスタに振り分け
- 18. Copyright ? 2012 NTT DATA Corporation 18 フェイルオーバ PostgreSQLは自動的なフェイルオーバ機能を提供しない ? スタンバイはいつでもマスタに昇格可能(pg_ctl promote) ? 自動的な故障検知とフェイルオーバにはクラスタソフトと要連携 クライアント クライアント マスタ pgpool-II マスタ スタンバイ スタンバイ Pacemaker pgpool-II VIP PostgreSQLレプリケーションの クラスタリング機能搭載済!
- 19. 19 Copyright ? 2012 NTT DATA Corporation レプリケーションの監視 =# SELECT * FROM pg_stat_replication; -[ RECORD 1 ]----+------------------------------ procpid | 26531 usesysid | 10 usename | postgres application_name | tokyo client_addr | 192.168.1.2 client_hostname | client_port | 39654 backend_start | 2012-02-01 18:54:49.429459+09 state | streaming sent_location | 0/406E7CC write_location | 0/406E7CC flush_location | 0/406E7CC replay_location | 0/406E1B0 sync_priority | 1 sync_state | sync レプリケーションの進捗 マスタはどこまでWALを送信したか? スタンバイがどこまでWALを 書き込み/フラッシュ/リカバリしたか? レプリケーション接続情報 スタンバイのIPアドレス、ポート番号、 レプリケーションに使用するユーザ名、 レプリケーションの開始日時など レプリケーションの状態 どの同期モードで動作中か? スタンバイはマスタに追いつき中か?済か?
- 20. 20 Copyright ? 2012 NTT DATA Corporation その他 クラッシュセーフなマスタとスタンバイ クラッシュしたマスタ/スタンバイを再起動するだけでレプリケーション 再開可能 スタンバイのオンライン追加?削除 マスタ稼働中にスタンバイを追加?削除可能 スケールアウト時にサービスの一時停止が発生しない リカバリの一時停止?再開 スタンバイ側でリカバリを一時停止し、静止点を作成可能 2 1 3
- 21. Copyright ? 2012 NTT DATA Corporation 21 (参考)pg_receivexlog WALの受信と書き込みを繰り返すクライアントツール ? オペミス対策でWALの多重化などの用途 リカバリ マスタ スタンバイ 更新SQL クライアント WAL書き込み WAL転送 WAL書き込み pg_receivexlogは、赤枠の 部分をツール化したもの
- 22. Copyright ? 2012 NTT DATA Corporation 22 PostgreSQLレプリケーションの同期/非同期
- 23. 23 Copyright ? 2012 NTT DATA Corporation レプリケーションモード レプリケーションモードを選択可能 ?非同期 ?同期
- 24. Copyright ? 2012 NTT DATA Corporation 24 非同期レプリケーション COMMIT時にレプリケーションの完了を待たない ? COMMIT成功時にWALがスタンバイに届いている保証なし フェイルオーバ時にCOMMIT済データを失う可能性あり スタンバイの参照SQLで古いデータが見える可能性あり レプリケーション完了を待たないので比較的高性能! リカバリ マスタ スタンバイ COMMIT クライアント WAL書き込み WAL転送 WAL書き込み OK 1 2 3 4 5 6 と の間でフェイル オーバが発生すると、 COMMIT済データを損失 3 4 ? ? ?
- 25. Copyright ? 2012 NTT DATA Corporation 25 同期レプリケーション COMMIT時にレプリケーションの完了を待つ ? COMMIT成功時にWALがマスタ?スタンバイ両方に書き込み済と保証 フェイルオーバ時にCOMMIT済データを失わない! レプリケーション完了を待つので比較的低性能 スタンバイの参照SQLで古いデータが見える可能性あり ? 「同期レプリケーション＝COMMIT済データをすぐにスタンバイで参照可能」 ではないことに注意!! リカバリ マスタ スタンバイ COMMIT クライアント WAL書き込み WAL転送 WAL書き込み OK 1 2 6 3 4 7 5 応答 ? ? WAL転送は同期的だが、 リカバリは非同期的に実行 ?
- 26. Copyright ? 2012 NTT DATA Corporation 26 3 4 同期レプリケーション 応答が届くまでトランザクションの結果は別トランザクションから参照不可 ? 参照を許すと、未COMMITのデータが参照される可能性がある リカバリ マスタ スタンバイ COMMIT クライアント WAL書き込み WAL転送 WAL書き込み OK 1 2 8 5 6 9 7 応答 クライアント 参照SQL 参照結果 応答待ちのトランザクションの結果を が参照した場合 と の間でフェイルオーバが発生すると、 応答待ちのトランザクションの結果はスタンバイに存在しない では未COMMITのデータを参照したことになる 4 5 4 4
- 27. 27 Copyright ? 2012 NTT DATA Corporation スタンバイごとのレプリケーションモード選択 スタンバイごとにレプリケーションモードを選択可能 ?同期レプリケーションを実行できるスタンバイは同時に1台のみ ?同期レプリケーションの実行優先度をスタンバイに設定可能 ?カスケードレプリケーションは非同期モードのみ選択可能 同期 非同期 非同期 同期モードを選択 優先度高 同期モードを選択 優先度低 非同期モードを選択 同期 非同期 スタンバイ スタンバイ 故障 復旧 次に優先度の高いスタンバイ (同期モード選択)が自動的に 同期レプリケーションを引き継ぎ 最も優先度の高いスタンバイ (同期モード選択)が自動的に 同期レプリケーションを再開
- 28. Copyright ? 2012 NTT DATA Corporation 28 トランザクションごとのデータ保護レベル選択 同期レプリケーションでは、トランザクションごとにデータ保護レベルを選択可能 データ保護レベル マスタ スタンバイ WALフラッシュ WAL書き込み WALフラッシュ off 待たない 待たない 待たない local 待つ 待たない 待たない remote_write 待つ 待つ 待たない on 待つ 待つ 待つ リカバリ マスタ スタンバイ COMMIT クライアント WALフラッシュ WAL転送 WALのファイルキャッシュへの書き込み OK 応答 WALのディスクへのフラッシュ 高性能 保護レベル高
- 29. Copyright ? 2012 NTT DATA Corporation 29 非同期レプリケーション継続不可時の挙動 故障により単独稼働するマスタの挙動に注意! ? マスタ故障(フェイルオーバ) ? スタンバイ故障 ? ネットワーク故障 マスタ単独でトランザクションを処理 ? 故障によりトランザクションが停止することはない レプリケーション COMMIT WAL転送 OK マスタ スタンバイ クライアント COMMIT OK マスタ スタンバイ 故障 復旧 → 新マスタ単独稼働 → 既存マスタ単独稼働 クライアント マスタ単独
- 30. Copyright ? 2012 NTT DATA Corporation 30 同期レプリケーション継続不可時の挙動 COMMIT時に(スタンバイからの届くことのない)応答を待ち続ける ? 故障によりトランザクションは停止する! ? 復旧により応答が届くようになったら、トランザクション再開 ?復旧にかかる時間だけシステム停止 クライアント COMMIT WAL転送 OK マスタ スタンバイ クライアント COMMIT マスタ スタンバイ 故障 復旧 応答 レプリケーション マスタ単独 レプリケーション完了応答を 待ち続ける
- 31. 31 Copyright ? 2012 NTT DATA Corporation 同期レプリケーション継続不可時の挙動 トランザクション停止は、データ保護を最優先するため ?COMMIT成功時に確実にWALが複数箇所に書き込み済と保証 マスタ スタンバイ 更新SQL WAL転送 応答 OK 更新SQL 更新SQL OK OK マスタのディスク故障により COMMIT済データを損失!! マスタ単独でのトランザクション処理を 許可すると、COMMIT成功時にWALは マスタのディスクのみに書き込み済
- 32. Copyright ? 2012 NTT DATA Corporation 32 同期レプリケーションでの高可用の実現 マルチスタンバイ構成 故障/復旧時にレプリケーションモードを非同期/同期に設定変更 データ損失リスクは依然あるため、(RAID等)ディスク故障対策が必要 状況に応じてモードを設定変更する機能をPacemakerは搭載済! クライアント COMMIT WAL転送 OK マスタ スタンバイ クライアント COMMIT マスタ スタンバイ 故障 復旧 応答 レプリケーション マスタ単独 OK レプリケーション再開時は 同期に設定 マスタ単独時は 非同期に設定 2 1
- 33. Copyright ? 2012 NTT DATA Corporation 33 PostgreSQLレプリケーションの利用事例
- 34. 34 Copyright ? 2012 NTT DATA Corporation 利用事例： Instagram ??? ??? レプリケーション マスタ12台 スタンバイ12台 利用者4000万人超の写真データを保管 データベースをマスタ12台に水平分散 マスタ12台、スタンバイ12台でレプリケーション 写真共有アプリ/SNS。Facebookが10億ドルで買収 (出典：Scaling Instagram ＠ AirBnB Tech Talk 2012)
- 35. 35 Copyright ? 2012 NTT DATA Corporation レプリケーション構成事例 共有ディスク型とレプリケーションの組み合わせ ?日本と遠隔地に共有ディスク型の高可用構成 ?激甚対策として遠隔地にレプリケーション マスタ 共有ディスク スタン バイ マスタ 共有ディスク スタン バイ
- 36. Copyright ? 2011 NTT DATA Corporation Copyright ? 2012 NTT DATA Corporation
- 37. Copyright ? 2012 NTT DATA Corporation 37 PostgreSQLレプリケーションのアーキテクチャ
- 38. Copyright ? 2012 NTT DATA Corporation 38 プロセス構成 walsender walreceiver startup データベース クライアント 変更 書き込み WAL WAL 読み込み WAL転送 書き込み 読み込み リカバリ 参照 更新SQL 参照SQL bbaacckkeenndd backend bbaacckkeenndd backend マスタ スタンバイ データベース walsender 読み込み WAL転送 ディスク 領域 メモリ領 域 プ ロ セ ス 凡例 OK 応答 応答 walsender 読み込み WAL転送