スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

MySQL 8.0.19 new features roundup!

MySQL 8.0.19 new features roundup!

この記事では、2020/01/18時点の最新リリースである8.0.19で実装された新機能の一部についてご紹介します。

8.0.19新機能の完全なリストは以下をご確認ください。

Changes in MySQL 8.0.19 (2020-01-13, General Availability)

また、弊社では OSSニュースにMySQLを主とした各製品のリリースノートの翻訳記事を投稿しています。
こちらでより網羅的な内容を確認することができますので、ぜひご確認ください!

これまでの記事は以下をご参照ください。

ユーザアカウントへのログイン失敗許容回数の設定

これまでにも明示的にアカウントをロックすることはできましたが、ログイン失敗回数を条件にロックすることが可能となりました。

Failed-Login Tracking and Temporary Account Locking

CREATE/ALTER USER文に以下の2つの構文を使用します。

構文 説明
FAILED_LOGIN_ATTEMPTS N ログイン失敗回数の上限。この数を超えてログインに失敗した場合、一定期間アカウントはロックされる
PASSWORD_LOCK_TIME {N or UNBOUNDED} FAILED_LOGIN_ATTEMPTS に達したアカウントをロックする期間。Nは日数です。UNBOUNDEDは明示的にロックを解除するまでロックされることを意味します。

現在のところPASSWORD_LOCK_TIMEには整数しか指定できないようで、最低1日はロックされるようです。

実際にログインに失敗してみるとこのようになります。
1日はログインできない状態となりました。

しかしながら、mysql.userのaccount_lockedがYになっていませんでした。
そのため確認には実際にログインをしてみることが必要かもしれません。

ロックに失敗した回数や、ロックされる日数等はACL_USERクラスの変数に持っているようです。

ソースコード

興味がありましたらWLもご確認ください

なお、ロック回数は以下の条件でクリアされます。

  • サーバの再起動
  • FLUSH PRIVILEGESの実行
  • FAILED_LOGIN_ATTEMPTSに達する前にログインに成功
  • ロック期間の経過
  • ALTER USER ACCOUNT UNLOCKの実行
  • ALTER USERによるユーザ属性の再設定

この設定を管理用のユーザ等に設定することでよりセキュアな運用ができそうです。

システム関連スキーマ内のInnoDBテーブルについてのステータス変数の追加

システムスキーマ(mysql)内のInnoDBテーブルへの操作をトラッキングするステータス変数が追加されました。

  • Innodb_system_rows_read
  • Innodb_system_rows_inserted
  • Innodb_system_rows_deleted

既存のステータス変数(Innodb_rows_xxx)はシステムスキーマ、ユーザスキーマの操作は区別されていなかったため、頻繁にシステムスキーマのテーブルにアクセスされる環境では解析が難しくなる状況がありました。

特にレプリケーション環境においてrelay_log_info_repository/master_info_repository をTABLEに設定している場合に、利用されるslave_master_info/slave_replay_log_info/slave_worker_infoはmysqlスキーマに属しており、比較的頻繁にR/Wが行なわれるということがありました。

上記の変数を実装したことでInnodb_rows_xxxステータス変数にはユーザスキーマのInnoDBに対するオペレーションのみがカウントされるようになりました。

test.t1 はユーザスキーマですのでInnodb_rows_insertedに加算されます。

システムスキーマへの更新を行うとInnodb_system_rows_insertedが加算されます。
例としてテーブルを追加します。
テーブルを追加するとシステムスキーマ内の各テーブルへのR/Wが行われます。

ロール関連情報の強化

INFORMATION_SCHEMAにいくつかのロールに関する情報を提供するテーブルが追加されました。

テーブル名 説明
ADMINISTRABLE_ROLE_AUTHORIZATIONS 他のユーザに適用可能であるかの情報を持つ現在のユーザが適用できるロールの一覧
APPLICABLE_ROLES 現在のユーザに適用可能なロールの一覧
ENABLED_ROLES 現在の接続で有効なロールの一覧
ROLE_COLUMN_GRANTS 現在のユーザに適用されているロールがアクセス可能な列の一覧
ROLE_ROUTINE_GRANTS 現在のユーザに適用されているロールがアクセス可能なルーチンの一覧
ROLE_TABLE_GRANTS 現在のユーザに適用されているロールがアクセス可能なテーブルの一覧

今までは SHOW GRANTS FOR 'rolename' を実行して権限を確認する必要がありましたので、より管理上の利便性が高まったのではないでしょうか。

ログローテーションがログイン不要に

8.0.19からは、SIGUSR1 シグナルをmysqldに実行することで、ログイン不要でログのフラッシュが可能となりました。
対象のログは、エラーログ、一般ログ、スロークエリログです。

そのためmysqlクライアントを使用する必要がなくなります。
これは地味に嬉しい機能です。
なお、これまでも SIGHUP でフラッシュすることはできましたが、フラッシュ対象が広く運用中の実行は望ましくないものでした。

Unix Signal Handling in MySQL

例として、これまでの/etc/logrotate.d/mysql は以下のようになります。

8.0.19からは以下のようにすることが可能です。

TABLE, VALUE ステートメントが実装

SQL標準に従いTABLE, VALUE ステートメントが実装されました。

TABLE句はSELECTから射影の部分を抜いたようなSQLで、例えば以下のSQLはいずれも同じ結果を返します。

  • TABLE t ORDER BY c LIMIT 10 OFFSET 3;
  • SELECT * FROM t ORDER BY c LIMIT 10 OFFSET 3;

実行例は以下です。

SELECTと同じように、他のSQLと組み合わせて使用する事も可能です。

VALUES..ROW句は、INSERT等の値に複数レコードを指定する場合などに使用する句です。

また、VALUES..ROW句を使用して擬似的なテーブルを表現する事も可能です。

その他の重要な新機能

  • Windowsのmysqlクライアントでsystemコマンドが実行可能になりました。
  • JSON_SCHEMA_VALID()でエラー詳細が提供されるようになりました
  • Group Replication接続は、max_connectionsが考慮する接続から除外されました
  • 以前のDuplicate entryエラーにはキー名と値のみが表示されていましたが、テーブル名が含まれるようになりました
  • マルチスレッドスレーブ(slave_parallel_workers)の設定を行う際に、以前はスレーブ側でのlog_bin, log_slave_updatesの有効化が必要でしたが、これが不要となりました。これによりスレーブでバイナリログを出力する必要がなくなりました。
  • レプリケーションチャネルの設定にREQUIRE_ROW_FORMAT(行形式のバイナリログのみを受け入れる)が追加されました。
  • InnoDBテーブルの独自のサンプリング実装が行われました。これにより統計情報がより効率的に更新されるようになりました。

番外

MySQL Shell 8.0.19では、従来のレプリケーション環境をReplica Setとしてデプロイ、管理する機能が追加されています。

https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-replicasets-introduction.html

非常に興味深い機能ですので、いつか別の機会でご紹介できればと思います。

まとめ

今回ご紹介させて頂いた機能以外にも数多くの改善が行われています。
興味がありましたら、ぜひリリースノートを確認してみてください。
MySQL 8.0の進化はめざましく、今後も要チェックです!


MySQL

 

Return Top