Mariadb 10.4 Galera 集群缺少交换内存
Lack of swap memory on Mariadb 10.4 Galera cluster
我有 3 个节点的 Galera 集群和 MariaDB 10.4.13。每个节点都有 32GB RAM 和 2GB Swap。在我大约 1 个月前 mysql 调整后，每个节点内存几乎已满，但我认为还可以。但是最近几天 Swap 大小达到了最大值并且没有下降。我的 my.cnf 看起来像这样：
####慢记录
slow_query_log_file=/var/lib/mysql/mysql-slow.log
long_query_time=2
slow_query_log=开启
log_queries_not_using_indexes=开启
############ INNODB 选项
innodb_buffer_pool_size=24000M
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_data_file_path=ibdata1:100M:自动扩展
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_doublewrite=1
innodb_log_file_size=6144M
innodb_log_buffer_size=96M
innodb_buffer_pool_instances=24
innodb_log_files_in_group=2
innodb_thread_concurrency=0
#### innodb_file_format = 梭鱼
innodb_flush_method = O_DIRECT
#### innodb_locks_unsafe_for_binlog = 1
innodb_autoinc_lock_mode=2
######## 避免在执行例如显示表格时更新统计信息
innodb_stats_on_metadata=0
default_storage_engine=innodb
innodb_strict_mode = 0
#### 其他内容，缓冲区等
#### key_buffer_size = 24M
tmp_table_size = 1024M
max_heap_table_size = 1024M
max_allowed_packet = 512M
#### sort_buffer_size = 256K
#### read_buffer_size = 256K
#### read_rnd_buffer_size = 512K
#### myisam_sort_buffer_size = 8M
skip_name_resolve
内存锁=0
sysdate_is_now=1
max_connections=500
thread_cache_size=512
query_cache_type = 1
query_cache_size = 512M
query_cache_limit=512K
join_buffer_size = 1M
table_open_cache = 116925
open_files_limit = 233850
table_definition_cache = 58863
table_open_cache_实例数 = 8
lower_case_table_names=0
有了这个配置，我希望 MariaDB 使用 maximum，只要它不是关键的。
我想查看此配置，并可能禁用 query_cache 部分，并调整 InnoDB 值。请给我一些建议，并让我知道交换大小是否足够好，或者可能需要禁用 mysql 才能完全使用交换。
None 这些肯定太大了，但可能会发生一些事情使它们太大，尤其是合并时：
innodb_buffer_pool_size=24000M -- quick fix: lower this
(otherwise it should be a good size)
tmp_table_size = 1024M -- lower to 1% of RAM
max_heap_table_size = 1024M -- ditto
max_allowed_packet = 512M -- possibly too big
max_connections=500 -- lower to Max_used_connections or 100
query_cache_type = 1 -- 0 -- QC is not allowed on Galera
query_cache_size = 512M -- 0 -- ditto
table_open_cache = 116925 -- see how 2000 works
table_definition_cache = 58863 -- ditto
为了进一步分析，请提供 GLOBAL STATUS 和 VARIABLES 此处讨论：http://mysql.rjweb.org/doc.php/mysql_analysis#tuning
抱歉，我在这里没有看到太多令人兴奋的内容：
全局状态和变量分析：
观察：
- 版本：10.4.13-MariaDB-log
- 32 GB 内存
- 正常运行时间 = 1 天 15:19:41
- 您不在 Windows 上 运行。
- 运行 64 位版本
- 您似乎 运行 完全（或大部分）InnoDB。
更重要的问题：
低于建议值：
table_open_cache = 10000
tmp_table_size = 200M
max_heap_table_size = 200M
query_cache_size = 0 -- the high value you have can cause mysterious slowdowns
max_connections = 200
thread_cache_size = 20
I/O设置对于硬盘驱动器来说很漂亮；你有固态硬盘吗？
有很多 SHOW 命令 -- 每秒超过一个。也许某些监控工具过于激进？
为什么有这么多 GRANT？
这是在 Galera 集群中吗？
细节和其他观察：
( Key_blocks_used * 1024 / key_buffer_size ) = 48 * 1024 / 128M = 0.04% -- 已使用 key_buffer 的百分比。高水位线。
-- 降低 key_buffer_size（现在为 134217728）以避免不必要的内存使用。
( table_open_cache ) = 116,660 -- 要缓存的 table 个描述符的数量
-- 几百就可以了。
( Open_tables / table_open_cache ) = 4,439 / 116660 = 3.8% -- 缓存使用（open tables + tmp tables）
-- 可选择降低 table_open_cache（现在为 116660）
( innodb_buffer_pool_instances ) = 24 -- 对于大内存，考虑使用1-16个缓冲池实例，每个实例不允许小于1GB。此外，不超过 CPU 核心数量的两倍。
-- 推荐不要超过16。（10.5开始消失）
( innodb_lru_scan_depth * innodb_buffer_pool_instances ) = 1,024 * 24 = 24,576 -- CPU 使用量的指标。
-- 降低其中一个数字。
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096 -- 页面清理器每秒的工作量。
-- "InnoDB: page_cleaner: 1000ms intended loop take ..." 可以通过降低 lru_scan_depth 来修复：考虑 1000 / innodb_page_cleaners（现在是 4）。还要检查交换。
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 24 = 0.167 -- innodb_page_cleaners
-- 建议将 innodb_page_cleaners（现在为 4）设置为 innodb_buffer_pool_instances（现在为 24）
（10.5开始消失）
( innodb_lru_scan_depth ) = 1,024
-- "InnoDB: page_cleaner: 1000ms intended loop take ..." 可以通过降低 lru_scan_depth
来修复
( innodb_io_capacity ) = 200 -- 刷新时，使用这么多 IOP。
-- 读取可能缓慢或不稳定。
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 1,065,507 / 1538880 = 69.2% -- 当前未使用的 buffer_pool 的百分比
-- innodb_buffer_pool_size（现在是 25769803776）是否比需要的大？
( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10 -- 容量：max/plain
-- 推荐 2。Max 应该大约等于您的 I/O 子系统可以处理的 IOP。 （如果驱动器类型未知，2000/200 可能是一个合理的组合。）
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 7,641,841,664 / 24576M = 29.7% -- 数据占用缓冲池的百分比
-- 一小部分 可能 表示 buffer_pool 过大。
( innodb_log_buffer_size ) = 96M -- 建议 2MB-64MB，并且至少与事务中最大的 blob 集一样大。
-- 调整innodb_log_buffer_size（现在100663296）。
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 141,581 / 60 * 6144M / 2470192128 = 6,154 -- InnoDB 日志轮换之间的分钟数 从 5.6.8 开始，可以动态更改；请务必也更改 my.cnf。
--（轮换间隔 60 分钟的建议有些武断。）调整 innodb_log_file_size（现在为 6442450944）。 （无法在 AWS 中更改。）
( default_tmp_storage_engine ) = default_tmp_storage_engine =
( innodb_flush_neighbors ) = 1 -- 将块写入磁盘时的一个小优化。
-- SSD 驱动器使用 0； 1 个用于硬盘。
( innodb_io_capacity ) = 200 - I/O 磁盘上的每秒操作数。 100 用于慢速驱动器； 200 用于旋转驱动器； SSD 1000-2000；乘以 RAID 系数。
( sync_binlog ) = 0 -- 使用 1 以增加安全性，但 I/O =1 可能会导致很多“查询结束”； =0 可能会导致“binlog at impossible position”并在崩溃中丢失事务，但速度更快。
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- 是否记录所有死锁。
-- 如果您为死锁所困扰，请打开它。注意：如果有很多死锁，这可能会向磁盘写入大量内容。
( min( tmp_table_size, max_heap_table_size ) ) = (min( 1024M, 1024M )) / 32768M = 3.1% -- 当需要 MEMORY table (per table) 或 temp table inside a SELECT (per温度 table 每 SELECTs）。太高可能导致交换。
-- 将 tmp_table_size（现在为 1073741824）和 max_heap_table_size（现在为 1073741824）减少到 ram 的 1%。
( character_set_server ) = character_set_server = latin1
-- 将 character_set_server（现在是 latin1）设置为 utf8mb4 可能有助于解决字符集问题。那是未来的默认。
( local_infile ) = local_infile = ON
-- local_infile（现在开启）= 开启是一个潜在的安全问题
( query_cache_size ) = 512M -- QC 的大小
-- 太小 = 没有多大用处。太大 = 开销太大。建议0或不超过50M。
( Qcache_hits / (Qcache_hits + Com_select) ) = 8,821 / (8821 + 5602645) = 0.16% -- 命中率 -- SELECT使用QC的
-- 考虑关闭查询缓存。
( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (512M - 48787272) / 224183 / 16384 = 0.133 -- query_alloc_block_size vs 公式
-- 调整query_alloc_block_size（现在16384）
( tmp_table_size ) = 1024M -- 用于支持 SELECT 的 MEMORY temp table 的大小限制
-- 减少 tmp_table_size（现在为 1073741824）以避免 运行 内存不足。可能不会超过64M。
( Com_admin_commands / Queries ) = 888,691 / 6680823 = 13.3% -- 属于“admin”命令的查询百分比。
-- 怎么回事？
( Slow_queries / Questions ) = 438,188 / 6557866 = 6.7% -- 频率（占所有查询的百分比）
-- 查找慢查询；检查索引。
( log_queries_not_using_indexes ) = log_queries_not_using_indexes = ON -- 是否在 slowlog 中包含这样的内容。
-- 这会使慢日志变得混乱；将其关闭，以便您可以看到真正的慢速查询。并减少 long_query_time（现在为 2）以捕获最有趣的查询。
( Uptime_since_flush_status ) = 451 = 7m 31s -- 自 FLUSH STATUS（或服务器启动）以来的时间（以秒为单位）。
-- 全球状态的收集时间还不够长，无法针对许多问题获得可靠的建议。修复你能修复的，然后在几个小时后回来。
( Max_used_connections / max_connections ) = 25 / 500 = 5.0% -- 连接的峰值百分比
-- 由于可以根据 max_connections（现在为 500）扩展多个内存因子，因此最好不要将该设置设置得太高。
( thread_cache_size / Max_used_connections ) = 500 / 25 = 2000.0%
-- 线程缓存大于您可能的连接数没有任何优势。浪费space是劣势
异常小：
Innodb_dblwr_pages_written / Innodb_dblwr_writes = 2.28
aria_checkpoint_log_activity = 1.05e+6
aria_pagecache_buffer_size = 128MB
innodb_buffer_pool_chunk_size = 128MB
innodb_max_undo_log_size = 10MB
innodb_online_alter_log_max_size = 128MB
innodb_sort_buffer_size = 1.05e+6
innodb_spin_wait_delay = 4
lock_wait_timeout = 86,400
performance_schema_max_mutex_classes = 0
query_cache_limit = 524,288
异常大：
Acl_column_grants = 216
Acl_database_grants = 385
Acl_table_grants = 1,877
Innodb_buffer_pool_pages_free = 1.07e+6
Innodb_num_open_files = 9,073
Memory_used_initial = 8.16e+8
Open_table_definitions = 4,278
Open_tables = 4,439
Performance_schema_file_instances_lost = 1,732
Performance_schema_mutex_classes_lost = 190
Performance_schema_table_handles_lost = 570
Qcache_free_blocks = 9,122
Qcache_total_blocks = 457,808
Tc_log_page_size = 4,096
Uptime - Uptime_since_flush_status = 141,130
aria_sort_buffer_size = 256.0MB
auto_increment_offset = 3
gtid_domain_id = 12,000
innodb_open_files = 116,660
max_heap_table_size = 1024MB
max_relay_log_size = 1024MB
min(max_heap_table_size, tmp_table_size) = 1024MB
performance_schema_events_stages_history_size = 20
performance_schema_events_statements_history_size = 20
performance_schema_events_waits_history_size = 20
performance_schema_max_cond_classes = 90
table_definition_cache = 58,863
table_open_cache / max_connections = 233
tmp_memory_table_size = 1024MB
wsrep_cluster_size = 3
wsrep_gtid_domain_id = 12,000
wsrep_local_bf_aborts = 107
wsrep_slave_threads = 32
wsrep_thread_count = 33
字符串异常：
aria_recover_options = BACKUP,QUICK
disconnect_on_expired_password = OFF
gtid_ignore_duplicates = ON
gtid_strict_mode = ON
histogram_type = DOUBLE_PREC_HB
innodb_fast_shutdown = 1
myisam_stats_method = NULLS_UNEQUAL
old_alter_table = DEFAULT
opt_s__optimize_join_buffer_size = on
optimizer_trace = enabled=off
use_stat_tables = PREFERABLY_FOR_QUERIES
wsrep_cluster_status = Primary
wsrep_connected = ON
wsrep_debug = NONE
wsrep_gtid_mode = ON
wsrep_load_data_splitting = OFF
wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so
wsrep_provider_name = Galera
wsrep_provider_options = base_dir = /var/lib/mysql/; base_host = FIRST_NODE_IP; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT7.5S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 1; evs.view_forget_timeout = P1D; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = galera.cache; gcache.page_size = 128M; gcache.recover = yes; gcache.size = 1024M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.segment = 0; gmcast.time_wait = PT5S; gmcast.version = 0; ist.recv_addr = FIRST_NODE_IP; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.recovery = true; pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = PT30S; pc.weight = 1; protonet.backend = asio; protonet.version = 0; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.max_ws_size = 2147483647; repl.proto_max = 10; socket.checksum = 2; socket.recv_buf_size = auto; socket.send_buf_size = auto;
wsrep_provider_vendor = Codership Oy
wsrep_provider_version = 26.4.4(r4599)
wsrep_replicate_myisam = ON
wsrep_sst_auth = ********
wsrep_sst_method = mariabackup
wsrep_start_position = 353e0616-cb37-11ea-b614-be241cab877e:39442474
我有 3 个节点的 Galera 集群和 MariaDB 10.4.13。每个节点都有 32GB RAM 和 2GB Swap。在我大约 1 个月前 mysql 调整后，每个节点内存几乎已满，但我认为还可以。但是最近几天 Swap 大小达到了最大值并且没有下降。我的 my.cnf 看起来像这样：
####慢记录
slow_query_log_file=/var/lib/mysql/mysql-slow.log
long_query_time=2
slow_query_log=开启
log_queries_not_using_indexes=开启
############ INNODB 选项
innodb_buffer_pool_size=24000M
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_data_file_path=ibdata1:100M:自动扩展
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_doublewrite=1
innodb_log_file_size=6144M
innodb_log_buffer_size=96M
innodb_buffer_pool_instances=24
innodb_log_files_in_group=2
innodb_thread_concurrency=0
#### innodb_file_format = 梭鱼
innodb_flush_method = O_DIRECT
#### innodb_locks_unsafe_for_binlog = 1
innodb_autoinc_lock_mode=2
######## 避免在执行例如显示表格时更新统计信息
innodb_stats_on_metadata=0
default_storage_engine=innodb
innodb_strict_mode = 0
#### 其他内容，缓冲区等
#### key_buffer_size = 24M
tmp_table_size = 1024M
max_heap_table_size = 1024M
max_allowed_packet = 512M
#### sort_buffer_size = 256K
#### read_buffer_size = 256K
#### read_rnd_buffer_size = 512K
#### myisam_sort_buffer_size = 8M
skip_name_resolve
内存锁=0
sysdate_is_now=1
max_connections=500
thread_cache_size=512
query_cache_type = 1
query_cache_size = 512M
query_cache_limit=512K
join_buffer_size = 1M
table_open_cache = 116925
open_files_limit = 233850
table_definition_cache = 58863
table_open_cache_实例数 = 8
lower_case_table_names=0
有了这个配置，我希望 MariaDB 使用 maximum，只要它不是关键的。 我想查看此配置，并可能禁用 query_cache 部分，并调整 InnoDB 值。请给我一些建议，并让我知道交换大小是否足够好，或者可能需要禁用 mysql 才能完全使用交换。
None 这些肯定太大了，但可能会发生一些事情使它们太大，尤其是合并时：
innodb_buffer_pool_size=24000M -- quick fix: lower this
(otherwise it should be a good size)
tmp_table_size = 1024M -- lower to 1% of RAM
max_heap_table_size = 1024M -- ditto
max_allowed_packet = 512M -- possibly too big
max_connections=500 -- lower to Max_used_connections or 100
query_cache_type = 1 -- 0 -- QC is not allowed on Galera
query_cache_size = 512M -- 0 -- ditto
table_open_cache = 116925 -- see how 2000 works
table_definition_cache = 58863 -- ditto
为了进一步分析，请提供 GLOBAL STATUS 和 VARIABLES 此处讨论：http://mysql.rjweb.org/doc.php/mysql_analysis#tuning
抱歉，我在这里没有看到太多令人兴奋的内容：
全局状态和变量分析：
观察：
- 版本：10.4.13-MariaDB-log
- 32 GB 内存
- 正常运行时间 = 1 天 15:19:41
- 您不在 Windows 上 运行。
- 运行 64 位版本
- 您似乎 运行 完全（或大部分）InnoDB。
更重要的问题：
低于建议值：
table_open_cache = 10000
tmp_table_size = 200M
max_heap_table_size = 200M
query_cache_size = 0 -- the high value you have can cause mysterious slowdowns
max_connections = 200
thread_cache_size = 20
I/O设置对于硬盘驱动器来说很漂亮；你有固态硬盘吗？
有很多 SHOW 命令 -- 每秒超过一个。也许某些监控工具过于激进？
为什么有这么多 GRANT？
这是在 Galera 集群中吗？
细节和其他观察：
( Key_blocks_used * 1024 / key_buffer_size ) = 48 * 1024 / 128M = 0.04% -- 已使用 key_buffer 的百分比。高水位线。
-- 降低 key_buffer_size（现在为 134217728）以避免不必要的内存使用。
( table_open_cache ) = 116,660 -- 要缓存的 table 个描述符的数量
-- 几百就可以了。
( Open_tables / table_open_cache ) = 4,439 / 116660 = 3.8% -- 缓存使用（open tables + tmp tables）
-- 可选择降低 table_open_cache（现在为 116660）
( innodb_buffer_pool_instances ) = 24 -- 对于大内存，考虑使用1-16个缓冲池实例，每个实例不允许小于1GB。此外，不超过 CPU 核心数量的两倍。
-- 推荐不要超过16。（10.5开始消失）
( innodb_lru_scan_depth * innodb_buffer_pool_instances ) = 1,024 * 24 = 24,576 -- CPU 使用量的指标。
-- 降低其中一个数字。
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096 -- 页面清理器每秒的工作量。
-- "InnoDB: page_cleaner: 1000ms intended loop take ..." 可以通过降低 lru_scan_depth 来修复：考虑 1000 / innodb_page_cleaners（现在是 4）。还要检查交换。
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 24 = 0.167 -- innodb_page_cleaners
-- 建议将 innodb_page_cleaners（现在为 4）设置为 innodb_buffer_pool_instances（现在为 24）
（10.5开始消失）
( innodb_lru_scan_depth ) = 1,024
-- "InnoDB: page_cleaner: 1000ms intended loop take ..." 可以通过降低 lru_scan_depth
( innodb_io_capacity ) = 200 -- 刷新时，使用这么多 IOP。
-- 读取可能缓慢或不稳定。
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 1,065,507 / 1538880 = 69.2% -- 当前未使用的 buffer_pool 的百分比
-- innodb_buffer_pool_size（现在是 25769803776）是否比需要的大？
( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10 -- 容量：max/plain
-- 推荐 2。Max 应该大约等于您的 I/O 子系统可以处理的 IOP。 （如果驱动器类型未知，2000/200 可能是一个合理的组合。）
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 7,641,841,664 / 24576M = 29.7% -- 数据占用缓冲池的百分比
-- 一小部分 可能 表示 buffer_pool 过大。
( innodb_log_buffer_size ) = 96M -- 建议 2MB-64MB，并且至少与事务中最大的 blob 集一样大。
-- 调整innodb_log_buffer_size（现在100663296）。
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 141,581 / 60 * 6144M / 2470192128 = 6,154 -- InnoDB 日志轮换之间的分钟数 从 5.6.8 开始，可以动态更改；请务必也更改 my.cnf。
--（轮换间隔 60 分钟的建议有些武断。）调整 innodb_log_file_size（现在为 6442450944）。 （无法在 AWS 中更改。）
( default_tmp_storage_engine ) = default_tmp_storage_engine =
( innodb_flush_neighbors ) = 1 -- 将块写入磁盘时的一个小优化。
-- SSD 驱动器使用 0； 1 个用于硬盘。
( innodb_io_capacity ) = 200 - I/O 磁盘上的每秒操作数。 100 用于慢速驱动器； 200 用于旋转驱动器； SSD 1000-2000；乘以 RAID 系数。
( sync_binlog ) = 0 -- 使用 1 以增加安全性，但 I/O =1 可能会导致很多“查询结束”； =0 可能会导致“binlog at impossible position”并在崩溃中丢失事务，但速度更快。
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- 是否记录所有死锁。
-- 如果您为死锁所困扰，请打开它。注意：如果有很多死锁，这可能会向磁盘写入大量内容。
( min( tmp_table_size, max_heap_table_size ) ) = (min( 1024M, 1024M )) / 32768M = 3.1% -- 当需要 MEMORY table (per table) 或 temp table inside a SELECT (per温度 table 每 SELECTs）。太高可能导致交换。
-- 将 tmp_table_size（现在为 1073741824）和 max_heap_table_size（现在为 1073741824）减少到 ram 的 1%。
( character_set_server ) = character_set_server = latin1
-- 将 character_set_server（现在是 latin1）设置为 utf8mb4 可能有助于解决字符集问题。那是未来的默认。
( local_infile ) = local_infile = ON
-- local_infile（现在开启）= 开启是一个潜在的安全问题
( query_cache_size ) = 512M -- QC 的大小
-- 太小 = 没有多大用处。太大 = 开销太大。建议0或不超过50M。
( Qcache_hits / (Qcache_hits + Com_select) ) = 8,821 / (8821 + 5602645) = 0.16% -- 命中率 -- SELECT使用QC的
-- 考虑关闭查询缓存。
( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (512M - 48787272) / 224183 / 16384 = 0.133 -- query_alloc_block_size vs 公式
-- 调整query_alloc_block_size（现在16384）
( tmp_table_size ) = 1024M -- 用于支持 SELECT 的 MEMORY temp table 的大小限制
-- 减少 tmp_table_size（现在为 1073741824）以避免 运行 内存不足。可能不会超过64M。
( Com_admin_commands / Queries ) = 888,691 / 6680823 = 13.3% -- 属于“admin”命令的查询百分比。
-- 怎么回事？
( Slow_queries / Questions ) = 438,188 / 6557866 = 6.7% -- 频率（占所有查询的百分比）
-- 查找慢查询；检查索引。
( log_queries_not_using_indexes ) = log_queries_not_using_indexes = ON -- 是否在 slowlog 中包含这样的内容。
-- 这会使慢日志变得混乱；将其关闭，以便您可以看到真正的慢速查询。并减少 long_query_time（现在为 2）以捕获最有趣的查询。
( Uptime_since_flush_status ) = 451 = 7m 31s -- 自 FLUSH STATUS（或服务器启动）以来的时间（以秒为单位）。
-- 全球状态的收集时间还不够长，无法针对许多问题获得可靠的建议。修复你能修复的，然后在几个小时后回来。
( Max_used_connections / max_connections ) = 25 / 500 = 5.0% -- 连接的峰值百分比
-- 由于可以根据 max_connections（现在为 500）扩展多个内存因子，因此最好不要将该设置设置得太高。
( thread_cache_size / Max_used_connections ) = 500 / 25 = 2000.0%
-- 线程缓存大于您可能的连接数没有任何优势。浪费space是劣势
异常小：
Innodb_dblwr_pages_written / Innodb_dblwr_writes = 2.28
aria_checkpoint_log_activity = 1.05e+6
aria_pagecache_buffer_size = 128MB
innodb_buffer_pool_chunk_size = 128MB
innodb_max_undo_log_size = 10MB
innodb_online_alter_log_max_size = 128MB
innodb_sort_buffer_size = 1.05e+6
innodb_spin_wait_delay = 4
lock_wait_timeout = 86,400
performance_schema_max_mutex_classes = 0
query_cache_limit = 524,288
异常大：
Acl_column_grants = 216
Acl_database_grants = 385
Acl_table_grants = 1,877
Innodb_buffer_pool_pages_free = 1.07e+6
Innodb_num_open_files = 9,073
Memory_used_initial = 8.16e+8
Open_table_definitions = 4,278
Open_tables = 4,439
Performance_schema_file_instances_lost = 1,732
Performance_schema_mutex_classes_lost = 190
Performance_schema_table_handles_lost = 570
Qcache_free_blocks = 9,122
Qcache_total_blocks = 457,808
Tc_log_page_size = 4,096
Uptime - Uptime_since_flush_status = 141,130
aria_sort_buffer_size = 256.0MB
auto_increment_offset = 3
gtid_domain_id = 12,000
innodb_open_files = 116,660
max_heap_table_size = 1024MB
max_relay_log_size = 1024MB
min(max_heap_table_size, tmp_table_size) = 1024MB
performance_schema_events_stages_history_size = 20
performance_schema_events_statements_history_size = 20
performance_schema_events_waits_history_size = 20
performance_schema_max_cond_classes = 90
table_definition_cache = 58,863
table_open_cache / max_connections = 233
tmp_memory_table_size = 1024MB
wsrep_cluster_size = 3
wsrep_gtid_domain_id = 12,000
wsrep_local_bf_aborts = 107
wsrep_slave_threads = 32
wsrep_thread_count = 33
字符串异常：
aria_recover_options = BACKUP,QUICK
disconnect_on_expired_password = OFF
gtid_ignore_duplicates = ON
gtid_strict_mode = ON
histogram_type = DOUBLE_PREC_HB
innodb_fast_shutdown = 1
myisam_stats_method = NULLS_UNEQUAL
old_alter_table = DEFAULT
opt_s__optimize_join_buffer_size = on
optimizer_trace = enabled=off
use_stat_tables = PREFERABLY_FOR_QUERIES
wsrep_cluster_status = Primary
wsrep_connected = ON
wsrep_debug = NONE
wsrep_gtid_mode = ON
wsrep_load_data_splitting = OFF
wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so
wsrep_provider_name = Galera
wsrep_provider_options = base_dir = /var/lib/mysql/; base_host = FIRST_NODE_IP; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT7.5S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 1; evs.view_forget_timeout = P1D; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = galera.cache; gcache.page_size = 128M; gcache.recover = yes; gcache.size = 1024M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.segment = 0; gmcast.time_wait = PT5S; gmcast.version = 0; ist.recv_addr = FIRST_NODE_IP; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.recovery = true; pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = PT30S; pc.weight = 1; protonet.backend = asio; protonet.version = 0; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.max_ws_size = 2147483647; repl.proto_max = 10; socket.checksum = 2; socket.recv_buf_size = auto; socket.send_buf_size = auto;
wsrep_provider_vendor = Codership Oy
wsrep_provider_version = 26.4.4(r4599)
wsrep_replicate_myisam = ON
wsrep_sst_auth = ********
wsrep_sst_method = mariabackup
wsrep_start_position = 353e0616-cb37-11ea-b614-be241cab877e:39442474