これには時間がかかることがあります。Portは3000ですが、初期設定後に設定画面からURL含めて変更する事が可能です。http://localhost:3000/setup/レポーティングとクエリーコンソールユーザー管理アカウントやグループ毎に関連するデータベース接続があっても良いかもしれません。(監査等)共通アプリケーションアカウントでも問題ありません。機密情報や重要な情報にアクセス出来ないようにデータベースアカウントの権限を絞ると良いかと思います。その他、Slack等との連携なかなか便利なツールです。非エンジニア以外の方にはテンプレートを作成してあげたり、読み込み専用DBにアクセスを分けてあげると安心です。Clusterを用いた、MySQLの高可用性構成への取り組みに関して紹介させて頂きました。プロダクションのデータベースなので、これまでの機能紹介やシンプルなデモとは異なり、様々な確認や調整が必要で、DBのアップグレード以上に時間を割いている感じです。Routerが自動的に接続を切り替えてくれるので非常に楽になります。作業工数も大幅に削減出来るので、会社にとってもダウンタイムによる機会損失削減といったメリットだけでなく、エンジニアの工数削減によりサービス開発に専念が出来るようになり非常に良いソリューションだと考えています。これからもMySQLだけでは無く、様々な高可用性構成をコストと運用の観点から考察して、順次導入していきたいと思っています。システム移行と同時に様々な、改善も並行して出来るので1年を目途に最適化が出来ると良いかなと思ってます。Sugiyama補足:資料には明記してませんが、シングルプライマリーモードで構成しているので、グループレプリケーション構成直後に以下の値を全て1に変更しています。rdbmsTweetMySQL用のコネクター、Connector/Jの動作を改めて確認してみました。jdbc:mysql:loadbalanceの接続方法による挙動の違い。|+---------------------------+--------------------------------------+--------------+-------------+--------------+-bash-4.2$オフィシャルマニュアルには以下のように書いてあるけど、十分に検証しないといけないので少し落ち着いたタイミングにならないとアップグレードは少々躊躇する。変更点を一つ一つ確認していくのは難しいので、にバージョン毎の差を明確に、分かりやすく書いてあるマニュアルがあると有難い。現状でも、5.1.17~5.1.47までリリースがある。8.0,5.7,5.6、および5.5での使用を強く推奨します。8.0にアップグレードしてください。JDBCドライバーです。5.5,5.6、および5.7を含むMySQLのすべての機能との互換性を提供します。XML処理、接続ごとのクライアント情報のサポート、NCHAR、NVARCHARおよびNCLOBデータ型のサポートします。4.2ドライバーです。5.5,5.6,5.7,8.0のすべての機能との互換性を提供します。1.8.xが必要です。Jの現在の推奨バージョンは5.1です。Jについても説明します。具体的な注釈は、設定が特定のバージョンに適用される場合に指定します。java]#コンパイルして実行してみます。基本的には、常時左から順に利用可能なサーバーにアクセスして処理します。アクセスしているサーバーに障害が発生した場合は、例2のようにフェールオーバーする事が可能です。3310例2)10回目の接続時に最初にアクセスしたサーバーをダウンさせたらフェールオーバーします。左側に記載したサーバーが利用可能になると、一番左側のサーバーにアクセスします。java]#コンパイルして実行してみます。以下の設定でマスターへの接続かスレーブへの接続か判断して処理します。明示的にレプリケーションドライバーを指定)マニュアルには具体的な内容は発見出来ていませんが以下のようにもコメントされています。現状では上記のようにjdbc:mysql:Replicationでコーディングする方が主流なのかと。それ以降のコールがマスターMySQLサーバーに送信されるようにしてください。ドライバは、このロードバランシング機能を達成するために使用するすべての接続間で、自動コミット、分離レベル、およびカタログの現在の状態を伝達します。この機能を有効にするには、アプリケーション・サーバーの接続プールを構成するとき、またはスタンドアロン・アプリケーション用のJDBCドライバのインスタンスを作成するときにcom.mysql.jdbc.ReplicationDriverクラスを使用します。JDBCドライバでない限り、ReplicationDriverは現在java.sql.DriverManagerベースの接続作成では動作しません。java]#jdbc:mysql:Replicationと同じく、conn.setReadOnly(false)はマスターにconn.setReadOnly(true)はスレーブに参照しに行きます。上記の例だとスレーブ間をラウンドロビンします。java]#以下のように、全てのサーバーにロードバランスされるのでマルチマスター環境で利用可能です。Master設定)の構成で便利です。Clusterの場合は制限事項があるので、バッチ処理等と同じデータベースと利用する場合は十分に検証が必要。SYSスキーマの確認。基本的には、MySQL5.7と変わりは無いですが、ロックを取得するVIEW内部のテーブルがInformation_schemaからPerformance_Schemaに変更になったりしている。VIEW内部のスクリプト変更なので基本的に問題無く、これまで通り利用する事が可能です。少々手間取ってしまいました。Partitionを利用していたので直ぐにアップグレードする事が出来ました。いくつか設定を変更しました。色々なアドバイスが出てくるので、必要に応じて適宜対応してください。my.cnfに以下の設定を入れておく。default_authentication_plugin=mysql_native_passwordまた、mysql8.0に無いパラメータは、削除しておかないとエラーになるので削除しておきましょう。‘query_cache_type=0’パラメータのチェックに関しては、こちらのページが便利です。ファイルが自動的にアップグレードされ、メタデータ関連ファイルが無くなっている事が確認できる。COMPOSERで最新版のフレームワークにアップグレード後にTRUEに戻しました。(本番環境では、意図しないエラーが発生することもあるので注意してTRUE,FALSEの設定を行ってください。false,NO_AUTO_CREATE_USER等の、SQLモードが削除されているのでフレームワークによっては、StrictモードがTrueのままだと、アプリケーションがエラーになる場合があります。参照:アカウント管理に関連する次の機能は削除されました。USERを使用するようになっています。SQLモードはGRANT文にとって重要ではない為、削除されました。STATUSは少し改善されていた。Schemaを確認してみた。MySQL8.0からはPerformance_Schemaを確認しなくても”Slave_SQL_Running_State”で状態が確認出来るようになっている。(update)”になっています。lockになっている。Threadの状態が良く分からない。SLAVE]上記マスターで負荷をかけた場合の、スレーブ側の状態。lock”という状態になっている。Threadが止まっている訳では無く、何らかの処理を行っている状態の場合もある。SlaveのPerfomance_Schemaの状態。SlaveのIDで確認してみると、statement/sql/beginという状態である事が分かる。Logの適用から発生するトランザクションでした。補足:トランザクションでロックをかけたセッションで、SYSスキーマを利用した為、sys.innodb_lock_waitsの値がおかしい。違うセッションであれば、sys.innodb_lock_waitsも問題無い。上記はバグでは無いですが、分かり難いのでスクリプト変更しました。rdbmsTweetMySQL8.0における文字セットの変更:デフォルトの文字セットがlatin1からutf8mb4に変更されます。これらのシステム変数は次のような影響を受けます。character_set_serverおよびcharacter_set_databaseシステム変数のデフォルト値は、latin1からutf8mb4に変更。collation_serverおよびcollation_databaseシステム変数のデフォルト値は、latin1_swedish_ciからutf8mb4_0900_ai_ciに変更。MySQL8.0では、Unicode9までアップグレードされています、またutf8mb4(4byte)では絵文字を含む文字も処理する事が出来る為、バージョンアップと共に文字コードや照合順序を変更される事もあるかと思います。簡単ですが、手順を再確認して見ました。MySQL8.0にアップグレードする前に,mysqlsh8.xのアップグレード確認ユーティリティでチェックするのもお勧めです。文字セットも確認してくれます。状況に応じて使い分けて下さい。変換結果としては、問題無くテーブルのDefault文字セットはutf8mb4に変換されている。sec)但し、上記のようにテーブルのDefault文字セットを変換しただけの場合、以下の様にテーブルのカラムなどの文字コードは変換されていない。新しい文字セットに変更するには、次のようなステートメントを使用。collation_name];注意:このステートメントでは、すべての文字カラムの照合順序も変更されます。句を指定しない場合、このステートメントは、その文字セットのデフォルトの照合順序を使用します。場合は、照合順序を明示的に指定します。以下のテーブルは、文字セットと照合順序変更に伴いFK制約に引っかかってしまったので、マニュアルで対応する。sec)該当テーブルを変換後は問題無く、スクリプトでまとめて変更する事が出来た。sec)テーブルの文字コード変換スクリプト作成と実行、TABLEの照合順序がCity2だけutf8mb4_binのまま残っている。sec)一度、テーブルのcharacter_setを上記のステップでutf8mb4に変換しているのでここでは外して、テーブルと列の文字セット変換スクリプトを実行したが、FKのエラーになったので、FKを無効にして関連テーブルをマニュアルで変換しておく。※テーブルだけでは無く、列の文字セットや照合順序も変わるので大文字小文字の区別などが変わると困るテーブルなどは個別にマニュアル対応して下さい。sec)対象テーブルの制約は対応済みなので、問題無く変換が終了。全てのテーブルの文字コードも照合順序も適切に変換された事を確認。sec)変換後もutf8からutf8mb4への変換なので特にデータに問題は無い。絵文字もutf8mb4なので問題無くINSERT出来る事を確認。文字関連のデータ型に関しては、キャラクターセットも照合順序も問題無い事が確認出来る。sec)詳細:Collation変更にあたり、色々と考慮しなければいけない事がまとめられていて参考になります。https://mysqlserverteam.com/mysql-8-0-collations-migrating-from-older-collations/特定の文字セットを使用するように、バイナリ文字列または非バイナリ文字列カラムを変換する為の注意点が書いてあります。抜粋:正しく変換が行われるには、次の条件のいずれかを適用する必要があります。使用してエンコードされる必要があります。どの値がどの文字セットを使用するかを認識できず、データを正確に変換できません。ある場合、その内容は、カラムの文字セットでエンコードする必要があり、ほかの文字セットは使用できません。内容が別の文字セットでエンコードされている場合、最初にバイナリデータ型を使用するようにカラムを変換してから、使用する文字セットで非バイナリカラムに変換できます。データ値をマップしようとしますが、文字セットに互換性がない場合、データの損失が生じる可能性があります。SETを利用する場合の注意に関しては、此方も合わせて確認して下さい。MySQL8.0にした場合は特に指定しなければDefaultで基本的には問題無い設定が適用されるので、マニュアルで指定している場合やカスタマイズしている場合は確認して下さい。rdbmsTweetMySQL8.0のエラーログの設定オプションが変わっているので、Fredのブログを確認しながら検証環境で確認しました。新しいコンポーネントベースのエラーログには次の機能があり、自分の環境にあった設定を選択する事が可能になっています。ログイベントは、フィルタコンポーネントによってフィルタリングして、書き込みに使用できる情報に影響を与えることができます。(writer)コンポーネントによって出力されます。複数のシンクコンポーネントを有効にして、エラーログの出力を複数の宛先に書き込むことができます。フィルタとライターの組み込みコンポーネントが組み合わされて、デフォルトのエラーログフォーマットが実装されています。ロード可能なライターを使用すると、システムログにロギングできます。ロード可能なライターを使用すると、JSON形式でのログ記録が可能になります。システム変数は、有効にするログコンポーネントとログイベントをフィルタリングするルールを制御します。log_error_servicesシステム変数は、エラーログに有効にするログコンポーネントを制御します。その値は、セミコロンで区切られたコンポーネントのリストです。スペースは重要ではありませんが、リストされた順序でコンポーネントを実行するため、コンポーネントの順序は重要です。JSONフォーマットのログを利用したいので、JSON用のコンポーネントを追加しています。メモ:log_errorがstderrの場合、JSONライターはコンソールにログを書き込みます。sec)MySQLを再起動して、JSONフォーマットのエラーログが追加されているか確認。log_sink_internalとlog_sink_jsonの2つが順に列挙されている為、エラーログは通常のエラーとJSONフォーマットのエラーログの2つが出力されています。以下、マニュアル抜粋log_filter_internal:優先度に基づくエラーログのフィルタリングエラーログの冗長性制御は、エラーイベントの優先度に基づいたログフィルタリングの簡単な形式です。これは、log_filter_internalログフィルタコンポーネントによって実装されます。log_filter_internalがエラー・ログを対象とするエラー、警告、およびメモイベントを許可または抑制する方法に影響を与えるには、log_error_verbosityシステム変数を設定します。log_filter_internalはデフォルトで組み込まれ、有効になっていますが、無効にするとlog_error_verbosityの変更は無効です。許可されるlog_error_verbosityの値は、1(エラーのみ)、2(エラーと警告)、3(エラー、警告、およびメモ)log_filter_dragnet:ルールベースのエラーログのフィルタリングlog_filter_dragnetログフィルタコンポーネントは、ユーザ定義のルールに基づいてログフィルタリングを有効にします。適用可能なルールを定義するにはdragnet.log_error_filter_rulesシステム変数を設定します。詳細:https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_dragnet.log_error_filter_ruleslog_filter_dragnetフィルタを有効にするには、まずフィルタコンポーネントをロードしてから、log_error_services値を変更します。log_filter_internal:優先度に基づくエラーログのフィルタリングエラーログの冗長性制御は、エラーイベントの優先度に基づいたログフィルタリングの簡単な形式です。これは、log_filter_internalログフィルタコンポーネントによって実装されます。log_filter_internalがエラー・ログを対象とするエラー、警告、およびメモイベントを許可または抑制する方法に影響を与えるには、log_error_verbosityシステム変数を設定します。log_filter_internalはデフォルトで組み込まれ、有効になっていますが、無効にするとlog_error_verbosityの変更は無効です。log_sink_internal、log_sink_test:これらのライターは、file_nameに書き込みますlog_sink_json:log_error_services値で指定されたこのライターの連続インスタンスは、file_nameという名前のファイルと、番号付きの.NN.json接尾辞:file_name.00.json、file_name.01.jsonなどに書き込みます。詳細:https://dev.mysql.com/doc/refman/8.0/en/error-log-json.htmllog_sink_syseventlog:このライターは、log_error値に関係なく、システムログに書き込みます。log_sink_internal、log_sink_json、log_sink_test:これらのライターはコンソールに書き込みます。rdbmsTweetSYSスキーマの説明をする機会があったので、改めてMySQL5.7.21でSYSスキーマに関しての概要をまとめたのでご紹介。Information_Schemaを直接確認しないと取得出来無い情報もまだあるけれど、SYSスキーマを利用すれば簡単にMySQLの状態を確認出来、複雑なクエリーを使わないでもロックの状態、メモリーの状態、未使用のインデックス、起動してからの累積値だけれども遅いクエリー等が確認可能です。使われていないユーザーも多いけど、便利なので是非活用下さい。MySQL5.7.21の時点では以下のオブジェクトが存在します。sec)以下のスライドにまとめたので、詳細をご確認下さい。