MySQL memorandum

MySQL で踏み抜いたものメモ。網羅したものではないので、あくまで参考までに。

Group replication まわり

メモリ使用量

innodb のデフォルト値が用途に対して大きすぎたので、減量した。

[mysqld]
innodb_buffer_pool_size = 33554432
innodb_buffer_pool_chunk_size = 33554432

group_replication_message_cache_size が 8.0.16 で導入され、最低限 1GB 確保されてしまうようになった。

virtual size が大きい

設定可能な値とは別に、OS 側から見て確保されているメモリ量は、予想以上に大きい。これは Linux のメモリアロケータの性質上、そういうことになるようだ。それにしても VSZ が実メモリの 90% ぐらいにおさまるように（best practice）、と言い始めると、なかなか厳しい。

以下は同様の構成で group replication を使ったときのメモリ消費量

• 8.0.15
  • memory/group_rpl/GCS_XCom::xcom_cache は 25 MiB
  • performance_schema.memory_summary_global_by_event_name で総計 380 MiB 程度
  • cgroup memory で 500 MiB 程度
  • mysqld VSZ=1207044 RSS=440932 (1.178 GiB, 430 MiB)
• 8.0.18
• memory/group_rpl/GCS_XCom::xcom_cache が 1 GiB 程度まで伸びて止まるのは想定通り。
• performance_schema.memory_summary_global_by_event_name で総計 1.3 GiB 程度
• cgroup memory で 1.7 GiB 程度
• mysqld VSZ=3173076 RSS=1442772 (3.098 GiB, 1.41 MiB)

8.0.21 から xcom cache のサイズを調整できるようになった。https://dev.mysql.com/doc/refman/8.0/en/group-replication-performance-xcom-cache-reduce.html

table repair

VM 上の MySQL が VM 再起動後に起動障害。
Error: Cannot load from mysql.proc. The table is probably corrupted
MySQL 設定ファイルに以下を追加して再起動すると修復される。

[mysqld]
upgrade=force

根本解決でもないし、そもそも常時付けるべきでもないオプションだと思う。

未解決

推測としては、メモリをたくさん使うようになって、逆に解放するのに時間がかかりすぎてタイムアウトを引き起こしている……とか？

[Warning] [MY-011648] [Repl] Plugin group_replication reported: 'While leaving the group due to a stop, shutdown or failure there was a timeout receiving a view change. This can lead to a possible inconsistent state. Check the log for more details'