postgresql 9.0 in osc@tokyo,okinawa
DESCRIPTION
オープンソースカンファレンス 2010 Tokyo/Fall, Okinawa での PostgreSQL 9.0 の紹介。新機能やレプリケーションについて解説する。TRANSCRIPT
日本PostgreSQLユーザ会 / フォルシア株式会社
板垣 貴裕
オープンソースカンファレンス2010.9.11 Tokyo/Fall2010.10.2 Okinawa
� 板垣 貴裕 (いたがき たかひろ)
� 所属◦ 日本PostgreSQLユーザ会
◦ PostgreSQL Committer
◦ フォルシア株式会社◦ フォルシア株式会社
� PostgreSQLは7.4～8.0あたりから触り始めた
� 主にPostgreSQLを中核にしたシステムの開発◦ 必要に応じてPostgreSQL本体の改造や拡張モジュールも作ってみたり。
2
� PostgreSQL 9.0 の新機能◦ 記念すべきリリース
◦ 新機能の紹介 – レプリケーション以外にも盛りだくさん！
� レプリケーションをもっと詳しく◦ ホット・スタンバイを使う際の、お勧めのノード構成◦ ホット・スタンバイを使う際の、お勧めのノード構成
◦ レプリケーションで、できること / できないこと
3
� 9.0は5年ぶりの「記念リリース」◦ 上一桁の更新は「適用領域の大幅な拡大」を表す◦ メジャーバージョンは上2桁 / バグ修整は3桁目
� ホット・スタンバイとレプリケーションをぜひ使って欲しいので！
1977
19961986
PostgreSQL6.0
PostgreSQL6.0
7.47.4
IngressIngress
•パーティショニング•2相コミット•バッファ管理改良
•パーティショニング•2相コミット•バッファ管理改良
8.1
•HOT: 更新性能向上•HOT: 更新性能向上
8.3
9.0 (2010/9/20)
9.0.0メジャー マイナー
4
20032004
2005
2006
20072008
2009
2000
1996
7.37.3
POSTGRESPOSTGRES
•Windows対応対応対応対応•セーブポイント•メディア故障対応(PITR)•テーブルスペース
•Windows対応対応対応対応•セーブポイント•メディア故障対応(PITR)•テーブルスペース
8.0
•バッファ管理改良•バッファ管理改良
•CPUスケール•オンライン索引作成•GIN: 汎用転置索引
•CPUスケール•オンライン索引作成•GIN: 汎用転置索引
8.2
•HOT: 更新性能向上•VACUUM自動化•全文テキスト検索
•HOT: 更新性能向上•VACUUM自動化•全文テキスト検索
2010
Window関数・再帰クエリ•VACUUM用メモリ自動管理•他DBMS互換性向上
Window関数・再帰クエリ•VACUUM用メモリ自動管理•他DBMS互換性向上
8.４
•ホット・スタンバイホット・スタンバイホット・スタンバイホット・スタンバイ•レプリケーションレプリケーションレプリケーションレプリケーション•ホット・スタンバイホット・スタンバイホット・スタンバイホット・スタンバイ•レプリケーションレプリケーションレプリケーションレプリケーション
9.0 (2010/9/20)
� 紹介する新機能◦ 1. ホット・スタンバイとストリーミング・レプリケーション◦ 2. 排他制約 (地理データ型の“重なり”を制限)◦ 3. 高速なVACUUM FULL◦ 4. アクセス制御の一括変更 / デフォルト設定
◦ 5. EXPLAINとクエリ統計の強化◦ 6. Key=Valueデータの保存◦ 7. pgbenchで性能計測 / 負荷試験◦ 7. pgbenchで性能計測 / 負荷試験
� その他の新機能◦ 条件付き 及び 列単位のトリガ◦ LISTEN/NOTIFY の高速化 / メッセージ送信◦ DO文：PL/pgSQLの簡易実行◦ Windows 環境での 64-bit 版サポート
5
その他にも多数の新機能あり。下記URLも参照http://developer.postgresql.org/pgdocs/postgres/release-9-0.htmlhttp://lets.postgresql.jp/documents/technical/9.0/
� PostgreSQL 9.0のレプリケーション機能◦ ホット・スタンバイ (HS)� スタンバイで参照を許可する
◦ ストリーミング・レプリケーション (SR)� WALレコードをスタンバイへ流す
� これまでのウォーム・スタンバイの発展系
2つの組合せ
� これまでのウォーム・スタンバイの発展系
6
8.3
8.0
9.0
ウォーム・スタンバイ
ストリーミング・レプリケーションホット・スタンバイ
オンライン・バックアップ アーカイブ・リカバリ
プライマリ スタンバイ
WAL pg_standbyarchive_command
ウォームスタンバイ(～v8.4)
READ WRITE READ WRITE
8.4
スタンバイ側では何も処理できない
WALファイル単位のため遅延がある (～1分)
7
プライマリ スタンバイ
ホットスタンバイ
(v9.0)
READ WRITE READ WRITE
wal receiverwal sender WAL
9.0
スタンバイ側で参照処理ができる
WALレコード単位のため遅延が少ない (～数秒)
9.0のスタンバイは資源を有効活用できる
レプリケーション Slony-I pgpool-II
バージョン 9.0 2.0 2.3
種別シングルマスタマルチスレーブ
シングルマスタマルチスレーブ
プロキシサーバ
伝播方式 物理変更セット 論理変更セット クエリ複製
伝播遅延 少ない 中程度 無し
更新性能 そのまま 若干低下 低下
複製範囲 DB一括 選択 (手間もかかる) DB一括
良い非常に良い凡例
複製範囲 DB一括 選択 (手間もかかる) DB一括
SQL互換性 完全互換 PK必須, DDL不可※ 概ね互換
スレーブ台数☆ ～10 ～10 ～3
カスケード 不可 可 (意味が無い)
自動参照分散 － － ○
自動切り替え － － ○
バージョン混在 － ○ －
8
用途に応じてサードパーティ製ツールの使い分けが必要※PK=主キー, DDL=データ定義言語☆台数は妥当な性能を得られる上限
� 範囲や地理データ型の“重なり”を制限◦ 一意性制約 (UNIQUE)
� “点” の “一致” を禁止
◦ 排他制約 (EXCLUDE)
� “広がり” を持つ型の “重なり” を禁止
� 地理データ管理やスケジュール管理で有用
� 新しいタイプのアプリケーションでの利用◦ GPS情報を利用するシステム
◦ グループ・コミュニケーション
9
地理データ型の重なり 予約時間の重なり
� 空間を占めるオブジェクトの重なりを避ける
� 部屋の予約時間の重なりを避ける
CREATE TABLE placement (
object text,
location box, -- 矩形EXCLUDE USING gist (location WITH &&)
);
&&は “重なり” を表す比較演算子
◦ 注意� text型のgistインデックスサポートはcontrib/btree_gistが必要
� period型は自作が必要 (次期9.1で計画中)
10
CREATE TABLE reservation (
room text,
during period, -- {開始日時,終了日時}のペアEXCLUDE USING gist (room WITH =, during WITH &&)
);複数列gistインデックスも利用可能
� VACUUM FULLの扱いが正反対に◦ 8.4までは “最悪” のテーブル再編成方法� ダンプ→リストアのほうが遥かに効率的
◦ 9.0からは “最良” のテーブル再編成方法� 内部的なダンプ→リストア相当処理のため、最高速
VACUUM FULLも利用価値UP。ただしあくまで補助
� ほとんどのケースはVACUUM (無印) で十分◦ FULLは対象テーブルの排他ロックが必要◦ 大量削除後はFULLが適する場合もあるが、その場合でも「表分割+TRUNCATE」がより好ましい
11
VACUUM FULLも利用価値UP。ただしあくまで補助
コマンド テーブル インデックス 競合
VACUUM ゴミ取り ゴミ取り なし
VACUUMFULL
8.4 行を移動 ゴミ増加ゴミ増加ゴミ増加ゴミ増加 参照, 更新
9.0 作り直し 作り直し 参照, 更新
CLUSTER ソート+作り直し 作り直し 参照, 更新
REINDEX - 作り直し 参照, 更新REINDEX - 作り直し 参照, 更新
� 普段はVACUUMで「ゴミを取る」だけで十分◦ ゴミを取り除いた後の領域は、次回以降の更新で再利用
� VACUUM FULL (8.4) は、インデックスのゴミが増える◦ 完了後、REINDEXしなければならないケースも
� VACUUM FULL (9.0) と CLUSTERは、REINDEXを含む◦ 追加のREINDEXは不要
≪それぞれのコマンドの取り扱い≫
� セキュリティ管理機能が使いやすくなった◦ ROLEを使い分けてアクセス制御しているユーザ向け
� 新構文◦ GRANT/REVOKE ON ALL … IN SCHEMAGRANT/REVOKE ON ALL … IN SCHEMAGRANT/REVOKE ON ALL … IN SCHEMAGRANT/REVOKE ON ALL … IN SCHEMA
� 指定したスキーマ内のすべてのオブジェクトの権限を一括して譲渡する / 取り消す
◦ ALTER DEFAULT PRIVILEGESALTER DEFAULT PRIVILEGESALTER DEFAULT PRIVILEGESALTER DEFAULT PRIVILEGES FOR ROLE / IN SCHEMAFOR ROLE / IN SCHEMAFOR ROLE / IN SCHEMAFOR ROLE / IN SCHEMA◦ ALTER DEFAULT PRIVILEGESALTER DEFAULT PRIVILEGESALTER DEFAULT PRIVILEGESALTER DEFAULT PRIVILEGES FOR ROLE / IN SCHEMAFOR ROLE / IN SCHEMAFOR ROLE / IN SCHEMAFOR ROLE / IN SCHEMA
� ROLEが今後作成する / SCHEMA内に今後作られるオブジェクトのデフォルトの権限を設定する
13
8.4以前では GRANT ON ALL の代わりに PL/pgSQLでガマンFOR tbl IN SELECT tablename FROM pg_tables F LOOPEXECUTE 'GRANT SELECT ON ' || tbl || ' TO ユーザ';
END LOOP;
(DEFAULT PRIVILEGESの代わりは無い)
� EXPLAIN (ANALYZE, BUFFERS) SELECT …◦ 実行計画や処理時間と共に、バッファアクセス数も取得◦ メモリ割り当てに関連するパラメータチューニングに有用� 例1 : “shared read” が多いからshared_buffersを増やそう
� 例2 : “temp read” が多いからwork_memを増やそう
� contrib/auto_explain (8.4～)� contrib/auto_explain (8.4～)◦ 上記のEXPLAINを、スロークエリに対して自動的に行う◦ SQLの流し直しが難しい場合、スロークエリログより役立つ
� contrib/pg_stat_statements (8.4～)◦ SQLの種類 (文字列の一致) ごとに集計◦ 回数や時間 (8.4) に加え、バッファアクセス数 (9.0) も取得◦ ログを眺めず済むので楽。収集に必要なコストも低い
14
$ EDIT $PGDATA/postgresql.conf=> shared_preload_libraries = 'pg_stat_statements'
$ psql -f $PGHOME/share/contrib/pg_stat_statements.sql$ psql –c "SELECT query, round(100.0 * shared_blks_hit /(shared_blks_hit + shared_blks_read), 2) AS hitpctFROM pg_stat_statementspg_stat_statementspg_stat_statementspg_stat_statements ORDER BY shared_blks_read DESC"
クエリモードは� shared_blks_read
見どころはreadの数メモリ設定に関連
15
query | hitpct | hitpct
-------------------------+--------+--------
UPDATE pgbench_accounts | 84.92 | 87.71
INSERT INTO pgbench_his | 99.00 | 99.23
UPDATE pgbench_tellers | 99.98 | 99.95
UPDATE pgbench_branches | 99.98 | 99.98
24MB 256MBshared_buffers
$ pgbench -s10 -M prepared
クエリモードはprepared or extended
� shared_blks_read
� 共有バッファ (shared_buffers)
� local_blks_read
� 一時テーブル (temp_buffers)
� temp_blks_read
� ソート用メモリ (work_mem)
メモリ設定に関連
例
� contrib/hstore◦ {キー, 値} の配列を保持する型。いわゆるハッシュ型◦ 利用例1 : 柔軟な「正規化崩し」で検索性能UP◦ 利用例2 : 頻繁なALTER COLUMNの代わりに◦ 利用例3 : ほとんどNULLのたくさんの列を集約
=# SELECT hstore('a=>1,b=>2');hstore
� 9.0にて大幅に強化◦ サイズ制限 : 64kB → 1GB◦ 要素検索 (GiST, GIN) に加えて、全体一致検索も (btree)◦ レコード型との相互変換 (列名=値のhstore扱い)
� 次期9.1に向けて、さらにJSON型が開発中
16
hstore--------------------"a"=>"1", "b"=>"2”
� 8.4 vs. 9.0 with pgbench –S -c64 (参照系)
◦ 8.4: 11,600tps8.4: 11,600tps8.4: 11,600tps8.4: 11,600tps (-j1相当)
◦ 9.0: 52,725tps9.0: 52,725tps9.0: 52,725tps9.0: 52,725tps (-j8)
� 4.5倍のスコア! …実際にはベンチマークの差
–j<スレッド数> オプションの追加� –j<スレッド数> オプションの追加◦ これまではpgbenchがシングルスレッドだったため、処理が追い付かず、サーバに十分な負荷をかけられなかった
◦ 性能測定や高負荷試験に便利なツールとして
17
開発中のPG本体にあった、高負荷での更新処理の不具合の発見にも貢献
ユーザSQLの実行も可能
高可用性 + 参照スケールアウトが可能なレプリケーション機能のネイティブ・サポート
� ファイルサーバ (NAS) を用意◦ アーカイブログとオンライン・バックアップをNASに配置
� 利点◦ バックアップとレプリケーションを一括して設定できる
◦ 日々のバックアップを使ってスタンバイDBを追加できる
マスタDB スタンバイDB
19
マスタDB
バックアップ用ファイルサーバ
スタンバイDB
archive_commandrsync
バックアップ元
アーカイブログを直接バックアップサーバへ送る
20
archive_command= cp, scp
rsync
ベース・バックアップ
バックアップ用ファイルサーバ
rsync
必要なアーカイブログをバックアップから復元
リストア先
restore_command
21
rsync
バックアップ用ファイルサーバ
restore_command= cp, scp
バックアップとリカバリを同時に行う構成
restore_command
マスタDB スタンバイDB
22
アーカイブが届くごとにリカバリを継続する
バックアップ用ファイルサーバ
restore_command= pg_standby
primary_conninfo
マスタDBアーカイブログぶんが追いついたらそれ以降はストリーミング
参照OKrestore_command
スタンバイDB
23
バックアップ用ファイルサーバ
restore_command= cp, scp
pg_standbyではなく単なるファイルコピー
スタンバイでの参照参照参照参照
DBクラスタ全体全体全体全体の複製
非同期非同期非同期非同期での差分ログ転送
複数複数複数複数のスタンバイサーバ
スタンバイでの更新更新更新更新
複製データの選択選択選択選択
同期同期同期同期での差分ログ転送
スタンバイのカスケードカスケードカスケードカスケード構成
できる できない
複数複数複数複数のスタンバイサーバ
すべてすべてすべてすべてののののSQLSQLSQLSQL
ノードの停止停止停止停止////再開再開再開再開
手動手動手動手動フェイルオーバー
スタンバイの追加、削除追加、削除追加、削除追加、削除
スタンバイのカスケードカスケードカスケードカスケード構成
スレーブでの一時テーブル一時テーブル一時テーブル一時テーブル
(ソート用一時ファイルはOK)
自動自動自動自動フェイルオーバー
再構築無しの再組込再組込再組込再組込は困難
24
停止①
空のファイルシステム
リストア
スタンバイの停止/再開は自由リストアは最初だけ
ベースバックアップ
25
trigger_file スタンバイ通常運用
pg_ctl stop
pg_ctl startstandby_mode = ‘on’pg_ctl stop
停止② いったん通常運用に入るとスタンバイには戻せない
pg_ctl startstandby_mode = ‘off’
外部からトリガを与えてマスタに昇格 (フェイルオーバー)
� EDIT $PGDATA1/postgresql.conf� EDIT $PGDATA1/pg_hba.conf� pg_ctl start -D $PGDATA1� SELECT pg_start_backup(‘label’)� rsync など (ベース・バックアップ)
� SELECT pg_stop_backup()
wal_level = hot_standbyarchive_mode = onarchive_command = 'cp %p /arclog/%f'max_wal_senders = 1
rsync -av –delete--exclude=pg_xlog --exclude=postmaster.pid$PGDATA1/* $BACKUP/pgdata
host replication postgres ::1/128 trust
マスタ
� rsync など (ベース・バックアップ復元)
◦ mkdir $PGDATA2/pg_xlog� EDIT $PGDATA2/postgresql.conf� EDIT $PGDATA2/recovery.conf� pg_ctl start -D $PGDATA2
26
$PGDATA1/* $BACKUP/pgdata
hot_standby = on
restore_command = 'cp /arclog/%f %p'standby_mode = 'on'primary_conninfo = 'host=::1/128'
スタンバイ
� リプレイが必要なWALの “量” で遅れ具合がわかる◦ マスタ：どこまでWALを作成したか?� ① pg_current_xlog_location()
◦ スタンバイ：どこまでWALを受け取った / リプレイした� ② pg_last_xlog_receive_location()
� ③ pg_last_xlog_replay_location()
遅れの計算� 遅れの計算◦ 送信遅れ : ① － ②◦ リプレイ遅れ : ① － ③� 遅れの時間は時間当たりのWAL生成量から別途計算する
� 面倒な手順が必要なので、改善していきたいところ �
◦ pgpool-II 3.0 の機能を利用する手も
27
引き算の仕方に工夫が要る(単純な整数ではないため)
� PostgreSQLコアには無いが、pgpoolが対応予定� pgpool-II 3.0 新機能◦ マスタ=スレーブモードが9.0レプリケーション対応◦ トランザクション内のSELECTもロードバランス◦ 拡張プロトコル (特にJDBC) のクエリも適切に振り分け◦ スレーブの遅延をチェック。遅れすぎたら振り分けを手加減◦ クライアントアプリにエラーを返すノードを切り離し◦ クライアントアプリにエラーを返すノードを切り離し◦ レプリケーションを利用したオンライン・リカバリ
28
• PostgreSQL本体 = データのレプリケーション• Pgpool = クエリの振り分け, ノード管理
マスタDB
スタンバイDBpgpool
App
役割分担
� A. 公式には、スタンバイのすべてのデータを捨てて、ベースバックアップからやり直してください。
� A. 非公式ですが、recovery.conf にて、タイムラインを明記することで復帰できることを確認しています。◦ 新マスタでの timeline の調べ方� pg_controldata
� Latest checkpoint‘s TimeLineID (最終チェックポイントの時系列ID)� Latest checkpoint‘s TimeLineID (最終チェックポイントの時系列ID)
� 使用中のWALセグメントファイル名の左から8桁� select
substring(pg_xlogfile_name(pg_current_xlog_location()), 1, 8)::integer;
◦ $EDIT recovery.conf� primary_conninfoprimary_conninfoprimary_conninfoprimary_conninfo = '<new-master>’
� recovery_target_timelinerecovery_target_timelinerecovery_target_timelinerecovery_target_timeline = '<TL>'
� standby_mode = 'on'
29
� PostgreSQL “9.0” は開発者からの“ぜひ使って欲しい” というメッセージ◦ レプリケーションを初め、数多くの機能強化
◦ その他の機能紹介は “Let’s Postgres” にて
� http://lets.postgresql.jp/documents/technical/9.0/1
� 組み込みのレプリケーションが採用された◦ SQL制約、遅延、性能オーバーヘッドの少ない方式
◦ マスタ=スタンバイ レプリケーションの決定版！
31
単独マスタ
複数スタンバイ
� PostgreSQL 9.1 Alpha 1 (2010.9.7)
◦ NUMERIC型のディスクサイズがコンパクトに
◦ GROUP BYの制限が緩めに (MySQL風)
◦ VACUUM, ANALYZEの回数が統計情報に追加
◦ 文字列関数: concat, concat_ws, left, right, reverse
◦ XML関数: xmlexists, xpath_exists, xml_is_well_formed
� その他にも続々と新機能が開発中
◦ 同期レプリケーション (Semi-Synchronous)
◦ MERGE (≒ REPLACE, INSERT ON DUPLICATE KEY UPDATE)
◦ JSON型, JSONを扱う関数
◦ クエリの進捗表示
32
1年後 (2011/初秋) をお楽しみに!
PostgreSQL 9.0 を楽しんでください！