そーだいなるらくがき帳

そーだいが自由気侭に更新します。

PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った

中国地方DB勉強会 in 岡山の登壇資料です。

そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。

PostgreSQL

PostgreSQL 12に上げれるなら15まで基本的に上げれる。 自分もプロダクトで9.2から最近14まで上げましたが互換性、パフォーマンス共に問題なかった。

11,12から上げるところで大きな非互換はOIDの廃止だけど、基本的にそこに刺さる人はいないはず。 いたら returning 句を使う形に書き直しましょう。 または nextval() 先に値を取得する。 一般的なORMを使ってるような環境であれば一般的にそのへんは困らないはず。

見ると良い

公式ドキュメントは一通りみること

確認すること

拡張、Extensionをインストールしている場合があるのでそこは要確認。 インストールしている拡張はSQL SELECT * FROM pg_extension; で確認できるので事前に確認すること。 Extensionをインストールしている場合はExtensionのバージョンアップを調べること。

バージョンアップのドキュメント

公式があるので確認すること。 非推奨や削除された機能などが書いてある。

注意点

バージョンアップ直後、統計情報とかが壊れててパフォーマンスが落ちることがある。 これはAWSのドキュメントにも記載がある。

ANALYZE 操作を実行して pg_statistic テーブルを更新します。これは、すべての PostgreSQL DB インスタンスのすべてのデータベースに対して行う必要があります。Optimizer の統計情報はメジャーバージョンのアップグレード中には転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。次のようにパラメータを指定せずにコマンドを実行して、現在のデータベース内のすべての標準テーブルの統計情報を生成します

とりあえずアップデートしたらANALYZEしましょう。

あと、文字コードやロケール周りも要注意。

PostgreSQLはinitdbの際にロケールを指定しない場合、OS側に設定されているロケールを使用します。この場合の多くは、ja_JP.UTF-8が選ばれるでしょう。これに伴いDBが壊れることはありませんし、エラーなどもありません。ただし、ソート関連に影響し、OSに依存してしまうことから、意図しない挙動をすることがあります。

例えばこういうのもあるし、あとから変えるのは大変なので要注意。

あとMySQLも同様だけど、パラメータがリセットされて設定が変わることがあるのは要注意。 デッドロックやチェックポイント周りのチューニングやタイムゾーンなどは漏れやすい。

特にRDSはデフォルトのタイムゾーンはUTCだし、ロケールはなのでen_US.UTF-8なので注意。

Extension PostGISのアップデートの例

Managing spatial data with the PostGIS extension

AWSの手順書がちゃんとしているので参考にすること。#

view raw PostgreSQL-vup.md hosted with ❤ by GitHub
gist.github.com

MySQL

確認すること

メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。

基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある

最初に諦めること

  • MyISAMを使いたい
    • 8でも動くけど諦めろ、もう未来はない
    • InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが…
  • InnoDB memcached Pluginとか使ってるんだよね
    • 諦めろ、未来はない
    • これを機にアーキテクチャを見直しましょう
  • PKが無いtableがあるんだよね
    • すべてのtableにまずPKを付けるんだ
    • このあと、DMSを使ったりとかなにをするにしても死ぬ
    • そもそもデータモデルとして死んでるのでPKはつけよう
  • クエリキャッシュを使いたい

見ると良い

破壊的変更

注意点

  • 文字セットの違い
  • パフォーマンスはKVSのような使い方をしていると特に下がる
  • Aurora 2 → Aurora 3は20 ~ 30%程性能劣化することも珍しくない
  • クソデカテーブルの count(*) も遅くなっているのも影響を受けやすい
  • パラメータの差異は見逃しがち
    • 旧環境でチューニングしていた内容を反映することを忘れるなど
    • 例えば open_cache_table とか range_optimizer_max_mem_size とか
    • どちらも5.7のときからあるパラメータだが、バージョンアップ時に新しいconfingを利用することで変更を忘れてパフォーマンスに影響を与えることがある
  • 予約語とかSQLモードの違いとかによるエラーは開発環境で見つけれるはず
    • テストを書きましょう
    • GROUP BYや予約語は地道に直すしか無いです

準備としてやると良いこと

時間があったら書く

view raw mysql57to8.md hosted with ❤ by GitHub
gist.github.com

チートシートだけじゃわからない！困ってる！

Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。

have-fun.tech

まとめ

やっぱ中国地方DB勉強会は最高だぜ！