20181201_MySQLバージョンアップの基礎知識.pdf

Copyright © 2018, Oracle and/or its affiliates. All rights reserved.
| MySQLバージョンアップの基礎知識 2018/12/01 第25回中国地方DB勉強会 in 鳥取（倉吉） updated 2018/12/03 Yoshiaki Yamasaki / 山﨑由章 MySQL Global Business Unit MySQL Senior Sales Consultant

Safe Harbor Statement 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメントするものではない為、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。 2

Program Agenda 3 MySQLをバージョンアップする必要性バージョンアップ手法の選択肢バージョンアップの事前準備基本的なバージョンアップ手順参考情報 1 2 3 4 5

なぜバージョンアップをするするのか？ • 旧バージョンのサポート期間が終了する • 旧バージョンを使用し続けることによるセキュリティリスクを避けたい • 旧バージョンを使用し続けることによる運用管理コスト増加を避けたい – 新バージョンの方が性能がいい場合がある – 新バージョンの方が運用管理コストが下がる場合がある – 複数サーバーを管理している場合、旧バージョンの環境が混在していると運用管理手法が複数必要になる • 新機能を使いたい、など 5

旧バージョンのサポート期間が終了する 6

MySQLのサポート期間、知っていますか？ • 商用版のMySQLに対して、ライフタイム・サポート・ポリシーに従ってサポート期間が明確に定められています • オープンソース版のMySQLも、商用版のMySQLと同じタイミングでパッチの提供（マイナーバージョンアップのリリース）をしているため、実質的にはオープンソース版のMySQLのサポート期間も同様になります 7

ライフタイム・サポート・ポリシーとは？ • オラクルの製品/ライセンスとサポート契約をお客様が保持する限り、特段の定めがある場合をのぞいて、ソフトウェア製品やオペレーティング・システム製品は無期限で、ハードウェア製品は予め期限を定めずにサポート・サービスを提供するポリシー • ただし、ソフトウェア製品やオペレーティング・システム製品については、出荷開始からの経過期間等により提供されるサービス・レベルが変動する • サービス・レベルは、Premier Support, Extended Support, Sustaining Support の3種類がある 8

サービスレベルの違い（概要） • Premier Support – 通常出荷開始（GA）日から5年間、包括的なメンテナンスとソフトウェア・アップグレードを提供（最も高いサポートレベルを提供） • Extended Support – 製品およびリリースによっては、Extended Support期間が設定されることがある（MySQLには設定されている） – Premier Supportの後さらに3年間、Premier Supportとほぼ同等の保守・サポートを提供 • Sustaining Support – 新規の問題に対する修正（パッチの提供）は原則的に行われないが、サポートエンジニアからのサポートは受けられる 9

サービスレベルの違い（一覧表） 10 ※出典：https://www.mysql.com/jp/support/

11 MySQLのサポート期間 ※出典：https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf

MySQLのサポート期間：重要なポイント 12 • MySQL 5.6のPremier Supportは2018年2月に終了 • MySQL 5.5のExtended Supportは2018年12月に終了

MySQLサポート期間のご案内 13 • MySQL 5.6のPremier Supportは2018年2月に終了 • MySQL 5.5のExtended Supportは2018年12月に終了 ⇒MySQL 5.7、MySQL 8.0へのバージョンアップを計画下さい！！

旧バージョンを使用し続けることによるセキュリティリスクを避けたい 14

MySQLのセキュリティ上の脆弱性に関して • オラクル社はセキュリティ上の脆弱性修復のため迅速な行動をとり、定期的に情報発信しています – ネット上で脆弱性に関する情報がバズっている時以外でも、日々脆弱性には迅速に対応し、情報発信しています • 「Critical Patch Updates」という形で3か月に1回情報を発信し、情報公開日も予め定めています（1月、4月、7月、10月の17日に最も近い火曜日） – 2019年の公開日（米国時間） • 2019年1月15日 • 2019年4月16日 • 2019年7月16日 • 2019年10月15日 15

MySQLのセキュリティ上の脆弱性に関して • 更に、Critical Patch Updateの公開を待てないような重篤な脆弱性の修正を提供した場合には、Security Alertsが発行されます • 備考：Critical Patch UpdatesとSecurity Alerts https://www.oracle.com/technetwork/jp/topics/alerts-082677-ja.html#CPU ⇒それぞれのCPUの“Risk Matrix”を“MySQL”で検索してMySQLに関する情報をご確認下さい 16

17 MySQLのRisk Matrixの例 ※出典：https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html?ssSourceSiteId=otnjp#AppendixDB#AppendixMSQL

18 MySQLのRisk Matrixの例 ※出典：https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html?ssSourceSiteId=otnjp#AppendixDB#AppendixMSQL "CVE-2016-9843"は、MySQL 5.5、5.6、5.7、8.0に影響するが、それぞれ5.5.62以降、5.6.42以降、 5.7.24以降、8.0.13以降にバージョンアップすれば影響を受けなくなることが判断できる

セキュリティリスクを下げるためにも、小まめなパッチ適用（マイナーバージョンアップ）も検討下さい 19 ※発表後に追記したスライド

小まめにパッチ適用することによる副次的なメリット • 1度も停止したことのないDB（システム）は、いざという時にも停止しにくい • 普段から小まめにパッチ適用し、短時間のDB（システム）停止に慣れておくことで、（メジャーバージョンアップ時など）いざという時にDB（システム）を長時間停止する時にも、関係者の理解を得やすくなる 20 ※発表後に追記したスライド (勉強会当日聞いた@soudai1025さんの話に感銘を受け、追記）

・旧バージョンを使用し続けることによる運用管理コスト増加を避けたい・新機能を使いたい 21

MySQL 5.6での新機能、改善点の例 • オンラインDDL • バッファプールのダンプ/リストア • トランスポータブル・テーブルスペース • GTID、クラッシュセーフなスレーブ、バイナリログのグループコミット • オプティマイザ統計の永続化、オプティマイザの改善 – サブクエリの高速化、インデックス・コンディション・プッシュダウン、 LIMIT句で少数のレコードを取得する際のファイル・ソートを最適化、など • パフォーマンス・スキーマの拡張 • Visual EXPLAIN、SELECT文以外に対するEXPLAIN、オプティマイザ・トレース 22

MySQL 5.7での新機能、改善点の例 • JSONデータ型、JSON関数 • InnoDB日本語全文検索 • GIS機能（InnoDBでの空間インデックス、GeoHash、GeoJSON、など） • パフォーマンス・スキーマの拡張、sysスキーマ • UNDOログの自動トランケート • マルチソース・レプリケーション、マルチスレッドスレーブ • Generated Columns（生成列）とFunctional Index（関数インデックス） • オプティマイザの改善 23

MySQL 8.0での新機能、改善点の例 • Utf8mb4の性能改善 • Window関数、CTE（WITH句） • 更に機能強化されたJSONデータ型、JSON関数（JSON_TABLE関数、など） • MySQL ドキュメントストア • GIS機能のSRID対応 • トランザクショナル・データ・ディクショナリ • リモートマネジメント性の向上（SET PERSIST、RESTARTコマンド、など） • コストモデル、オプティマイザの改善 24

バージョンアップ手法の選択肢 • インプレースアップグレード • 新環境へのデータ移行（ロジカルアップグレード） – 通常はmysqldumpを使用 26

インプレースアップグレード • 実施方法 – MySQLサーバーのバイナリを新しいバージョンに入れ替えて、 mysql_upgradeを実行する • 備考 – 旧環境のデータベースを直接アップグレードする – 別筐体で実施したい場合は、コールドバックアップを取得して別筐体にリストアし、その後新しいバージョンのMySQLバイナリからmysql_upgradeを実行する – 1つ先のメジャーバージョンへバージョンアップ可能 • リスクをより低くするためには、まずそのバージョン内で最新のマイナーバージョンまでインプレースアップグレードした後で、次のメジャーバージョンにインプレースアップグレードする（例：MySQL 5.6.30 --> 5.6.42 --> 5.7.24） 27

インプレースアップグレード • 注意事項 – MySQL 5.5から5.6へのバージョンアップ時は、データ移行によるアップグレードが推奨されています（マニュアルに明記されています） • インプレースアップグレードでは、テーブル等のオブジェクトが再編成されません • MySQL 5.6ではDATETIME型の内部フォーマットが変更されたため、オブジェクトを再編成しないと新しいフォーマットになりません 28 ※出典：https://dev.mysql.com/doc/refman/5.6/en/upgrade-binary-package.html

補足：mysql_upgradeとは？ • mysql_upgradeを実行すると、全てのデータベースの全てのテーブルに対して、現在のバージョンのMySQLサーバーとの非互換性を調べ、修復を試みる（システムテーブルも含む） • 参考マニュアル – MySQL 8.0 Reference Manual / 4.4.5 mysql_upgrade — Check and Upgrade MySQL Tables • https://dev.mysql.com/doc/refman/8.0/en/mysql-upgrade.html – MySQL 5.7 Reference Manual / 4.4.7 mysql_upgrade — Check and Upgrade MySQL Tables • https://dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html – MySQL 5.6 Reference Manual / 4.4.7 mysql_upgrade — Check and Upgrade MySQL Tables • https://dev.mysql.com/doc/refman/5.6/en/mysql-upgrade.html – MySQL 5.6 リファレンスマニュアル / 4.4.7 mysql_upgrade — MySQL テーブルのチェックとアップグレード • https://dev.mysql.com/doc/refman/5.6/ja/mysql-upgrade.html 29

新環境へのデータ移行 • 実施方法 – 旧環境とは別に新環境のMySQLデータベースを作成し、そこにデータを入れる • 備考 – 旧環境のデータベースを残したまま新しい環境を作成可能 – 新環境のMySQLデータベースに必要なユーザーを作成後、 mysqldumpで取得したユーザーデータをロードする – 2つ以上先のメジャーバージョンへも直接移行可能 30

新環境へのデータ移行 • 備考 – データ移行に伴うトラブルが発生する可能性があるが、データ移行時にテーブル等のオブジェクトが再編成されるというメリットがある 31

バージョンアップの事前準備 • バージョン間の差異の確認 • MySQLの移行テスト – MySQLモジュールとデータベースのバージョンアップ • アプリケーションのテスト • 移行作業計画策定 33

バージョン間の差異の確認 34

バージョン間の差異を確認することの重要性 • バージョンアップにより互換性が失われる変更が存在する可能性がある • 互換性は保たれつつも、影響の大きい変更が存在する可能性がある • 事前にそれらを確認することで、バージョンアップ後に想定外の問題が発生するリスクを下げることが出来る 35

マニュアルからバージョン間の差異を確認する • マニュアル中の”Upgrading MySQL”の ”Changes Affecting Upgrades to MySQL x.x”セクションを確認 • Known issue(既知の問題)やIncompatible change(互換性が失われる変更) に特に注意する 36

マニュアルからバージョン間の差異を確認する • マニュアルの”Changes Affecting Upgrades to MySQL x.x”セクション – MySQL 8.0 Reference Manual / 2.11.1.3 Changes in MySQL 8.0 • https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html – MySQL 5.7 Reference Manual / 2.11.1.2 Changes Affecting Upgrades to MySQL 5.7 • https://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html – MySQL 5.6 Reference Manual / 2.11.1.2 Changes Affecting Upgrades to MySQL 5.6 • https://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html – MySQL 5.6 リファレンスマニュアル / 2.11.1.3 MySQL 5.5 から 5.6 へのアップグレード • https://dev.mysql.com/doc/refman/5.6/ja/upgrading-from-previous-series.html 37

「Changes Affecting Upgrades to MySQL 5.7」の例 • Incompatible change – In MySQL 5.7.5, the executable binary version of mysql_install_db is located in the bin installation directory, whereas the Perl version was located in the scripts installation directory. For upgrades from an older version of MySQL, you may find a version in both directories. To avoid confusion, remove the version in the scripts directory. For fresh installations of MySQL 5.7.5 or later, mysql_install_db is only found in the bin directory, and the scripts directory is no longer present. Applications that expect to find mysql_install_db in the scripts directory should be updated to look in the bin directory instead. – The location of mysql_install_db becomes less material as of MySQL 5.7.6 because as of that version it is deprecated in favor of mysqld --initialize (or mysqld --initialize- insecure). See Section 2.10.1.1, “Initializing the Data Directory Manually Using mysqld” 38

「Changes Affecting Upgrades to MySQL 5.7」の例 • Incompatible change – In MySQL 5.7.5, the executable binary version of mysql_install_db is located in the bin installation directory, whereas the Perl version was located in the scripts installation directory. For upgrades from an older version of MySQL, you may find a version in both directories. To avoid confusion, remove the version in the scripts directory. For fresh installations of MySQL 5.7.5 or later, mysql_install_db is only found in the bin directory, and the scripts directory is no longer present. Applications that expect to find mysql_install_db in the scripts directory should be updated to look in the bin directory instead. – The location of mysql_install_db becomes less material as of MySQL 5.7.6 because as of that version it is deprecated in favor of mysqld --initialize (or mysqld --initialize- insecure). See Section 2.10.1.1, “Initializing the Data Directory Manually Using mysqld” 39 ⇒データディレクトリの初期化(初期DB作成)方法として、mysql_install_dbではなく、 ”mysqld --initialize”が推奨されている ⇒scripts配下のmysql_install_dbが廃止されている

リリースノートから差異を確認する • 各バージョンのリリースノートには、マイナーバージョン毎の変更履歴が記載されている • バージョン間のリリースノートを全て確認することが理想的 – 例）MySQL 5.7.21 から MySQL 8.0.13 へ移行する場合 ⇒MySQL 5.7.21～5.7.24(最新版)、MySQL 8.0.1～8.0.13(最新版)のリリースノートを確認 • 最低でも”Incompatible Change”の記載内容は事前に確認することを推奨 40

リリースノートから差異を確認する • 各バージョンのリリースノート – MySQL 8.0 Release Notes • https://dev.mysql.com/doc/relnotes/mysql/8.0/en/ – MySQL 5.7 Release Notes • https://dev.mysql.com/doc/relnotes/mysql/5.7/en/ – MySQL 5.6 Release Notes • https://dev.mysql.com/doc/relnotes/mysql/5.6/en/ – MySQL 5.5 Release Notes • https://dev.mysql.com/doc/relnotes/mysql/5.5/en/ 41

リリースノートの例 42 ※https://dev.mysql.com/doc/relnotes/mysql/5.7/en/ 各マイナーバージョン毎に変更内容がまとめられている

リリースノートの例 43 5.7.21での変更内容

リリースノートの例 44 互換性が失われる変更点には“Incompatible Change“という見出しがついている

パラメーターの差異の確認 • バージョンアップにより、追加されたパラメーター、廃止/非推奨になったパラメーター、デフォルト値が変更になったパラメーターが存在する場合がある • これらの変更点はマニュアルやリリースノートで確認できる – MySQL Server Version Reference / mysqld Option/Variable Reference • https://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-optvar.html • 既存環境のmy.cnf/my.iniをベースにして、旧環境、新環境で各パラメーターに設定される値を比較し、差異を確認すればより安全 – この作業に役立つ資料を公開しています（詳細は後述） 45

マニュアルから各パラメーターの詳細を確認する • マニュアルの“Server System Variables”セクションを参照し、確認したいパラメーター名で検索 – MySQL 8.0 Reference Manual / 5.1.8 Server System Variables • https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html – MySQL 5.7 Reference Manual / 5.1.5 Server System Variables • https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html – MySQL 5.6 Reference Manual / 5.1.5 Server System Variables • https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html – MySQL 5.6 リファレンスマニュアル / 5.1.4 サーバーシステム変数 • https://dev.mysql.com/doc/refman/5.6/ja/server-system-variables.html 46

マニュアルから各パラメーターの詳細を確認する • binlog-formatの確認例 – MySQL 5.7.7以降はデフォルト値がROWに変更されていることが分かる（MySQL 5.7がGAになったのは5.7.9） 47

参考資料：パラメーター変更に伴う注意事項解説 • MySQL 5.6 と MySQL 5.7 のシステム変数の設定の違いと注意事項について解説した資料 – MySQL 5.7とMySQL 5.6設定パラメータ比較 https://www.mysql.com/jp/why-mysql/presentations/mysql-variables-comparation- ppt-201702-ja/ • MySQL 5.7 と MySQL 8.0 のシステム変数の設定の違いと注意事項などについて解説した資料 – MySQL 8.0へのアップグレードのポイントとパラメタ比較 https://www.mysql.com/jp/why-mysql/presentations/mysql-variables-comparation- ppt-57-80-ja/ 48

参考資料： MySQLのパラメーター比較 • MySQL 5.5、5.6、5.7、8.0でのパラメータの差異の確認に役立つ Excelファイル（パラメーターのデフォルト値確認方法も掲載） – 以下のバージョンにおけるパラメーターのデフォルト値を比較したExcelファイル • MySQL 5.5.46 2015年09月30日リリース ※MySQL 5.7 GAリリース時点の最新版 • MySQL 5.6.27 2015年09月30日リリース ※MySQL 5.7 GAリリース時点の最新版 • MySQL 5.7.9 2015年10月21日リリース ※MySQL 5.7 GAリリース • MySQL 5.7.17 2016年12月12日リリース ※2017年02月07日時点の最新版 • MySQL 8.0.11 2018年04月19日リリース ※MySQL 8.0 GAリリース • MySQL 8.0.12 2018年07月27日リリース ※2018年07月27日時点の最新版 – ダウンロード先 • https://www.mysql.com/jp/why-mysql/presentations/mysql-variables-comparison-ja/ 49

参考情報： MySQLのパラメーター比較 • @tmtmsさんが、MySQLのバージョン間のパラメーター比較ができるページを作成してくれています – MySQL Parameters https://tmtm.github.io/mysql-params/ ※@tmtms のメモ / MySQLパラメータ比較 https://tmtms.hatenablog.com/entry/2018/02/26/mysql-parameters 50

予約語、関数の差異の確認 • バージョンアップにより、予約語や使用できる関数に違いがある可能性がある • これらの変更点はマニュアルやリリースノートで確認できる – MySQL Server Version Reference / Keywords and Reserved Words • https://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-keywords.html – MySQL Server Version Reference / Functions and Operators • https://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-opsfuncs.html 51 ※MySQL 5.7へバージョンアップする場合でも、将来MySQL 8.0にバージョンアップすることを見越して、 MySQL 8.0でキーワード/予約語となっている文字列をオブジェクト名等に使用しないことを推奨します。

MySQL upgrade_checkerを使って事前確認する（5.7-->8.0） • MySQL upgrade_checker – MySQL Shellに追加された新しいツール • upgrade_checker を使うことで、MySQL 5.7のアップグレード準備状況をチェックできる – 準備が不十分な場合、必要な変更点を推奨してくれる • upgrade_checker は活発に開発中 – 今後のマイナーバージョンアップにより、より多くのチェック項目が追加される予定 52

MySQL upgrade_checkerを使って事前確認する（5.7-->8.0） • 非公式なツールですが、Oracle ACE(MySQL)の@yoku0825さんがPerlで実装して下さったMySQL 5.6以前に対しても実行できるバージョンもあります – https://github.com/yoku0825/p5-mysql-upgrade-checker/blob/master/README.md 53

• 古い temporal type の使用 • DBのオブジェクト名と予約語の競合 • utf8mb3キャラクタセットの使用 • mysqlスキーマの予約されたテーブル名 • 64文字を超える外部キーの名前 • 廃止された sql_mode の使用 • 255文字を超える要素を含む ENUM/SET型の列 • 共有テーブルスペースでのパーティショニングテーブルの使用 • 廃止された関数の使用 • 廃止された GROUP BY ASC/DESC の使用 • ”check table” と ”for upgrade” コマンドによって報告される問題 54 MySQL upgrade_checkerで確認できる内容

MySQLの移行テスト（MySQLモジュールとデータベースのバージョンアップ） 55

MySQLの移行テスト • MySQLの移行作業が問題無く完了するかを事前にテスト環境でテストする • 移行作業計画を立てるために、作業時間も記録しておく – 本番の移行作業を実施する際に必要なタスクの作業時間が重要 • 例）別筐体に新環境を作ってmysqldumpでデータ移行する場合 ⇒「現行環境からmysqldumpでデータを抜く時間＋ダンプファイルを新環境に転送する時間＋新環境でダンプファイルをロードする時間＋作業後の確認時間」 • MySQLモジュールとデータベースのバージョンアップ方法については後述 56

アプリケーションのテスト 57

アプリテストの必要性 • 事前にマニュアル、リリースノートからバージョン間の差異を確認し、アプリケーションが影響を受ける部分については修正しておくことが望ましが、全てを事前に修正出来るわけでは無い – 要因： • ドキュメントの確認漏れ • ドキュメントに記載されていない細かな変更点による影響、、、など • バージョンアップ後の環境でアプリケーションが問題無く動くかどうかは、事前に検証が必要 • マイナーバージョンアップにおいても、事前にアプリケーションテストを実施することを推奨 58

アプリテストの必要性 • アプリの修正が必要な場合は、修正後のアプリが問題無く稼働することをテストするとともに、稼働確認時間も含めて、アプリの修正を反映するためにかかる時間も見積もっておく – 移行作業計画を立てる上で必要 59

移行作業計画策定 60

移行作業計画 • MySQLの移行テスト、アプリケーションのテストが正常に完了した後に、移行作業計画を立てる • テスト時に見積もった時間をベースにし、問題が発生した場合の切り戻しにかかる時間も見越してメンテナンス時間を計画する • 想定外の事態へ備えるために、切り戻しを実施するか否かのマイルストーン、判断基準を予め設定しておく 61

基本的なバージョンアップの手順 1．アプリケーション停止 2．バックアップ取得 3．モジュールのバージョンアップ 4．データベースのバージョンアップ 5．移行後の確認 6．アプリケーション再開 63

バックアップ取得について • コールドバックアップやmysqldumpによるバックアップを取得する – バックアップ取得方法については、以下の資料を参照 • MySQL 5.7入門セミナー講演資料 (バックアップ編) https://www.mysql.com/jp/why-mysql/presentations/mysql-57-for-beginners-backup-ja/ • SQLダンプによるバージョンアップをする場合は、mysqldumpの取得が必須 – バージョンアップ作業中に既存環境に手を加えないため、既存環境をそのままバックアップとして扱える 64

モジュールのバージョンアップについて • 新バージョンのモジュールをインストールする • バージョンアップ先が別筐体の場合は、単純に新バージョンをインストールするだけ – モジュールのインストール方法については、以下の資料を参照 • MySQL 5.7入門セミナー講演資料 (インストール、アーキテクチャ基礎編) https://www.mysql.com/jp/why-mysql/presentations/mysql-57-for-beginners-install-ja/ • MySQL 8.0入門セミナー講演資料 (インストール、アーキテクチャ基礎編) https://www.mysql.com/jp/why-mysql/presentations/mysql-80-for-beginners-install-doc-ja/ 65

モジュールのバージョンアップについて • 同一筐体でバージョンアップする場合 – 旧バージョンの環境を残しておける場合はそのまま残しておくことで、バージョンアップ作業時に問題が発生した場合の切り戻しをスムーズに実施できる（.tar.gzや.zipファイルを使ってモジュールをインストールしている場合） • 異なるディレクトリにモジュールをインストールし、シンボリックリンクやフォルダ名のリネームで使用するモジュールを切り替える – YumやAPT、Windowsインストーラーを使用する場合は、旧環境をそのまま残しておけないため、切り戻し手順が複雑になり時間もかかることに注意 66

モジュールのバージョンアップについて • Yum、RPMによるMySQLのバージョンアップ – MySQL 8.0 Reference Manual / 2.11.1.6 Upgrading MySQL with the MySQL Yum Repository https://dev.mysql.com/doc/refman/8.0/en/updating-yum-repo.html – MySQL 5.7 Reference Manual / 2.11.1.3 Upgrading MySQL with the MySQL Yum Repository https://dev.mysql.com/doc/refman/5.7/en/updating-yum-repo.htm – MySQL 5.7 Reference Manual / 2.11.1.5 Upgrading MySQL with Directly-Downloaded RPM Packages https://dev.mysql.com/doc/refman/5.7/en/updating-direct-rpms.html 67

モジュールのバージョンアップについて • APTによるMySQLのバージョンアップ – MySQL 8.0 Reference Manual / 2.11.1.7 Upgrading MySQL with the MySQL APT Repository https://dev.mysql.com/doc/refman/8.0/en/updating-apt-repo.html – MySQL 5.7 Reference Manual / 2.11.1.4 Upgrading MySQL with the MySQL APT Repository https://dev.mysql.com/doc/refman/5.7/en/updating-apt-repo.html • WindowsインストーラーによるMySQLのバージョンアップ – MySQL 8.0 Reference Manual / 2.3.8 Upgrading MySQL on Windows https://dev.mysql.com/doc/refman/8.0/en/windows-upgrading.html – MySQL 5.7 Reference Manual / 2.3.8 Upgrading MySQL on Windows https://dev.mysql.com/doc/refman/5.7/en/windows-upgrading.html 68

データベースのバージョンアップについて • 前述の通り、以下の2種類の方法がある – インプレースアップグレード • モジュールをバージョンアップした後で、既存のdatadirに対して（データベースに対して） mysql_upgradeを実行する • 旧環境をそのまま残しておけないため、切り戻し手順が複雑になり時間もかかることに注意 – 事前にdatadir（データベース）のバックアップを取得しておき、切り戻し時にはバックアップを直ぐにリストアできるように準備しておく – mysqldumpを使用してデータを新環境にロードする • SQLダンプを新しいバージョンの環境にリストアする • 旧環境をそのまま残しておけるため、問題が発生した場合の切り戻しをスムーズに実施できる 69

mysqldumpを使用してデータを新環境にロードする • ユーザーは新環境に予め作成しておき、データだけ新環境にロードする • ユーザーの移行にはmysqlusercloneを活用可能 – MySQL Utilities 1.6 / 5.28 mysqluserclone — Clone Existing User to Create New User https://dev.mysql.com/doc/mysql-utilities/1.6/en/mysqluserclone.html 70

移行後の確認 • 移行作業のログを確認し、エラーやワーニングが発生していないか確認する • 移行前、移行後でオブジェクトの比較もしておくとより安全 – オブジェクト名の一覧の比較 – テーブルの行数の比較など 71

その他の考慮事項 72

バージョンアップによるメンテナンス時間を最小化する工夫 • レプリケーション機能を活用することでバージョンアップによるメンテナンス時間を最小化できる – 新環境を別筐体に用意し、既存環境をマスター、新環境をスレーブとしてレプリケーションを設定する – 「マスター：MySQL 5.6、スレーブ：MySQL 5.7」のように、スレーブをメジャーバージョン 1つ新しくする構成はサポートされる – レプリケーションにより更新内容が伝搬され、遅延がなくなってからアプリケーションの接続先を切り替えれば、メンテナンス時間は短時間で済む 73

バージョンアップによるメンテナンス時間を最小化する工夫 • レプリケーション機能を活用することでバージョンアップによるメンテナンス時間を最小化できる – 但し、レプリケーション機能のバージョン間の互換性に注意（例：MySQL 5.5とMySQL 5.6ではDATETIME型のフォーマットが異なるため、 DATETIME型に対するROWベースレプリケーションはエラーになる） – レプリケーション機能のバージョン間の互換性に関する情報 • MySQL 8.0 Reference Manual / 17.4.2 Replication Compatibility Between MySQL Versions https://dev.mysql.com/doc/refman/8.0/en/replication-compatibility.html • MySQL 5.7 Reference Manual / 16.4.2 Replication Compatibility Between MySQL Versions https://dev.mysql.com/doc/refman/5.7/en/replication-compatibility.html • MySQL 5.6 Reference Manual / 17.4.2 Replication Compatibility Between MySQL Versions https://dev.mysql.com/doc/refman/5.6/en/replication-compatibility.html 74

バージョンアップによるメンテナンス時間を最小化する工夫 • 注意事項 – MySQL 5.5から5.7への移行時に「MySQL 5.5 --> 5.6 --> 5.7」のように中間バージョンを経由する構成は、以前はサポートされていたが、サポートポリシーの変更があり、現在はサポート対象外となった（技術的に動くか動かないかという点は別にして） • 同時に3つ以上のバージョンが混在するレプリケーション構成はサポート対象外（「MySQL 8.0.11 --> 8.0.12 --> 8.0.13」のように、マイナーバージョン同士でもNG） • MySQL 5.6の日本語マニュアルではこのような中間バージョンを経由する構成に関する記述が残っているが、英語版マニュアルでは該当部分の記述は削除されているため注意（次ページ参照） 75

備考：現在英語版のマニュアルからは削除されている記述 76 • MySQL 5.6 リファレンスマニュアル / 17.4.2 MySQL バージョン間のレプリケーション互換性 – https://dev.mysql.com/doc/refman/5.6/ja/replication-compatibility.html 場合によっては、マスターと、マスターよりメジャーバージョン 2 つ以上新しいスレーブとの間で複製できます。ただし、MySQL 4.1 以前を実行するマスターから MySQL 5.1 以降を実行するスレーブに複製しようとすることに関する既知の問題があります。このような問題に対処するために、2 つの間に中間バージョンを実行する MySQL サーバーを挿入できます。たとえば、MySQL 4.1 マスターから MySQL 5.1 スレーブに直接複製するのではなく、MySQL 4.1 サーバーから MySQL 5.0 サーバーに複製してから、MySQL 5.0 サーバーから MySQL 5.1 サーバーに複製できます。

備考：3つ以上のバージョンが混在する構成に関する記述 77 • MySQL 8.0 Reference Manual / 17.4.2 Replication Compatibility Between MySQL Versions – https://dev.mysql.com/doc/refman/8.0/en/replication-compatibility.html The use of more than two MySQL Server versions is not supported in replication setups involving multiple masters, regardless of the number of master or slave MySQL servers. This restriction applies not only to release series, but to version numbers within the same release series as well. For example, if you are using a chained or circular replication setup, you cannot use MySQL 8.0.1, MySQL 8.0.2, and MySQL 8.0.4 concurrently, although you could use any two of these releases together.

Oracle MySQLサポートサービスとは？ • MySQL商用版を契約することで利用できるサポートサービス – 無制限サポート・インシデント – 24時間x365日サポート • コンサルティングサポートが含まれており、「SQLチューニング」や「スキーマ・レビュー」まで通常サポートの範囲内 – コンサルティングサポートの詳細はこちらを参照下さい http://www-jp.mysql.com/support/consultative.html • ソースコードレベルでサポート可能 – ほとんどのサポートエンジニアがソースを読めるため、対応が早い – 開発エンジニアとサポートエンジニアも密に連携している 79

Oracle MySQLサポートサービス：その他の特徴 • MySQL開発ベンダーによるベンダーサポート • コミュニティ版バイナリに対してもサポートを提供可能 – サブスクリプションを契約することで、バイナリを入れ替えずにサポートを受けられる（バイナリはオラクルが提供しているものをご使用ください） – 商用版の機能を使用する場合のバイナリ入れ替えの必要性については、P19参照 • ライフタイム・サポート・ポリシーにより長期間のサポートを提供 80

バージョンアップで困った時など、サポートの利用をご検討ください！！ 81

価格 MySQL サブスクリプション（ソケット数）年間価格（円）ライセンスカウント単位 MySQL Standard Edition （1-4ソケット・サーバー/年） 240,000 サーバー MySQL Enterprise Edition （1-4ソケット・サーバー/年） 600,000 サーバー MySQL Cluster Carrier Grade Edition （1-4ソケット・サーバー/年） 1,200,000 サーバー 82 MySQLライセンスは、MySQLデータベースがインストールされたサーバー数でカウントされます。価格は「物理サーバー単位」で、各エディションについて、1-4ソケットおよび5ソケット以上をもつサーバーの2クラスの価格があります。 5ソケット以上の価格については、MySQL担当営業までお問い合わせください。 MySQL Cluster を初めて導入される場合は、コンサルタントをご利用されることをお薦めしています。必ずオラクルのMySQL担当営業までご相談ください。 ※サーバー：プログラムがインストールされたコンピュータと定義されます。サーバー・ライセンスによって使用許諾を受けたプログラムを、指定された1台のコンピュータで使用することができます。仮想環境上でMySQLを稼働させた場合も物理サーバー単位でカウントされます。 ※ソケット：CPUチップ（またはマルチチップ・モジュール）を装着したスロットと定義され、1つまたは複数のコアを含みます。コアの数にかかわらず、各チップ（またはマルチチップ・モジュール）は1つのソケットとして数えられます。

お問合せ先 • [MySQL お問い合わせ窓口] 0120-065556 • 【受付時間】平日 9:00-12:00/13:00-18:00 (祝日及び年末年始休業日を除きます) [email protected] 83

84

20181201_MySQLバージョンアップの基礎知識.pdf

20181201_MySQLバージョンアップの基礎知識.pdf

More Decks by YoshiakiYamasaki

Other Decks in Technology

Featured

Transcript