MySQL Shell のログを活用しよう

この記事は最終更新から2年以上経過しています。内容が古くなっている可能性があります。

MySQL Shell を使用した事があっても、MySQL Shell のログファイルは見たことがない方もおられるのではないでしょうか。
MySQL Shell のログファイルはUnix系OSでは操作ユーザのホームディレクトリ配下 ~/.mysqlsh/mysqlsh.log に出力されます。
Windows系OSでは C:\Users\<ユーザ名>\AppData\Roaming\MySQL\mysqlsh\mysqlsh.log に出力され、保存先を変更したい場合は、いずれも環境変数 MYSQLSH_USER_CONFIG_HOME に出力先を設定する事でログファイルの保存先を変更できます。

先月GAとなった MySQL Shell 8.0.18 からAPI操作によって実行されるSQLステートメントが出力できるようになりました
これによって何が嬉しいかというと、例えば本ブログで何度か紹介している MySQL InnoDB Cluster のクラスタ作成・制御時に実行したコマンドが各ノードにどのようなステートメントを発行しているのかを確認したい場合、今までは各ノードの General Query Log を出力して確認したりする必要がありました。
それが、MySQL Shell のログを確認するだけで、どのノードにどのようなSQLステートメントが発行されているかを確認できるようになります。

具体的にどのような出力がされるのか、簡単に MySQL InnoDB Cluster を構築して確認してみます。

1. 構成

シングルプライマリモードとし、MySQL Shell は MySQL Router と同一サーバにインストールします。
サーバOSは全て CentOS7.5 となります。

ホスト名 IPアドレス 用途
mysqlrouter8018 192.168.33.25 MySQL Router
MySQL Shell
node8018-1 192.168.33.26 クラスタノード(プライマリ)
node8018-2 192.168.33.27 クラスタノード(セカンダリ)
node8018-3 192.168.33.28 クラスタノード(セカンダリ)

2. 構築

目次

2-1. 共通の設定

  • このセクションの設定内容は全てのノードで実行します。

SELinuxを無効にします。

各ノードのホスト情報を /etc/hosts に追加します。

MySQLの公式レポジトリを追加します。

2-2. クラスタノードの設定

  • このセクションの内容はクラスタノードとなる node8018-1 ~ node8018-3 の各ノードで実行します。

Firewalldが起動している場合はMySQL InnoDB Cluster で使用するポートを解放します。

MySQLサーバをインストールします。

my.cnf に最低限の必要な情報のみ設定しておきます。
server_idのみ各ノードで異なる値を設定します。

MySQLサーバを起動します。

MySQLサーバにログインし、root ユーザのパスワード変更と、MySQL Shellから実行するユーザを作成します。

2-3. MySQL Router + MySQL Shell の設定

  • このセクションの内容は mysqlrouter8018 ノードのみで実行します。

Firewalldが起動している場合はMySQL Router に必要なポートを解放します。

MySQL Router + MySQL Shell + MySQL Client をインストールします。


ここからは、MySQL Shell でクラスタを作成し、本題となるログ出力の確認となります。
MySQL Shell の –dba-log-sql オプションで MySQL Shell が発行するSQLステートメントの出力を制御します。

設定値 説明
0 SQLステートメントの出力をしない。(デフォルト)
1 SELECTステートメントと SHOWステートメントは出力しない。
2 実行するSQLステートメントを全て出力する。

2 を設定すると非常に多くのログが出力されるので、1 を設定して、まずはプライマリノード(node8018-1)にログインします。

クラスタの作成

dba.createCluster()でクラスタを作成してみます。

正常に完了したので、MySQL Shell のログファイル ~/.mysqlsh/mysqlsh.log を確認してみましょう。

node8018-1 で group_replication プラグインのインストールやグループレプリケーションユーザの作成、SET PERSIST ステートメントでグループレプリケーション関連のパラメータを設定している事がわかります。
また、クラスタのメタ情報等を保持するテーブルを mysql_innodb_cluster_metadata データベースに作成してレコードを管理している事も読み取れます。

クラスタにノードを追加

<cluster>.addInstance()で node8018-2 をクラスタに追加します。
recovery method には 8.0.17 で追加された Cloneプラグイン を選択してみます。

addInstance 時のログを確認してみましょう。

node8018-2 でCLONEプラグイン、グループレプリケーションの設定をし、node8018-1 に対してメタ情報を登録している事が分かります。

node8018-3 もクラスタに追加してみます。

追加した際のログを確認してみます。

node8018-2 を追加した際と特に変わりのある操作はないようです。
SQLステートメントとして出力される事で具体的な操作内容が分かり易く、各ノードのログを確認する必要もなくお手軽に確認できるのが嬉しいですね。

折角なので、MySQL Routerからクラスタノードにアクセスするまで確認しておきます。

正常にクラスタノードが稼働している事が確認できます。

続いて MySQL Router を起動し、アクセスしてみましょう。

6446ポートへのアクセスがプライマリノードへ、6447ポートへのアクセスがセカンダリノードへ振り分けられていますね。

まとめ

MySQL Shell で InnoDB Cluster を操作するコマンドは、リファレンスに言葉としての説明はありますが、自分が思ったような挙動をしない場合もありました。
そんな時は、今回確認した --dba-log-sql オプションで実行しているSQLステートメントをログに出力して確認する事で、内部的な動作を理解するのに役立つように思います。

SQLステートメントを出力する以外にも、–log-level オプションでデフォルト設定より詳細なログ情報を出力する事もできるので、困った時は MySQL Shell のログを確認してみましょう。

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次