兄弟，这大概率不是bug，而是Galera对gcache.size参数的修改有特殊限制——它不像gcache.recover或gcache.page_size那样重启就能生效，因为这个参数是和节点第一次启动时创建的galera.cache磁盘文件绑定死的：

核心原因 #

Galera的gcache是一种预分配的环形缓存，节点第一次初始化启动时会根据gcache.size的值在磁盘上创建固定大小的galera.cache文件。后续即使修改配置文件里的gcache.size并重启节点，Galera也只会复用已存在的缓存文件，不会重新调整它的大小。而gcache.recover和gcache.page_size属于运行时可调整（或重启生效）的参数，不受这个预分配限制，所以你修改它们能正常生效。

解决步骤 #

要成功调大gcache.size，你需要按以下步骤操作：

1. 确认gcache文件位置
   登录MariaDB执行以下命令，找到gcache.dir对应的路径（默认一般是/var/lib/mysql/）：

   SHOW GLOBAL VARIABLES LIKE 'wsrep_provider_options';
   

   对应的缓存文件名为galera.cache。

2. 停止所有集群节点
   确保所有节点完全停止，没有残留的MariaDB/Galera进程，可以用ps aux | grep mysql检查并清理。

3. 删除所有节点上的galera.cache文件
   比如默认路径下执行：

   rm /var/lib/mysql/galera.cache
   

   每个节点都要执行这一步，因为每个节点都有自己的本地缓存文件。

4. 确认my.cnf配置正确
   确保每个节点的my.cnf中，wsrep_provider_options是合并后的完整配置，不要拆分多个条目（否则后面的会覆盖前面的），比如：

   wsrep_provider_options="gcache.size=1G;gcache.page_size=1G;gcache.recover=yes"
   

5. 重新启动集群
   按正常集群启动顺序操作：

   • 先启动第一个节点，若需要初始化集群，启动时临时指定wsrep_cluster_address=gcomm://（比如在启动命令里加--wsrep_cluster_address=gcomm://，或者临时修改配置）；
   • 第一个节点启动完成后，再依次启动其他节点，指定集群地址（比如wsrep_cluster_address=gcomm://node1_ip,node2_ip）。

6. 验证修改结果
   登录任意节点执行以下命令，确认gcache.size已变为1G：

   SHOW GLOBAL VARIABLES LIKE 'wsrep_provider_options';
   

   同时检查磁盘上的galera.cache文件大小，应该接近1G（预分配文件会占用对应大小的磁盘空间）。

注意事项 #

• 一定要在所有节点都停止的情况下删除缓存文件，否则会导致节点无法加入集群或出现数据不一致问题；
• 如果集群需要持续提供服务，也可以采用滚动更新的方式：逐个停止节点，删除缓存文件、修改配置后重启并同步，完成一个再处理下一个，但这种方式需要确保集群始终有足够的节点维持quorum；
• 检查my.cnf中是否存在多个wsrep_provider_options条目，MariaDB只会读取最后一个，这是很多人配置出错的常见原因。

内容的提问来源于stack exchange，提问作者stoffel