Analyze Tableがレプリケートされない様にNO_WRITE_TO_BINLOGオプションを付けた場合の
バイナリーログの確認。殆どのケースで参照側でAnalyzeが実行されても問題は無いと思うが、
サンプリングのオーバーヘッドが無い訳ではないので、念のためのオプションとして。

By default, the server writes ANALYZE TABLE statements to the binary log so that they replicate to replicas. To suppress logging, specify the optional NO_WRITE_TO_BINLOG keyword or its alias LOCAL.

13.7.3.1 ANALYZE TABLE Statement

マスターログの確認

mysql> show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | …

In Case of MySQL

MySQL8.0.13のリリースノートに以下の記載があったので部分的ではありますが、CREATE TEMPORARYテーブルをトランザクション内で実行し確認してみました。

Previously, CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE statements were not supported inside transactions, procedures, functions, or triggers when using GTIDs (that is, when the enforce_gtid_consistency system variable is set to ON). It was possible to use these statements with GTIDs enabled, but only outside of any transaction, and only with autocommit=1.

From MySQL 8.0.13, this restriction has been removed when binlog_format is set to ROW or MIXED. With row-based logging in use, CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE statements can now be used inside transactions, procedures, functions, or triggers when GTIDs are enabled. When binlog_format is set to STATEMENT, the restriction remains. Because of …

そのため、MySQLのグループレプリケーションはMySQL 5.7で生まれました。 人々がそれについてもっと質問し始めている間今それは少し出ています。

• https://dev.mysql.com/doc/refman/8.0/en/group-replication.html
• …

MySQL用のコネクター、Connector/Jの動作を改めて確認してみました。
検証した内容としては、jdbc:mysql、jdbc:mysql:replication、jdbc:mysql＋ReplicationDriver, jdbc:mysql:loadbalanceの接続方法による挙動の違い。

検証環境：
Connector/J:　mysql-connector-java-community-5.1.36-bin.jar
MySQL環境：　 mysql 5.7.21 でグループレプリケーション（シングルマスターモード）

-bash-4.2$ ./gr_mysql_status.sh
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 1d69db5d-a273-11e8-b673-080027d65c57 | …

MySQL5.7までのSHOW SLAVE STATUSだけでは分からない事が多かったけど、MySQL8.0のSHOW SLAVE STATUSは少し改善されていた。
マスター側で負荷をかけて、スレーブの状態を確認した時にスレーブ側で”Systetm lock”という状態になっていて、詳細を確認する為にPerformance Schemaを確認してみた。
MySQL8.0からはPerformance_Schemaを確認しなくても”Slave_SQL_Running_State”で状態が確認出来るようになっている。
以下、MySQL8.0で確認したログですが、MySQL5.7では”System lock”だった状態が、MySQL8.0では”Applying batch of row changes (update)”になっています。

[admin@misc02 ~]$ cat repli_log | grep Slave_SQL_Running_State
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates …

MySQL Group Replicationは、グループで一つのIDを持つ為、通常のシングルインスタンスと同じようにレプリケーションを組む事が出来ます。4月のInnoDB Clusterリリース以降、MySQLを利用されているお客様から、幾つか質問を受けていたので念の為に挙動を再確認。

環境
複数サーバーを準備出来なかったので,シングサーバーにポートを変更して、2グループ(6サーバー)で先ずはGROUP REPLICATIONを準備。

mysql> select @@version;
+-------------------------------------------+
| @@version                                 |
+-------------------------------------------+
| 5.7.18-enterprise-commercial-advanced-log |
+-------------------------------------------+
1 row in set (0.00 sec)

…

MySQL5.7からslave_parallel_workersを調整してスレーブの遅延が対応出来る事は、
色々な資料やブログ等にも書かれているので詳細はそちらを確認してみて下さい。
Oracle MySQL Cloud Service(OC3 = 2vCPU)の環境でSQLSLAPで負荷をかけてみて、
マスターとスレーブで遅延がどれだけ解消できるか？若しくはどこまで調整すれば良いか確認してみました。
slave_parallel_workersを1,2,4,8,16,32と変更して確認した中では、slave_parallel_workers=8が安定していました。
但し、slave_parallel_workersが多いからと言ってCPUが少ないインスタンスより上がる訳では無く、全体的なシステムのバランスが重要なようです。
スレーブのCPUや実行されているQuery等を確認して、適宜最適な値を調整出来ると良いですね。

環境
…

今月の頭、詳解MySQL 5.7の出版記念第一弾として、MyNA（日本MySQLユーザ会）名義でイベントを行ったので、その際使用したスライドを紹介しておこう。今回紹介した新機能のカテゴリは2つ。レプリケーションとセキュリティである。レプリケーションはMySQLの運用と切っても切り離せないほど重要なものであり、そしてデータベースサーバーにとってセキュリティが重要であることは、言うまでもないだろう。

レプリケーション What's New in MySQL 5.7 Replication from Mikiya Okuno 今回のバージョンでは、レプリケーションが大きく進化している。

まず、MySQL 5.7では、レプリケーションのトポロジの限界を打ち破った！！MySQL …

MySQL5.7から実装された、マルチソースレプリケーションに関しての質問も少しずつ増えてきたので、改めて基本的な挙動をこちらに纏めました。
基本的には、通常のレプリケーションの挙動と変わりませんが、CHANNELに分けて1台のスレーブが複数マスターからのログを受け取るので、運用上、気を付けないといけない部分が増えてくるので、リカバリー含むPOCはしておいた方が安心です。

■ マスター側の設定（複数マスターサーバー全体でサーバーID以外は同じ)
※　マスター側は通常のレプリケーションの設定をしています。(サーバーID, バイナリーログ等)
※　ログポジションベース、GTIDモードどちらも可能ですが、今回はGTIDで設定しています。
…

先日、ご紹介させて頂いた、MySQL Enterprise Firewallを利用する事により、
White ListベースのDBアクセス制御(ステートメントベース)をUserアカウントとSQLステートメントの
組み合わせで実装する事が出来ますが、Publicクラウドを含む環境でWebサイトを運用されている場合は、Replication機能と組み合わせてご利用される場合もあるかと思います。

MySQL Enterprise Firewallには、全部で4つのテーブルがありますが、
(Information_Schemaに2つMySQLに2つテーブルが準備されています)
information_schemaにあるテーブルに関しては、レプリケーション対象外なので実際にSlaveに同期されるのは以下の2つのテーブルという事になります。

…