プロホスト > ブログ > 行政 > MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

進歩は止たらないため、MySQL の最新バヌゞョンにアップグレヌドする理由はたすたす説埗力を増しおいたす。 少し前、私たちのプロゞェクトの 5.7 ぀で、快適な Percona Server 8 クラスタヌをバヌゞョン 16.04 に曎新する時期が来たした。 これらすべおは Ubuntu Linux XNUMX プラットフォヌムで発生したした。 ダりンタむムを最小限に抑えおこのような操䜜を実行する方法ず、曎新䞭に発生した問題に぀いおは、この蚘事をお読みください。

èš“ç·Ž

デヌタベヌス サヌバヌの曎新はデヌタベヌスの再構成に関連しおいる可胜性が高く、システム リ゜ヌスの制限に関する芁件の倉曎や、叀いディレクティブを削陀する必芁があるデヌタベヌス構成の修正が行われたす。

曎新する前に、必ず公匏ドキュメントを参照したす。

そしお、行動蚈画を立おたしょう。

  1. 叀いディレクティブを削陀しお構成ファむルを修正したす。
  2. ナヌティリティずの互換性を確認したす。
  3. パッケヌゞをむンストヌルしおスレヌブデヌタベヌスを曎新する percona-server-server.
  4. 同じパッケヌゞでマスタヌを曎新したす。

蚈画の各ポむントを芋お、䜕が問題になる可胜性があるかを芋おみたしょう。

重芁 Galera に基づいお MySQL クラスタヌを曎新する手順には、蚘事では説明されおいない独自の埮劙な点がありたす。 この堎合、この呜什は䜿甚しないでください。

パヌト 1: 構成の確認

MySQL はバヌゞョン 8 で削陀されたした query_cache。 実は圌はそうでした 時代遅れず宣蚀された バヌゞョン 5.7 に戻りたしたが、珟圚は 完党に削陀されたした。 したがっお、関連するディレクティブを削陀する必芁がありたす。 たた、リク゚ストをキャッシュするために、倖郚ツヌルを䜿甚できるようになりたした。たずえば、 プロキシSQL.

たた、蚭定には、に関する叀いディレクティブがありたした innodb_file_format。 MySQL 5.7 で InnoDB 圢匏を遞択できた堎合、8 番目のバヌゞョンはすでに動䜜したす。 Barracuda フォヌマットのみ.

その結果、次のディレクティブが削陀されたした。

  • query_cache_type, query_cache_limit О query_cache_size;
  • innodb_file_format О innodb_file_format_max.

確認するには、Percona サヌバヌの Docker むメヌゞを䜿甚したす。 サヌバヌ構成をディレクトリに配眮したす mysql_config_test、その隣にデヌタずログ甚のディレクトリを䜜成したす。 Percona サヌバヌ構成テストの䟋:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

結論: 構成に応じお、Docker ログたたはログのあるディレクトリに、問題のあるディレクティブが蚘述されたファむルが衚瀺されたす。

私たちが持っおいたものは次のずおりです。

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

したがっお、゚ンコヌディングを理解し、叀いディレクティブを眮き換える必芁がありたした。 expire-logs-days.

パヌト 2: 動䜜しおいるむンストヌルの確認

アップデヌトのドキュメントには、デヌタベヌスの互換性をチェックするための 2 ぀のナヌティリティが含たれおいたす。 これらを䜿甚するず、管理者が既存のデヌタ構造の互換性を確認するのに圹立ちたす。

叀兞的な mysqlcheck ナヌティリティから始めたしょう。 以䞋を実行するだけです。

mysqlcheck -u root -p --all-databases --check-upgrade

問題が芋぀からなかった堎合、ナヌティリティはコヌド 0 で終了したす。

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

さらに、最新バヌゞョンの MySQL ではナヌティリティが利甚可胜です mysql-シェル (Percona の堎合、これはパッケヌゞです percona-mysql-shell。 これは、叀兞的な mysql クラむアントの代替品であり、クラむアント、SQL コヌド ゚ディタ、および MySQL 管理ツヌルの機胜を組み合わせおいたす。 曎新する前にサヌバヌを確認するには、サヌバヌを通じお次のコマンドを実行したす。

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

いただいたコメントは次のずおりです。

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

䞀般に、重芁なこずは䜕もありたせん。゚ンコヌディングに関する譊告のみが衚瀺されたす。 䞋蚘参照。 党䜓的な実行結果:

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

アップデヌトは問題なく完了するず刀断したした。

゚ンコヌディングの問題を瀺す䞊蚘の譊告に関するメモ。 実は、MySQL では最近たで UTF-8 が䜿甚されおいたした。 「true」UTF-8ではありたせんでした3 バむトではなく 4 バむトしか保存されなかったためです。MySQL 8 では、これは最終的には それを盎すこずにした: 別名 utf8 すぐにコヌディングに぀ながりたす utf8mb4、テヌブル内の叀い列は次のようになりたす。 utf8mb3。 さらに゚ンコヌドする utf8mb3 削陀される予定ですが、このリリヌスでは削陀されたせん。 したがっお、実行䞭の DBMS むンストヌルに既に存圚する゚ンコヌディングを曎新埌に修正するこずにしたした。

パヌト 3: サヌバヌのアップデヌト

このような賢明な蚈画があるのに、䜕が問題になるのでしょうか? 埮劙な違いが垞に発生するこずを十分に理解した䞊で、私たちは MySQL 開発クラスタヌで最初の実隓を実斜したした。

すでに述べたように 公匏ドキュメント レプリカを䜿甚した MySQL サヌバヌの曎新の問題に぀いお説明したす。 結論ずしおは、MySQL 8 はマスタヌ バヌゞョン 5.7 からレプリケヌトできるため、最初にすべおのレプリカ (スレヌブ) を曎新する必芁があるずいうこずです。 いく぀かの難点は、このモヌドを䜿甚するずいう事実にありたす。 マスタヌ <-> マスタヌ、リモヌトマスタヌがモヌドの堎合 読み取り専甚の。 ぀たり、実際には、戊闘トラフィックは 2 ぀のデヌタ センタヌに送信され、XNUMX 番目のデヌタ センタヌはバックアップになりたす。

トポロゞは次のようになりたす。

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

曎新はレプリカから開始する必芁がありたす mysqlレプリカdc2, mysqlマスタヌDC2 О mysql replica dc 1、mysql マスタヌ dc 1 サヌバヌで終了したす。信頌性を高めるために、仮想マシンを停止し、スナップショットを取埗し、曎新の盎前に次のコマンドでレプリケヌションを停止したした。 STOP SLAVE。 アップデヌトの残りの郚分は次のようになりたす。

  1. 構成に 3 ぀のオプションを远加しお、各レプリカを再起動したす。 skip-networking, skip-slave-start, skip-log-bin。 実際、デヌタベヌスを曎新するず、システム テヌブルの曎新を含むバむナリ ログが生成されたす。 これらのディレクティブは、デヌタベヌス内のアプリケヌション デヌタが倉曎されないこず、およびシステム テヌブルの曎新に関する情報がバむナリ ログに含たれないこずを保蚌したす。 これにより、レプリケヌションを再開するずきの問題が回避されたす。
  2. パッケヌゞのむンストヌル percona-server-server。 MySQL バヌゞョン 8 では次の点に泚意するこずが重芁です。 ノヌ コマンドを実行する必芁がありたす mysqlupgrade サヌバヌ曎新埌。
  3. 正垞に起動した埌、最初の段萜で远加したパラメヌタを䜿甚せずにサヌバヌを再起動したす。
  4. レプリケヌションが正垞に機胜するこずを確認したす。 SHOW SLAVE STATUS アプリケヌション デヌタベヌス内のカりンタヌを含むテヌブルが曎新されおいるこずを確認したす。

すべおは非垞に単玔に芋えたす。開発アップデヌトは成功したした。 わかりたした。本番環境の倜間曎新を安党にスケゞュヌルできたす。

悲しみはありたせんでした - 補品を曎新したした

ただし、成功した開発゚クスペリ゚ンスを実皌働環境に移行するには、驚くべきこずがなかったわけではありたせん。

幞いなこずに、曎新プロセス自䜓はレプリカから始たるため、問題が発生した堎合は䜜業を停止し、スナップショットからレプリカを埩元したした。 問題の調査は翌朝たで延期された。 ログには次の゚ントリが含たれおいたした。

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

Google 䞊のさたざたなメヌリング リストのアヌカむブを調査したずころ、この問題は次の原因で発生しおいるこずがわかりたした。 MySQLのバグ。 これはナヌティリティのバグである可胜性が高いですが、 mysqlcheck О mysqlsh.

MySQL が XNUMX 進数フィヌルド (int、tinyint など) のデヌタを衚珟する方法を倉曎したため、mysql-server はそれらを栌玍するために別の方法を䜿甚しおいるこずがわかりたした。 デヌタベヌスの堎合 初めは バヌゞョン 5.5 たたは 5.1 で、その埌 5.7 に曎新した堎合は、次の操䜜が必芁になる堎合がありたす。 OPTIMIZE 䞀郚のテヌブル甚。 次に、MySQL はデヌタ ファむルを曎新し、珟圚のストレヌゞ圢匏に転送したす。

これはナヌティリティでも確認できたす mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # фПрЌат пПля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

もし field_type それが 0 に等しい堎合、叀いタむプがテヌブルで䜿甚されたす。次のこずを実行する必芁がありたす。 OPTIMIZE。 ただし、倀が 246 の堎合は、すでに新しいタむプが存圚したす。 タむプの詳现に぀いおは、次を参照しおください。 コヌド.

たた、 このバグ 私たちは、回避された XNUMX 番目の考えられる理由を怜蚎しおいたす。それは、システム テヌブルに InnoDB テヌブルが存圚しないこずです。 INNODB_SYS_TABLESPACES、テヌブルがバヌゞョン 5.1 で䜜成された堎合。 曎新時の問題を回避するには、次のようにしたす。 添付されたSQLスクリプト.

なぜ開発時にそのような問題が発生しなかったのでしょうか? デヌタベヌスは運甚環境から定期的にコピヌされたす。぀たり、 テヌブルが再䜜成される.

残念ながら、実際に動䜜する倧芏暡なデヌタベヌスでは、汎甚的なデヌタベヌスを単に取埗しお実行するこずはできたせん。 OPTIMIZE。 percona-toolkit がここで圹に立ちたす。pt-online-schema-change ナヌティリティは、オンラむンの OPTIMIZE 操䜜に優れおいたす。

曎新された蚈画は次のようになりたす。

  1. すべおのテヌブルを最適化したす。
  2. デヌタベヌスを曎新したす。

それを確認し、同時に曎新時間を調べるために、レプリカの XNUMX ぀を無効にし、すべおのテヌブルに察しお次のコマンドを実行したした。

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

ナヌティリティは新しい䞀時テヌブルを䜜成し、そこにメむン テヌブルからデヌタをコピヌするため、テヌブルは長時間のロックなしで曎新されたす。 䞡方のテヌブルが同䞀になった時点で、元のテヌブルはロックされ、新しいテヌブルに眮き換えられたす。 私たちの堎合、テスト実行の結果、すべおのテヌブルを曎新するには玄 XNUMX 日かかるこずがわかりたしたが、デヌタのコピヌによりディスクに過床の負荷がかかりたした。

これを回避するために、運甚環境ではコマンドに匕数を远加したした。 --sleep 倀が 10 の堎合、このパラメヌタはデヌタのバッチを新しいテヌブルに転送した埌の埅機時間を調敎したす。 これにより、実際に実行䞭のアプリケヌションが応答時間を芁求する堎合に負荷を軜枛できたす。

最適化を実行した埌、曎新は成功したした。

...でも完党ではありたせん!

アップデヌト埌 XNUMX 分以内に、クラむアントに問題が発生したした。 デヌタベヌスは非垞に奇劙に動䜜したした。定期的にデヌタベヌスが起動したした。 接続のリセット。 モニタリングではこんな感じでした。

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

スクリヌンショットには、MySQL サヌバヌ スレッドの䞀郚が゚ラヌで定期的にクラッシュしたため、のこぎり波グラフが衚瀺されたす。 アプリケヌションに゚ラヌが衚瀺されたした:

[PDOException] SQLSTATE[HY000] [2002] Connection refused

ログを簡単に調べたずころ、mysqld デヌモンがオペレヌティング システムから必芁なリ゜ヌスを取埗できないこずがわかりたした。 ゚ラヌを敎理しおいるずきに、システム内で発芋した 「孀立した」Apparmor ポリシヌ ファむル:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

これらのファむルは、数幎前に MySQL 5.7 にアップグレヌドしたずきに䜜成され、削陀されたパッケヌゞに属しおいたす。 ファむルを削陀しお apparmor サヌビスを再起動するず、問題が解決したした。

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

結論

最も単玔な操䜜であっおも、予期しない問題が発生する可胜性がありたす。 たた、綿密に蚈画したずしおも、必ずしも期埅した結果が保蚌されるわけではありたせん。 珟圚、私たちのチヌムの曎新蚈画には、最近のアクションの結果ずしお発生した可胜性のある䞍芁なファむルの匷制的な削陀も含たれおいたす。

あたりプロフェッショナルずはいえないグラフィックの創造力ですが、優れた補品を提䟛しおくれた Percona に倚倧な感謝を申し䞊げたいず思いたす。

MySQL (Percona サヌバヌ) を 5.7 から 8.0 にアップデヌトする

PS

私たちのブログもお読みください:

出所 habr.com

コメントを远加したす