More Related Content Similar to 20171028 osc-nagaoka-postgre sql-10 (20) More from Toshi Harada (20) 7. 7
MySQL と並ぶ OSS DBMS
ライセンスは BSD ライクなもの
高度なクエリにも対応
性能面でも商用 DBMS とも遜色なし
9.0 以降はレプリケーションも対応
非常に高い拡張性
20 年以上の長い歴史
活発な開発コミュニティ
10. 10
postgres=# SELECT * FROM pg_banner('PostgreSQL 10');
data
---------------------------------------------------------------------------------------------------
###### ####### ##### ####### ##### ###### ####### ##### ##### # # ####
# # # # # # # # # # # # # # # # # ## # ##
# # # # # # # # # # # # # # # # # # #
###### # # ##### # # #### ###### ##### ##### # # # # # # #
# # # # # # # # # # # # # # # # ## #
# # # # # # # # # # # # # # # # # # #
# ####### ##### # ##### # # ####### ##### #### # ####### ##### ####
(7 rows)
postgres=# SELECT * FROM pg_banner('Release!');
data
---------------------------------------------------------------
###### ####### # ####### # ##### ####### ###
# # # # # # # # # # ###
# # # # # # # # # ###
###### ##### # ##### # # ##### ##### #
# # # # # ####### # #
# # # # # # # # # # ###
# # ####### ####### ####### # # ##### ####### ###
(7 rows)
PostgreSQL 10 Release!
https://github.com/nuko-yokohama/pg_scripts
20. 20
Logical Replication のイメージ
Logical Replication
Replication Slot
WAL
テーブル
レプリケーション用
標準プラグイン
(pgoutput)
論理
ログ
サブスクライバ
PostgreSQL
更新
PUBLICATION 定義
SUBSCRIPTION 定義
Logical Decoding の基盤を使って、
PostgreSQL 間のレプリケーション専用に
使いやすくした、というイメージ
21. 21
Logical Replication の基本パターン 1
あるテーブルのみを複製する
Logical Replication
PostgreSQL server (srv2)
(port=10002)
tokyo DBkanagawa DB
machida table machida table
SUBSCRIPTION
sub_kanagawa_machida
PUBLICATION
pub_kanagawa_machida
client
PostgreSQL server (srv1)
(port=10001)
Replication
Protocol
yokohama table
接続
23. 23
postgresql.conf の設定
wal_level = logical
max_wal_senders = 10 # 0 より大きい数
max_replication_slots = 10 # 0 より大きい数
PUBLICATION を設定する上流側サーバ
のみ設定しておけば OK.
PostgreSQL 10 からは max_wal_senders や
max_replication_slots のデフォルトが 0 でなくなったの
で、少し設定が楽に。
Logical Replication
24. 24
pg_hba.conf の設定
通常の Streaming Replication 用設定と同じで OK.
レプリケーション専用ユーザを使う場合には、別途レプリ
ケーション権限をもつユーザを作成しておく必要がある。
Logical Replication
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication postgres trust
この例では postgres ユーザで
接続してるけど、実用時には
レプリケーション専用ユーザを
作ることを推奨します。
25. 25
データベース / テーブルの作成
Logical Replication はデータベース単
位に設定する（重要！）
複製先に Logical Replication 対象の
テーブルを持つデータベースがなけれ
ば作成する。
Logical Replication
30. 30
Logical Replication の設定例
テーブルの作成
Logical Replication
psql -p 5432 -U postgres kanagawa -c "CREATE TABLE machida(id int
primary key, pref text, data text)"
psql -p 5432 -U postgres kanagawa -c "CREATE TABLE yokohama(id int
primary key, pref text, data text)"
psql -p 5433 -U postgres tokyo -c "CREATE TABLE machida(id int
primary key, pref text, data text)"
PUBLICATION を srv1 の kanagawa DB に作成
対象は machida テーブルのみ
psql -p 5432 -U postgres kanagawa -c "CREATE PUBLICATION pub_kanagawa_m
achida FOR TABLE machida"
SUBSCRIPTION を srv2 の tokyo DB に作成
psql -p 5433 -U postgres tokyo -c "CREATE SUBSCRIPTION sub_kanagawa_
machida CONNECTION 'dbname=kanagawa port=5432 user=postgres'
PUBLICATION pub_kanagawa_machida"
31. 31
Logical Replication の基本パターン 1
（再掲）
Logical Replication
PostgreSQL server (srv2)
(port=10002)
tokyo DBkanagawa DB
machida table machida table
SUBSCRIPTION
sub_kanagawa_machida
PUBLICATION
pub_kanagawa_machida
client
PostgreSQL server (srv1)
(port=10001)
Replication
Protocol
yokohama table
“ ”パブリッシャー と呼ぶ “ ”サブスクライバ と呼ぶ
接続
32. 32
設定の確認方法
srv1 の kanagawa DB に接続。
psql メタコマンド dRp で PUBLICATION を確認
Logical Replication
kanagawa=# dRp
List of publications
Name | Owner | All tables | Inserts | Updates | Deletes
----------------------+----------+------------+---------+---------+---------
pub_kanagawa_machida | postgres | f | t | t | t
srv2 の tokyo DB に接続
psql メタコマンド dRs で SUBSCRIPTION を確認
tokyo=# dRs
List of subscriptions
Name | Owner | Enabled | Publication
----------------------+----------+---------+------------------------
sub_kanagawa_machida | postgres | t | {pub_kanagawa_machida}
33. 33
レプリケーションの例 ( 挿入 )
パブリッシャー (srv1) の kanagawa DB にログイン
machida テーブルに挿入し、直後に検索
Logical Replication
psql -p 10001 -U postgres kanagawa -c "INSERT INTO machida VALUES (1, 'kanagawa',
'Naruse'),(2, 'kanagawa', 'Machida')"
INSERT 0 2
psql -p 10001 -U postgres kanagawa -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
サブスクライバ (srv2) の tokyo DB に接続
machida テーブルに挿入内容が伝播している。
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
レプリケーション成功！
34. 34
レプリケーションの例 ( 更新と削除 )
パブリッシャー (srv1) の kanagawa DB にログイン
machida テーブルへ更新 / 削除して、直後に検索
Logical Replication
psql -p 10001 -U postgres kanagawa -c "UPDATE machida SET data='Nyaruse' WHERE id = 1"
UPDATE 1
psql -p 10001 -U postgres kanagawa -c "DELETE FROM machida WHERE id=2"
DELETE 1
psql -p 10001 -U postgres kanagawa -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Nyaruse
サブスクライバ (srv2) 側にも
更新 / 削除内容が伝播している。
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Nyaruse
35. 35
レプリケーションされない例
パブリッシャー (srv1) の kanagawa DB にログイン
machida テーブルを TRUNCATE し、直後に検索
Logical Replication
psql -p 10001 -U postgres kanagawa -c "TRUNCATE machida"
TRUNCATE TABLE
psql -p 10001 -U postgres kanagawa -c "TABLE machida"
id | pref | data
----+------+------
(0 rows)
サブスクライバ (srv2) 側は・・・
TRUNCATE されていない！
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Nyaruse
(1 row)
現状、 Logical Replication では TRUNCATE は未対応！
37. 37
Logical Replication の Conflict
Logical Replication
PostgreSQL server (srv2)
(port=10002)
tokyo DBkanagawa DB
machida table machida table
SUBSCRIPTION
sub_kanagawa_machida
PUBLICATION
pub_kanagawa_machida
client
PostgreSQL server (srv1)
(port=10001)
Replication
Protocol
yokohama table
“ ”パブリッシャー と呼ぶ “ ”サブスクライバ と呼ぶ
key=x のレコードを
先に挿入
key=x のレコードを
後で挿入
接続
38. 38
INSERT の Conflict 例
srv1 と srv2 の machida テーブルが同期している状態
Logical Replication
psql -p 10001 -U postgres kanagawa -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
この状態で srv2 の machida テーブルに id=3 のレコード
を先に挿入しておく
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
psql -p 10002 -U postgres tokyo -c "INSERT INTO machida VALUES (3, 'tokyo',
'Kobuchi')"
INSERT 0 1
To be continued
39. 39
INSERT の Conflict 例
srv1 に id=3 のレコードを挿入すると・・・
Logical Replication
psql -p 10001 -U postgres kanagawa -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
3 | kanagawa | Kobuchi
この状態で srv1 と srv2 の machida テーブルを参照する
とこうなる。
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
3 | tokyo | Kobuchi
psql -p 5432 -U postgres kanagawa -c "INSERT INTO machida VALUES (3, 'kanagawa',
'Kobuchi')"
INSERT 0 1
psql -p 10001 -U postgres kanagawa -c "INSERT INTO machida VALUES (3, 'kanagawa',
'Kobuchi')"
INSERT 0 1
ConfilictConfilict
発生！発生！
Conflict が発生すると、
以降、このサブスクライバに対する
更新伝播が止まってしまう・・・
40. 40
INSERT の Conflict 発生時のログ
パブリッシャー側のサーバログ
Logical Replication
2017-10-27 13:52:52.544 JST [12522] LOG: logical decoding found consistent point at
0/16646D8
2017-10-27 13:52:52.544 JST [12522] DETAIL: There are no running transactions.
2017-10-27 13:52:57.558 JST [12524] LOG: starting logical decoding for slot
"sub_kanagawa_machida"
2017-10-27 13:52:57.558 JST [12524] DETAIL: streaming transactions committing after
0/1664710, reading WAL from 0/16646D8
2017-10-27 13:55:13.006 JST [12636] LOG: logical replication apply worker for
subscription "sub_kanagawa_machida" has started
2017-10-27 13:55:13.011 JST [12636] ERROR: duplicate key value violates unique
constraint "machida_pkey"
2017-10-27 13:55:13.011 JST [12636] DETAIL: Key (id)=(3) already exists.
2017-10-27 13:55:13.012 JST [7851] LOG: worker process: logical replication worker
for subscription 16395 (PID 12636) exited with exit code 1
サブスクライバ側のサーバログ
42. 42
解決方法は 2 つある。
Logical Replication
https://www.postgresql.org/docs/current/static/logical-replication-conflicts.html
サブスクライバのデータを着信変更と競合しないように変更するか、既存のデー
タと競合するトランザクションをスキップすることによって解決できます。
サブスクライバの
データを変更
競合する
トランザクションを
スキップ
43. 43
サブスクライバのデータを変更
srv2 側の id=3 のレコードを削除する。
Logical Replication
psql -p 10002 -U postgres tokyo -c "DELETE FROM machida WHERE id=3"
DELETE 1
しばらくすると、 srv1 側に挿入された id=3 レコードが
反映される。
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
psql -p 10002 -U postgres tokyo -c "TABLE machida"
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
3 | kanagawa | Kobuchi
削除直後に参照すると id=3 のレコードは消えているが
46. 46
サブスクライバの pg_replication_origin_status を確認
Logical Replication
tokyo=# TABLE pg_replication_origin_status ;
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
1 | pg_16395 | 0/16646D8 | 0/1656650
パブリッシャーの pg_current_wal_lsn() を確認
kanagawa=# SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
0/16648E8
サブスクライバ上で pg_replication_origin_advance() を実行
第 1 引数には external_id を指定
第 2 引数には pg_current_wal_lsn() の値を指定
tokyo=# SELECT pg_replication_origin_advance('pg_16395', '0/16648E8');
pg_replication_origin_advance
-------------------------------
To be continued
47. 47
Confilict 状態からは抜け出せるが、パブリッシャー側の更新
もサブスクライブ側の更新もされたままである。
Logical Replication
kanagawa=# TABLE machida;
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
2 | kanagawa | Machida
3 | kanagawa | Kobuchi
tokyo=# TABLE machida;
id | pref | data
----+----------+---------
1 | kanagawa | Naruse
3 | tokyo | Kobuchi
2 | kanagawa | Machida
あくまでも Conflict 状態でなくなった ( 以降のレプリケー
ションを受け付けるようになった）だけ！
パブリッシャー側で id=3 のレコードに UPDATE かければ
データ上も同期はされる。
48. 48
そもそも Conflict しているかってどう
判断するのか？
Logical Replication
以下の SQL をパブリッシャーで発行する（たぶん）。
サブスクライバ側のサーバログに Conflict 原因のログが
出力されている。
ERROR: duplicate key value violates unique constraint "machida_pkey"
DETAIL: Key (id)=(3) already exists.
SELECT
(SELECT confirmed_flush_lsn FROM pg_replication_slots) =
pg_current_wal_lsn();
true なら Conflict していない。
false なら Conflict している。 Conflict の判断というより
最新状態に追いついているか
という判断方法かな
50. 50
異なる構造間の Logical Replication
Logical Replication は以下のようなテーブルの差異があっ
ても複製は可能。
列定義の順番が異なっていても OK 。
複製先テーブルには、複製元にない列があっても OK
（ null 可列の場合）
ただし、複製テーブルには、複製元の列が全てなくてはい
けない。ややこしい。
Logical Replication
51. 51
異なる構造間の Logical Replication
Logical Replication
列 A 列 B 列 C
AAA BBB CCC
複製元
列 C 列 B 列 A
CCC BBB AAA
複製先
列 A 列 B 列 C
AAA BBB CCC
複製元
列 A 列 B 列 C 列 X
AAA BBB CCC (null)
複製先
列 A 列 B 列 C
AAA BBB CCC
複製元
列 A 列 B
AAA BBB
複製先
52. 52
異文字コード間の Logical Replication
4/7? に Fix されたみたい。
バグレポした篠田さん＠ HPE 、
そして修正した堀口さん＠ NTT 、 GJ ！
この手の問題は英語圏の人は積極的に対応しない・・・。
https://postgresql-jp.slack.com/archives/C0AM4GZC0/p149154729244
3787
Logical Replication
Logical Replication の文字コード変換問題、修正モジュールがコミットされました。
UTF-8 から EUC_JP への変換も確認できました。堀口さん、ありがとうございました。
https://www.postgresql.org/message-id/20170407.100555.17227106.horiguchi.kyotar
o@lab.ntt.co.jp
55. 55
異バージョン間複製
ex. PostgreSQL 10 と PostgreSQL 11 間での複製
Logical Replication
PostgreSQL 11 server (srv2)
PG11
DB クラスタ
PG10
DB クラスタ
全 DB 全 DB
PostgreSQL 10 server (srv1)
更新
操作
Logical
Replication
PG10
DB クラスタ
全 DB
PostgreSQL 10 server (srv2)
Physical
Replication
pg_upgrade
PostgreSQL 11-devel が
使えるようになったら
試さねば・・・
56. 56
異アーキテクチャ間複製
Linux 版と Windows 版との間の複製もできるはず。
Logical Replication
PostgreSQL 10 serve
PG10
DB クラスタ
PG10
DB クラスタ
全 DB 全 DB
PostgreSQL 10 server
更新
操作
Logical
Replication
58. 58
Streaming vs Logical
Logical Replication
観点 Streaming Replication Logical Replication
複製範囲 データベースクラスタ全体 特定の DB/ 表も選択可能
複製対象の操作 DML(TRUNCATE 含む ),
DDL
DML(TRUNCATE 除く )
同期方式 同期または非同期 非同期
用途 高可用化 部分的な複製
異バージョン / 異アーキテクチャ
間複製
用途に合わせて選定しよう。
（私見） Logical Replication は実装されたばかり。
品質面でのリスクは覚悟しておくべきか。
Streaming Replication との併存も可能だと思う（未検証）
61. 61
Oracle, DB2 などの商用 DBMS では
DDL 構文として、パーティションが
サポートされていた。
PostgreSQL の従来のパーティションは
いわば「なんちゃってパーティション」
Declarative Partitioning
62. 62
PostgreSQL 10 新機能
CREATE TABLE 文の拡張によりパー
ティションテーブルの定義が可能に。
INSERT トリガ定義不要に！
しかも INSERT が高速化！
制約矛盾もある程度チェック可能！
Declarative Partitioning
64. 64
CREATE TABLE 構文
親テーブル側
Declarative Partitioning
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT
EXISTS ] table_name ( [
{ column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ]
| table_constraint
| LIKE source_table [ like_option ... ] }
[, ... ]
] )
[ INHERITS ( parent_table [, ... ] ) ]
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) } [ COLLATE
collation ] [ opclass ] [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]
65. 65
CREATE TABLE 構文
子テーブル側
Declarative Partitioning
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ]
table_name
PARTITION OF parent_table [ (
{ column_name [ column_constraint [ ... ] ]
| table_constraint }
[, ... ]
) ] FOR VALUES partition_bound_spec
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) } [ COLLATE
collation ] [ opclass ] [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]
子テーブルでも PARTITION BY 可能
つまり、多段パーティション定義が可能！
67. 67
従来の定義方式
親テーブルの定義。
Declarative Partitioning
CREATE TABLE japan (
pref text,
city text,
data text
);
CREATE TABLE tokyo (
CHECK (pref IN (' 東京 '))
) INHERITS (japan);
CREATE TABLE kanagawa (
CHECK (pref IN (' 神奈川 '))
) INHERITS (japan);
CREATE TABLE shizuoka (
CHECK (pref IN (' 静岡 '))
) INHERITS (japan);
子テーブルの定義
To be continued
68. 68
従来の定義方式（つづき）
トリガ関数の定義
Declarative Partitioning
CREATE OR REPLACE FUNCTION pref_insert_trigger_func()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW.pref = ' 東京 ') THEN
INSERT INTO tokyo VALUES (NEW.*);
ELSIF ( NEW.pref = ' 神奈川 ') THEN
INSERT INTO kanagawa VALUES (NEW.*);
ELSIF ( NEW.pref = ' 静岡 ') THEN
INSERT INTO shizuoka VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'Date out of range. Fix the pref_insert_trigger()
function!';
END IF;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;
To be continued
71. 71
PostgreSQL 10 の定義方式
親テーブルの定義。
Declarative Partitioning
CREATE TABLE japan (
pref text,
city text,
data text
)
PARTITION BY LIST (pref);
CREATE TABLE tokyo PARTITION OF japan
FOR VALUES IN (' 東京 ');
CREATE TABLE kanagawa PARTITION OF japan
FOR VALUES IN (' 神奈川 ');
CREATE TABLE shizuoka PARTITION OF japan
FOR VALUES IN (' 静岡 ');
子テーブルの定義
これだけで完了！ ( レンジパーティションもだいたい同じ）
74. 74
多段パーティションの定義例
親テーブルの定義。
Declarative Partitioning
CREATE TABLE japan (
pref text,
city text,
data text
)
PARTITION BY LIST (pref);
CREATE TABLE tokyo PARTITION OF japan
FOR VALUES IN (' 東京 ');
CREATE TABLE kanagawa PARTITION OF japan
FOR VALUES IN (' 神奈川 ')
PARTITION BY LIST (city);
CREATE TABLE shizuoka PARTITION OF japan
FOR VALUES IN (' 静岡 ');
子テーブルの定義
これだけで完了！
CREATE TABLE "kanagawa.yokohama"
PARTITION OF kanagawa
FOR VALUES IN (' 横浜 ');
CREATE TABLE "kanagawa.kawasaki"
PARTITION OF kanagawa
FOR VALUES IN (' 川崎 ');
CREATE TABLE "kanagawa.machida"
PARTITION OF kanagawa
FOR VALUES IN (' 町田 ');
孫テーブルの定義
76. 76
パーティション状態の確認
親テーブルの確認
Declarative Partitioning
partition=# d+ japan
Table "public.japan"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition key: LIST (pref)
Partitions: kanagawa FOR VALUES IN (' 神奈川 '),
shizuoka FOR VALUES IN (' 静岡 '),
tokyo FOR VALUES IN (' 東京 ')
パーティション種別とキーを表示してくれる。
子テーブルとパーティションキー値を表示してくれる。
77. 77
パーティション状態の確認
子テーブルの確認
Declarative Partitioning
partition=# d+ kanagawa
Table "public.kanagawa"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition of: japan FOR VALUES IN (' 神奈川 ')
Partition constraint: ((pref IS NOT NULL) AND (pref = ANY (ARRAY[' 神奈川 '::text])))
所属する親テーブルと、パーティションキー値、制約条件
を表示してくれる。
78. 78
パーティションキー重複のチェック
Declarative Partitioning
partition=# d+ japan
Table "public.japan"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition key: LIST (pref)
Partitions: kanagawa FOR VALUES IN (' 神奈川 '),
shizuoka FOR VALUES IN (' 静岡 '),
tokyo FOR VALUES IN (' 東京 ')
partition=# CREATE TABLE kanagawa2 PARTITION OF japan FOR VALUES IN (' 神奈川 ');
ERROR: partition "kanagawa2" would overlap partition "kanagawa"
パーティションキーの重複を検知してエラーにする。
80. 80
パーティションの切り離し
切り離し前
Declarative Partitioning
part=# d+ japan
Table "public.japan"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition key: LIST (pref)
Partitions: kanagawa FOR VALUES IN (' 神奈川 '),
shizuoka FOR VALUES IN (' 静岡 '),
tokyo FOR VALUES IN (' 東京 ')
ALTER TABLE ... DETACH コマンドで切り離し。
part=# ALTER TABLE japan DETACH PARTITION shizuoka ;
ALTER TABLE
81. 81
パーティションの切り離し
切り離し後
Declarative Partitioning
part=# d+ japan
Table "public.japan"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition key: LIST (pref)
Partitions: kanagawa FOR VALUES IN (' 神奈川 '),
tokyo FOR VALUES IN (' 東京 ')
切り離されたので静岡は検索されない。
part=# SELECT * FROM japan WHERE pref = ' 静岡 ';
pref | city | data
------+------+------
(0 rows)
82. 82
パーティションの組み込み
組み込み前
Declarative Partitioning
part=# d+ japan
Table "public.japan"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition key: LIST (pref)
Partitions: kanagawa FOR VALUES IN (' 神奈川 '),
tokyo FOR VALUES IN (' 東京 ')
ALTER TABLE ... ATTACH コマンドで組み込み。
part=# ALTER TABLE japan ATTACH PARTITION shizuoka FOR VALUES IN (' 静岡 ');
ALTER TABLE
組み込み時にはパーティションテーブルと制約を指定。
83. 83
パーティションの組み込み
組み込み後
Declarative Partitioning
part=# d+ japan
Table "public.japan"
Column | Type | Collation | Nullable | Default | Storage | Stats target |
Description
--------+------+-----------+----------+---------+----------+--------------
+-------------
pref | text | | | | extended | |
city | text | | | | extended | |
data | text | | | | extended | |
Partition key: LIST (pref)
Partitions: kanagawa FOR VALUES IN (' 神奈川 '),
shizuoka FOR VALUES IN (' 静岡 '),
tokyo FOR VALUES IN (' 東京 ')
条件が静岡の行が選択されるようになった。
part=# SELECT * FROM japan WHERE pref = ' 静岡 ';
pref | city | data
------+--------+----------
静岡 | 熱海市 | 雨風本舗
静岡 | 下田市 | 一品香
(2 rows)
88. 88
パーティションキーがない場合
Declarative Partitioning
partition=# EXPLAIN SELECT * FROM japan ;
QUERY PLAN
-----------------------------------------------------------------------------
Append (cost=0.00..82.50 rows=3250 width=96)
-> Seq Scan on tokyo (cost=0.00..16.50 rows=650 width=96)
-> Seq Scan on shizuoka (cost=0.00..16.50 rows=650 width=96)
-> Seq Scan on "kanagawa.yokohama" (cost=0.00..16.50 rows=650 width=96)
-> Seq Scan on "kanagawa.kawasaki" (cost=0.00..16.50 rows=650 width=96)
-> Seq Scan on "kanagawa.machida" (cost=0.00..16.50 rows=650 width=96)
(6 rows)
パーティションキーがないので、全ての子 / 孫パーティショ
ンを検索する実行計画になる。
89. 89
都道府県と市を条件に指定した場合
Declarative Partitioning
partition=# EXPLAIN SELECT * FROM japan WHERE pref = ' 神奈川 ' AND city = ' 町田 ';
QUERY PLAN
--------------------------------------------------------------------------
Append (cost=0.00..19.75 rows=1 width=96)
-> Seq Scan on "kanagawa.machida" (cost=0.00..19.75 rows=1 width=96)
Filter: ((pref = ' 神奈川 '::text) AND (city = ' 町田 '::text))
(3 rows)
この場合は pref が神奈川、 city が町田の子テーブル
(kanagawa.machida) の孫テーブルのみにアクセスする
実行計画になる。
91. 91
パーティション間更新の制約
パーティションキーを変更するような UPDATE はエラー
になる。→ hackers-ml でも議論中
変更後の値のパーティションテーブルに挿入するわけでは
なく、元のパーティションテーブルに挿入しようとして、
制約違反になる。
Declarative Partitioning
To be continued
partition=# SELECT * FROM japan WHERE id = 6;
id | pref | city | data
----+--------+------+--------
6 | 神奈川 | 町田 | 竹の助
(1 row)
partition=# UPDATE japan SET pref = ' 東京 ' WHERE id = 6;
ERROR: new row for relation "kanagawa.machida" violates partition constraint
DETAIL: Failing row contains (6, 東京 , 町田 , 竹の助 ).
92. 92
パーティション間更新の制約
代替手段として、 DELETE→INSERT する必要がある。
Declarative Partitioning
To be continued
partition=# SELECT * FROM japan WHERE id = 6;
id | pref | city | data
----+--------+------+--------
6 | 神奈川 | 町田 | 竹の助
(1 row)
partition=# BEGIN;
BEGIN
partition=# DELETE FROM japan WHERE id = 6;
DELETE 1
partition=# INSERT INTO japan VALUES (6, ' 東京 ', ' 町田 ', ' 竹の助 ');
INSERT 0 1
partition=# COMMIT;
COMMIT
partition=# SELECT * FROM japan WHERE id = 6;
id | pref | city | data
----+------+------+--------
6 | 東京 | 町田 | 竹の助
(1 row)
93. 93
パーティション間更新の制約
RETURNING 句を使って 1 つのクエリにすることも可能
Declarative Partitioning
partition=# SELECT * FROM japan WHERE id = 6;
id | pref | city | data
----+--------+------+--------
6 | 神奈川 | 町田 | 竹の助
(1 row)
partition=# WITH tmp AS
(DELETE FROM japan WHERE id = 6 RETURNING id, ' 東京 ', city, data)
INSERT INTO japan SELECT * FROM tmp;
INSERT 0 1
partition=# SELECT * FROM japan WHERE id = 6;
id | pref | city | data
----+------+------+--------
6 | 東京 | 町田 | 竹の助
(1 row)
ぐぬぬ・・・
町田は東京に奪われました
94. 94
インデックス関連の制約
パーティションの親テーブルには Primary key が設定でき
ない！
Declarative Partitioning
partition=# CREATE TABLE japan (
id integer primary key,
pref text,
city text,
data text
)
PARTITION BY LIST (pref);
ERROR: primary key constraints are not supported on partitioned tables
LINE 2: id integer primary key,
^
To be continued
95. 95
インデックス関連の制約
子テーブルを持つテーブルにはインデックスが作成できない。
Declarative Partitioning
partition=# d japan
Table "public.japan"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
id | integer | | |
pref | text | | |
city | text | | |
data | text | | |
Partition key: LIST (pref)
Number of partitions: 3 (Use d+ to list them.)
partition=# CREATE INDEX japan_id ON japan USING btree (id);
ERROR: cannot create index on partitioned table "japan"
親テーブルにインデックス設定したら、子テーブルに自動的に
伝播してくれればいいのになあ、とも思う・・・。
98. 98
GUC の差分
Parallel Query の改善
バージョン番号体系
データベースクラスタ内の名称変更
psql スクリプト内で if 制御
synchronous_standby_names
pg_hba.conf のビュー
ハッシュインデックス改善
Others
99. 99
今回も結構 GUC の差分は多いです。
9.6 と 10 .0 の初期設定の dif をとって調査
新機能に関連する GUC の追加、変更
初期設定値を変えなくても PostgreSQL の高度な機
能が使えるように。
レプリケーション関連
パラレルクエリ関連
その他、デフォルト値や説明の変更
GUC の差分
100. 100
GUC の差分
GUC の差分
パラメータ名 変更種別 変更内容 ぬこメモ
archive_timeout 説明変更 “xlog” → “wal”
bgwriter_lru_maxpages 最大値変更 1000 → 1073741823
enable_gathermerge 追加 パラレルクエリに関す
るプランナ制御
hot_standby デフォルト値
変更
of -> on
log_directory デフォルト値変
更
pg_log → log
log_line_prefix デフォルト値
変更
'' → '%m [%p]'
max_logical_replication_w
orkers
追加 ロジカルレプリケー
ション用のワーカ最大
数
max_parallel_workers 追加 パラレルクエリ制御
101. 101
GUC の差分
パラメータ名 変更種別 変更内容 ぬこメモ
max_parallel_workers_p
er_gather
デフォルト値
変更
max_pred_locks_per_re
lation
追加
max_replication_slots デフォルト値
変更
0 → 10
max_sync_workers_per_s
ubscription
追加
max_wal_senders デフォルト値
変更
0 → 10
max_wal_size デフォルト値
/ 単位変更
64/16MB → 1024/MB 計算上の値は 9.6 と変
更なし
102. 102
GUC の差分
パラメータ名 変更種別 変更内容 ぬこメモ
min_parallel_index_sca
n_size
追加 パラレルスキャン数決
定のためのインデック
スサイズ
min_parallel_relation_si
ze
削除 min_parallel_table_sc
an_size に名称変更
min_parallel_table_scan
_size
追加 パラレルスキャン数決
定のためのテーブルサ
イズ
min_wal_size デフォルト値
単位 / 変更
5/16MB → 80/MB 計算上の値は 9.6 と
変更なし
password_encryption 型 / デフォル
ト値変更
bool/on →
enum/md5
sql_inheritance 削除
103. 103
GUC の差分
パラメータ名 変更種別 変更内容 ぬこメモ
ssl CONTEXT 変
更
postmaster → sighup reload で SSL 通信
の on/of が可能に
ssl_ca_file
ssl_cert_file
ssl_ciphers
wal_consistency_checking 追加 bool/on
WAL 反映時のチェック
サムの有効無効。
wal_level デフォルト値
変更
replica →
hot_standby
105. 105
これまで （～ 9.6 ）
バージョン番号体系
X. Y. Z メジャーバージョン番号
X が上がるときには、大きな機能追加があった
場合（ PITR, レプリケーションなど）
マイナーバージョン番号
バグ Fix, セキュリティ Fix など
X. Z メジャーバージョン番号
機能追加
マイナーバージョン番号
バグ Fix, セキュリティ Fix など
これから （ 10 ～）
106. 106
より実態にあった名前に変更
pg_clog → pg_xact
pg_xlog が pg_wal
この影響でユーティリティ・関数名も変更されている。
pg_resetxlog→pg_resetwal
pg_xlogdump→pg_waldump
旧名のバイナリも残ってはいる
サーバログ出力先のデフォルトが変更
pg_log → log
DB クラスタ内の名称変更
pg_xlog と pg_log の名称が
紛らわしいという
議論からこうなった？
107. 107
psql スクリプト内で if,elif,else,endif を用
いた分岐が可能になった。
expression には直近の SQL 文の結果 (boolean) を gset コ
マンドを使って指定可能。
psql スクリプト内で if 制御
if expression
-- any
elif expression
-- any
else
-- any
endif
具体的な使い方は次ページ。
108. 108
pgbench 実行中なら中止する psql スクリプトの例
psql スクリプト内で if 制御
SELECT (count(*) <> 0) AS running
FROM pg_stat_activity
WHERE application_name = 'pgbench'
gset
if :running
echo "pgbench 動作中なのでスクリプトを終了します "
q
else
echo "pgbench は動作していないのでスクリプトを実行します "
endif
echo " バッチ処理を動かします（以下略） "
109. 109
9.5, 9.6, 10 で synchronous_standby_names の
記述方法が拡張されている。
synchronous_standby_names
バージョン 記法 補足
9.5 s1, s2, s3
9.6 N (s1, s2, s3)
10 [FIRST | ANY] N (s1, s2, s3) 省略時は FIRST と
解釈 (9.6 と同じ )
ANY 指定時は同期レプリケーション先記述の順序
に依存しなくなる。
複数同期に対応した HA ソリューションは・・・？
110. 110
pg_hba.conf の反映内容を参照できるビューが追加
pg_hba_rules
$ psql -U postgres -c "d pg_hba_file_rules"
View "pg_catalog.pg_hba_file_rules"
Column | Type | Collation | Nullable | Default
-------------+---------+-----------+----------+---------
line_number | integer | | |
type | text | | |
database | text[] | | |
user_name | text[] | | |
address | text | | |
netmask | text | | |
auth_method | text | | |
options | text[] | | |
error | text | | |
このビューはスーパーユーザ権限がないと参照不可。
111. 111
pg_hba.conf の内容
pg_hba_rules
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
112. 112
pg_hba.conf をリロード後に、 SELECT で検索
pg_hba_rules
$ psql -U postgres -c "SELECT type,database,user_name FROM
pg_hba_file_rules"
type | database | user_name
-------+---------------+-----------
local | {all} | {all}
host | {all} | {all}
host | {all} | {all}
local | {replication} | {all}
host | {replication} | {all}
host | {replication} | {all}
(6 rows)
このビューと、 pg_roles を結合させて、正しいロールが
pg_hba.conf に設定されているか、みたいなチェックにも
使えるかも。
113. 113
Hash Index 改善
9.6 までは WAL 出力に対応していない
今まで実質上使えなかった・・・
公式マニュアル上も非推奨扱いのインデックス
10 から WAL 出力に対応するようになった。
uuid のように = 比較しかできないデータ型の
インデックスにする場合は良さそう
インデックスサイズ削減
検索性能の若干の向上 (?)
Hash Index 改善
114. 114
Hash と B-Tree Index の比較
Hash Index 改善
Hash インデックス作成時間は長くなる。
uuid のような型の場合、インデックスサ
イズは小さくなる。
検索性能も Hash のほうが若干良いかも？
117. 117
PostgreSQL 10 は
新世代の PostgreSQL ！
様々な可能性を秘めた Logical Replication
使いやすい Delective Partition
更に進化した Parallel Query
バージョン番号体系の変更
その他いろいろな改善
122. 122
PostgreSQL 10devel Documentation
https://www.postgresql.org/docs/devel/static/index.html
Commitfest
https://commitfest.postgresql.org/
Michael Paquier - Open source developer based in Japan
http://michael.otacoo.com/
@sawada_masahiko さんの Twitter
https://twitter.com/sawada_masahiko
PostgreSQL Update 2017 ( 高塚さん )
https://www.slideshare.net/HarukaTakatsuka/postgre-sql-update20170310
postgresql-jp Slack
https://postgresql-hackers-jp.herokuapp.com/
篠田の虎の巻 7
http://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_10_New_Features_ja_20170522-1.pdf
OSC 2017 Fukuoka のスライド（花田さん）
https://www.slideshare.net/babystarmonja/postgresql-10-osc-2017-fukuoka
@fujii_masao さんの Qiita 記事
https://qiita.com/fujii_masao/items/c39e191e7ed26b141d8d
参考にしたもの
