PostgreSQLのバージョンアップの話 / PostgreSQL Version up

第25回 中国地方DB勉強会 in 鳥取の登壇資料です。
http://dbstudychugoku.github.io/

Transcript

1. PostgreSQLのバージョンアップ ~11の話もあるよ ~ 第25回 中国地方DB勉強会 in 鳥取
2. What is it? バージョンアップしてますか？
3. What is it? やり方が分からない
4. What is it? 上げてメリットあるの？
5. What is it? そんな課題・疑問にお答えします
6. あじぇんだ 1 自己紹介 2 Version upの種類とメリット 3 停止を伴うVersion up 4 停止を最小化したVersion up 5 まとめ
7. あじぇんだ 1 自己紹介 2 Version upの種類とメリット 3 停止を伴うVersion up 4 停止を最小化したVersion up 5 まとめ
8. 自己紹介 曽根 壮大（34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 • 3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も
9. 自己紹介 曽根 壮大（34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 • 3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も
10. 婚活といえばオミカレ https://party-calendar.net/
11. あじぇんだ 1 自己紹介 2 Version upの種類とメリット 3 停止を伴うVersion up 4 停止を最小化したVersion up 5 まとめ
12. Version upのメリット バージョンアップのメリット
13. Version upのメリット •新機能が使える •パフォーマンス向上する 12/22 発売のWeb+DBを読んで
14. PostgreSQLカンファレンス https://www.postgresql.jp/jpug-pgcon2018
15. PostgreSQL 11 解体新書 PostgreSQL カンファレンス 2018 https://speakerdeck.com/soudai/postgresql11-release
16. Version upのメリット 12/22 発売のWeb+DBを読んで （大事なことなので二回）
17. Version upの種類 PostgreSQLのバージョンアップ
18. Version upの種類 ざっくり4種類ある
19. Version upの種類 項目 停止時間 難易度 補足 Pg_dump/pg_restore 長い データ量に比例 簡単 全部のVersionに対応 pg_upgrade 一定時間 データ量に依存しない 簡単 8.4以降 レプリケーション 切り替え時間のみ 中程度 Versionによって違う APPの二重書込 切り替え時間のみ ??? チーム次第
20. • 自分たちの要件に合わせて選ぶ > 無理に難しい手段をとらない • 停止時間を取るほうが難易度は低い • 古いPostgreSQL(7系とか） > 選択肢が無いので停止 Version upの種類
21. • 自分たちの要件に合わせて選ぶ > 無理に難しい手段をとらない • 停止時間を取るほうが難易度は低い • 古いPostgreSQL(7系とか） > 選択肢が無いので停止 Version upの種類 後述の方法で出来なくはないけど…
22. Version upの種類 項目 停止時間 難易度 補足 Pg_dump/pg_restore 長い データ量に比例 簡単 全部のVersionに対応 pg_upgrade 一定時間 データ量に依存しない 簡単 8.4以降 レプリケーション 切り替え時間のみ 中程度 Versionによって違う APPの二重書込 切り替え時間のみ ??? チーム次第
23. Version upの種類 データが大きい場合に 色んな方法を検討します
24. Version upの種類 項目 停止時間 難易度 補足 Pg_dump/pg_restore 長い データ量に比例 簡単 全部のVersionに対応 pg_upgrade 一定時間 データ量に依存しない 簡単 8.4以降 レプリケーション 切り替え時間のみ 中程度 Versionによって違う APPの二重書込 切り替え時間のみ ??? チーム次第
25. Version upの種類 ???「止めてもらっては困る」
26. Version upの種類 ???「止めてもらっては困る」 ↓ 停止時間を短くする工夫
27. Version upの種類 項目 停止時間 難易度 補足 Pg_dump/pg_restore 長い データ量に比例 簡単 全部のVersionに対応 pg_upgrade 一定時間 データ量に依存しない 簡単 8.4以降 レプリケーション 切り替え時間のみ 中程度 Versionによって違う APPの二重書込 切り替え時間のみ ??? チーム次第
28. Version upの種類 要件が整理できたところで 具体的な手法を見ていきます
29. あじぇんだ 1 自己紹介 2 Version upの種類とメリット 3 停止を伴うVersion up 4 停止を最小化したVersion up 5 まとめ
30. 停止を伴うバージョンアップ 長時間の停止を伴う
31. Version upの種類 項目 停止時間 難易度 補足 Pg_dump/pg_restore 長い データ量に比例 簡単 全部のVersionに対応 pg_upgrade 一定時間 データ量に依存しない 簡単 8.4以降 レプリケーション 切り替え時間のみ 中程度 Versionによって違う APPの二重書込 切り替え時間のみ ??? チームs次第
32. 停止を伴うバージョンアップ pg_dump/pg_restoreが基本
33. 停止を伴うバージョンアップ pg_dump/pg_restoreが基本 ↓ バックアップ、リストアをする
34. 停止を伴うバージョンアップ • プレーンテキスト形式（SQL） • カスタムアーカイブ形式（圧縮したバイナリ） • ディレクトリ形式（表単位の圧縮したバイナリ） • TAR形式（表単位のバイナリ） pg_dumpの種類
35. 停止を伴うバージョンアップ • プレーンテキスト形式（SQL） • カスタムアーカイブ形式（圧縮したバイナリ） • ディレクトリ形式（表単位の圧縮したバイナリ） • TAR形式（表単位のバイナリ） pg_dumpの種類 オススメ！
36. pg_dump/pg_restore // -Fc カスタムアーカイブ形式 // -f は出力先 $ pg_dump –Fc データベース名 –U ユーザ名 ¥ –h ホスト名 –f /tmp/db.dump // リストア方法 $ pg_restore -d データベース名 /tmp/db.dump
37. 停止を伴うバージョンアップ これだけ！！
38. 停止を伴うバージョンアップ 質問 「pg_dumpallじゃだめですか？」
39. 停止を伴うバージョンアップ 回答 全DB移行するならそっち
40. 停止を伴うバージョンアップ pg_dumpallは内部的に pg_dumpをまとめてるだけ
41. 停止を伴うバージョンアップ 注意点 postgresql.conf 等は 自分で設定が必要
42. 停止を伴うバージョンアップ Webサーバ pg_dump pg_dumpの前に接続を停止する 旧DB クライアント 新DB
43. 停止を伴うバージョンアップ Webサーバ pg_restoreが終わったら切り替える 旧DB クライアント 新DB pg_restore
44. 停止を伴うバージョンアップ • Versionを一気に上げられる • pg_dump/pg_restoreを事前に試せる スケジュールが調整しやすい • ロールバックが簡単（旧DBにつなぎ直すだけ） • ステージング等で試しやすい この方式のメリット
45. 停止を伴うバージョンアップ • データ量が増えれば増えるほど時間がかかる • 停止は必須 • 移行用のインスタンスやサーバが必要 この方式のデメリット
46. 停止を伴うバージョンアップ • データ量が増えれば増えるほど時間がかかる • 停止は必須 • 移行用のインスタンスやサーバが必要 この方式のデメリット dumpファイルが数十GBを 超えてくると厳しい
47. 停止を伴うバージョンアップ pg_upgrade
48. 停止を伴うバージョンアップ pg_upgrade ↓ 使用中のDBクラスタを そのまま新しいバージョンにする
49. 停止を伴うバージョンアップ PostgreSQL 8.4以降、データファイルの構造が変更さ れていないため、pg_upgradeはテーブルやインデックス の再構築をしません。 制御ファイルやシステムカタログなどを修正して バージョンアップするため、手順としてもシンプルです。
50. 停止を伴うバージョンアップ Webサーバ pg_upgrade 接続を停止する 旧DB クライアント
51. 停止を伴うバージョンアップ Webサーバ 新DB クライアント Upgradeできたら接続を再開
52. 停止を伴うバージョンアップ 注意点 同じくpostgresql.conf 等は 自分で設定が必要
53. 停止を伴うバージョンアップ コピーモードとリンクモード
54. 停止を伴うバージョンアップ コピーモードとリンクモード 旧DBのデータが残るので ロールバックを考えたらこっち
55. 停止を伴うバージョンアップ コピーモードとリンクモード データコピーが無いので高速
56. 停止を伴うバージョンアップ どれくらい速度が変わるのか？
57. 停止を伴うバージョンアップ どれくらい速度が変わるのか？ ↓ 最大で400倍程度
58. 150GB、850テーブルの移行時 移行方法 所要時間(分) dump/restore(通常の方法) 300 dump/パラレルrestore(8.4からの機能) 180 pg_upgrade (コピーモード) 44 pg_upgrade (リンクモード) 0.7 引用元 : https://lets.postgresql.jp/documents/technical/contrib/pg_upgrade
59. pg_upgradeの事例 3TB超のCacooのPostgreSQL 9.3を 9.5にアップグレードした話 https://nulab-inc.com/ja/blog/cacoo/postgresql-from-9-3-to-9-5/
60. 停止を伴うバージョンアップ • 停止時間を短くして、すばやくバージョンアップ • 移行用のインスタンスやサーバが不要 • 手順が簡単 • 事前に試すことができる この方式のメリット
61. 停止を伴うバージョンアップ • リンクモードは高速だがロールバックが出来ない • 停止は必須 • Versionの制約がある • 事前に対象のPostgreSQLのインストールが必要 この方式のデメリット
62. 停止を伴うバージョンアップ 最近はDISKも早いので pg_dumpで大体なんとかなる (停止さえできれば)
63. あじぇんだ 1 自己紹介 2 Version upの種類とメリット 3 停止を伴うVersion up 4 停止を最小化したVersion up 5 まとめ
64. 停止を最小化したVersion up それでも止めれない時 または巨大なDBの時
65. Version upの種類 項目 停止時間 難易度 補足 Pg_dump/pg_restore 長い データ量に比例 簡単 全部のVersionに対応 pg_upgrade 一定時間 データ量に依存しない 簡単 8.4以降 レプリケーション 切り替え時間のみ 中程度 Versionによって違う APPの二重書込 切り替え時間のみ ??? チーム次第
66. 停止を最小化したVersion up レプリケーションを活用する
67. 停止を最小化したVersion up ロジカルレプリケーション
68. Version upの種類 特徴 ストリーミングレプリケーション （物理レプリケーション） ロジカルレプリケーション （論理レプリケーション） レプリケーション対象 全てのデータベース データベース単位、テーブル単 位など柔軟に設定可能 利用用途 バックアップ、参照負荷分散 部分的なレプリケーション、 バージョンアップ 何を伝搬するか トランザクションログ（WAL） 変更された行の情報 受信側での更新 不可能 可能 異なるバージョン間でのレ プリケーション 不可能 可能 対応バージョン 9.0以降 10以降 引用元:www.intellilink.co.jp/article/column/oss-postgres03.html
69. ロジカル レプリケーション プライマリ スタンバイ ロジカル レプリケーション PostgreSQL 10 スタンバイ プライマリ フェイルオーバー クライアント 切り替え PostgreSQL 11 プライマリ スタンバイ PostgreSQL 10 クライアント レプリケーションの構築 PostgreSQL 11 ストリーミング レプリケーション クライアント 停止を最小化したVersion up
70. 停止を最小化したVersion up ロジカルレプリケーション が最強なのでは？
71. Version upの種類 特徴 ストリーミングレプリケーション （物理レプリケーション） ロジカルレプリケーション （論理レプリケーション） レプリケーション対象 全てのデータベース データベース単位、テーブル単 位など柔軟に設定可能 利用用途 バックアップ、参照負荷分散 部分的なレプリケーション、 バージョンアップ 何を伝搬するか トランザクションログ（WAL） 変更された行の情報 受信側での更新 不可能 可能 異なるバージョン間でのレ プリケーション 不可能 可能 対応バージョン 9.0以降 10以降 www.intellilink.co.jp/article/column/oss-postgres03.htmls
72. 停止を最小化したVersion up PostgreSQL 10の現場が ほとんど無い （しかも11は出たばっかり） 今後に期待
73. 停止を最小化したVersion up 代替案 1 Amazon Database Migration Service
75. 停止を最小化したVersion up AWSは便利 （ただし9.4以降）
76. 停止を最小化したVersion up pglogicalでも同じことが出来る （ただし9.4以降）
77. 停止を最小化したVersion up 9.4未満の人？ 停止してバージョンアップしましょう データがでかい場合、難易度 “高”になる
78. 停止を最小化したVersion up 代替案 2 Slony-I
79. 停止を最小化したVersion up Slony-I トリガーを利用した 非同期レプリケーションツール ロジカルレプリケーション と同じようなことが出来る
80. 停止を最小化したVersion up Slony-Iは設定ファイルが煩雑 （ぶっちゃけむずい）
81. 停止を最小化したVersion up Slony-Iはトリガーベースなので パフォーマンスが悪い （大規模だと厳しい）
82. 停止を最小化したVersion up しかし現状では一番の現実解
83. 停止を伴うバージョンアップ 注意点 Slony-I 2.0は8.3以上で動作 それ未満のバージョンアップの時は古いSlony-Iが必要
84. 停止を最小化したVersion up • 停止時間を極小化出来る（切り替え時間のみ） • データ量の大きさに依存しない • 新しいバージョンでは簡単に出来る この方式のメリット
85. 停止を最小化したVersion up • フェイルオーバーの時に大規模だと参照が捌けない • 用意に必要なサーバの台数が多い • 技術的な難易度が高くなる • 障害時の切り戻しが難しい この方式のデメリット
86. 停止を最小化したVersion up インフラを触らずに データを連携する方法
87. 停止を最小化したVersion up アプリケーションが 新旧DBに書き込む
88. プライマリ プライマリ PostgreSQL 10 アプリケーション PostgreSQL 11 停止を最小化したVersion up 両方に書き込み 参照は旧DB
89. プライマリ プライマリ PostgreSQL 10 アプリケーション PostgreSQL 11 停止を最小化したVersion up 旧DBの書き込みをやめる 参照を切り替える
90. 停止を最小化したVersion up レプリケーションと 同じような効果がある
91. 停止を最小化したVersion up モデル層がリポジトリパターンで 適切に設計されていた場合は 比較的簡単に出来る 大体されてない
92. 停止を最小化したVersion up どれも工数はそれなりに掛かる ↓ 停止出来るなら停止した方が楽
93. あじぇんだ 1 自己紹介 2 Version upの種類とメリット 3 停止を伴うVersion up 4 停止を最小化したVersion up 5 まとめ
94. まとめ PostgreSQLは魅力的な機能が豊富！
96. まとめ バージョンを常に上げていきましょう
97. まとめ バージョンを常に上げていきましょう ↓ そういう文化を作る
98. まとめ 時間が経てばを経つほど バージョンの問題は根深くなる （データが大きくなるなど）
99. まとめ 最新版に追従していきましょう
100. おまけ シャーディングとかNoSQLなど 複数のデータストア層があると ゲキムズなのでやっぱ停止すべき
101. ご清聴ありがとうございました