mysql永久修改变量_MySQL 8.0 新特性之持久化全局变量的修改

在MySQL 8.0之前,全局变量的修改不会持久化。但从8.0开始,使用`SET PERSIST`命令可以将变量修改持久化到配置文件中,如`mysqld-auto.cnf`,并记录在`performance_schema.persisted_variables`表中。修改会由系统变量管理员权限完成,`SET PERSIST_ONLY`则只持久化不修改内存值。清除持久化变量用`RESET PERSIST`,但不会影响已修改的变量值。此外,`set persist variable=default`可将变量设回默认值并持久化。

MySQL在8之前的版本中,对于全局变量的修改,其只会影响其内存值,而不会持久化到配置文件中。数据库重启,又会恢复成修改前的值。从8开始,可通过SET PERSIST命令将全局变量的修改持久化到配置文件中。

试举一例

mysql> show variables like '%max_connections%';

+------------------------+-------+

| Variable_name          | Value |

+------------------------+-------+

| max_connections        | 151  |

| mysqlx_max_connections | 100  |

+------------------------+-------+

2 rows in set (0.00 sec)

mysql> set persist max_connections=200;

Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%max_connections%';

+------------------------+-------+

| Variable_name          | Value |

+------------------------+-------+

| max_connections        | 200  |

| mysqlx_max_connections | 100  |

+------------------------+-------+

2 rows in set (0.00 sec)

全局变量的修改会保存在两处,

1.  数据目录下mysqld-auto.cnf文件,

注意,不是启动时--defaults-file指定的配置文件。

[root@slowtech ~]# cat /var/lib/mysql/mysqld-auto.cnf

{ "Version" : 1 , "mysql_server" : { "max_connections" : { "Value" : "200" , "Metadata" : { "Timestamp" : 1525509217566258 , "User" : "root" , "Host" : "localhost" } } } }

持久化信息以json格式保存,其中,Metadata记录了这次修改的用户及时间信息。

在数据库启动时,会首先读取其它配置文件,最后才读取mysqld-auto.cnf文件。不建议手动修改该文件,其有可能导致数据库在启动过程中因解析错误而失败。如果出现这种情况,可手动删除mysqld-auto.cnf文件或将persisted_globals_load变量设置为off来避免该文件的加载。

2. performance_schema.persisted_variables

mysql> select * from performance_schema.persisted_variables;

+-----------------+----------------+

| VARIABLE_NAME  | VARIABLE_VALUE |

+-----------------+----------------+

| max_connections | 200            |

+-----------------+----------------+

1 row in set (0.00 sec)

全局变量的持久化除了SET PERSIST外,还有SET PERSIST_ONLY,与前者相比,其只持久化全局变量,而不修改其内存值。同时,在权限方面,前者只需要SYSTEM_VARIABLES_ADMIN,后者还需要PERSIST_RO_VARIABLES_ADMIN权限。

对于已经持久化了变量,可通过RESET PERSIST命令清除掉,注意,其只是清空mysqld-auto.cnf和performance_schema.persisted_variables中的内容,对于已经修改了的变量的值,不会产生任何影响。

除此之外,还可以通过下述方式将全局变量持久化为默认值。注意,是默认值,而不是修改前的值。

mysql> set persist max_connections=default;

这个命令同“set global max_connections=default”类似,都会将变量的值设置为默认值,只不过前者还会将默认值持久化到配置文件中。

0b1331709591d260c1c78e86d0c51c18.png

<think>我们正在讨论MySQL8.0中gtid_executed表的持久化机制对主从重建的影响,以及如何正确处理gtid_purged和gtid_executed以恢复主从同步。以下内容基于引用材料。###一、MySQL8.0GTID持久化机制的核心变化在MySQL8.0中,`gtid_executed`的存储方式发生了重要变化:1.**新增`mysql.gtid_executed`表**:每次事务提交时,GTID会**实时写入**该表(InnoDB引擎),确保GTID信息持久化[^3][^4]。2.**内存变量与表的同步**:`gtid_executed`全局变量由`mysql.gtid_executed`表的内容初始化,并在事务提交时更新[^4]。3.**崩溃恢复机制**:MySQL启动时通过读取undo日志中的GTID信息来恢复`mysql.gtid_executed`表,保证数据一致性[^3]。```mermaidgraphTDA[事务提交]-->B[写入mysql.gtid_executed表]B-->C[更新gtid_executed内存变量]D[MySQL启动]-->E[读取undo日志恢复gtid_executed表]```###二、对主从重建的影响####1.**重置GTID的操作变化**-**`RESETMASTER`行为改变**:-MySQL5.7:`RESETMASTER`清空`gtid_executed`内存变量和binlog文件[^1]。-MySQL8.0:`RESETMASTER`会**同时清空**`mysql.gtid_executed`表和内存变量[^4]。```sql--在MySQL8.0执行:RESETMASTER;--清空表+内存+binlog```####2.**数据导入时的GTID处理**-**逻辑备份导入**(如mysqldump):-备份文件包含`SET@@GLOBAL.gtid_purged`语句,会直接写入`mysql.gtid_executed`表[^4]。-**冲突风险**:若表中已有GTID记录,导入会报错`ER_GTID_PURGED`。-**物理备份导入**(如xtrabackup):-需手动执行`SET@@GLOBAL.gtid_purged`,该操作会覆盖`mysql.gtid_executed`表[^4]。####3.**主从重建的关键步骤调整**在MySQL8.0中重建主从需额外处理持久化表:|步骤|MySQL5.7|MySQL8.0||------|-----------|-----------||停止从库复制|`STOPSLAVE;`|相同||重置GTID|`RESETMASTER;`(仅清内存)|`RESETMASTER;`(清表+内存)||导入数据|禁用binlog后导入|相同,但需注意`gtid_purged`写入表||重设`gtid_purged`|直接设置内存变量|需通过`SETGLOBALgtid_purged`写入表|###三、正确恢复主从同步的步骤(MySQL8.0)####步骤1:停止并重置从库```sqlSTOPSLAVE;RESETSLAVEALL;--清除复制链路RESETMASTER;--清空mysql.gtid_executed表及内存变量[^4]```####步骤2:导入主库全量备份```sqlSETsql_log_bin=0;--禁用binlogSOURCE/path/to/dump.sql;SETsql_log_bin=1;```**注意**:若使用物理备份,需手动设置GTID:```sqlSETGLOBALgtid_purged='主库gtid_executed值';--写入mysql.gtid_executed表[^4]```####步骤3:验证GTID状态```sqlSELECT@@GLOBAL.gtid_executed;--应与主库SHOWMASTERSTATUS一致SELECT*FROMmysql.gtid_executed;--检查表内容```####步骤4:重新建立复制```sqlCHANGEMASTERTOMASTER_HOST='主库IP',MASTER_AUTO_POSITION=1;STARTSLAVE;```###四、常见错误处理####错误1:`GTID_PURGEDcannotbesetwhenmysql.gtid_executedisnotempty`**原因**:`mysql.gtid_executed`表非空时无法设置`gtid_purged`。**解决**:先执行`RESETMASTER`清空表。####错误2:`SlavehasmoreGTIDsthanthemaster`**原因**:从库的`gtid_executed`包含主库`gtid_purged`之外的事务。**解决**:按上述步骤重建从库。###五、性能优化建议-**定期压缩gtid_executed表**:```sqlALTERTABLEmysql.gtid_executedENGINE=InnoDB;--减少碎片```-**避免频繁小事务**:减少对`mysql.gtid_executed`表的写入压力。>⚠️**关键结论**:MySQL8.0的GTID持久化机制提高了数据安全性,但主从重建时需显式处理`mysql.gtid_executed`表,否则将导致GTID冲突。§§相关问题§§1.MySQL8.0中如何安全清理`mysql.gtid_executed`表?2.使用xtrabackup物理备份时如何正确处理GTID持久化?3.MySQL8.0的GTID持久化机制对高并发写入性能有何影响?4.主从切换后如何确保`gtid_purged`的一致性?5.如何监控`mysql.gtid_executed`表的增长和碎片情况?</think>### MySQL 8.0 GTID持久化机制对主从重建的影响与处理指南 #### 一、GTID持久化机制的核心变化 在MySQL 8.0中,GTID持久化机制进行了重大改进: 1. **`mysql.gtid_executed`表持久化** - 每次事务提交时,GTID会**实时写入**该表(InnoDB引擎),取代了MySQL 5.7基于内存的机制[^3][^4] ```sql -- 查看持久化的GTID信息 SELECT * FROM mysql.gtid_executed; ``` 2. **崩溃恢复增强** 启动时通过读取undo日志恢复GTID信息,确保崩溃后数据一致性[^3]: ```c // 源码关键路径(简化) trx_undo_gtid_read_and_persist() → trx_rseg_persist_gtid() → trx_sys_init_at_db_start() ``` 3. **变量关联性** - `gtid_executed`内存变量从`mysql.gtid_executed`表初始化[^4] - `gtid_purged`表示已清除的binlog对应的GTID[^2] #### 二、对主从重建的影响 1. **重置GTID更严格** `RESET MASTER`会**同时清空**内存变量和`mysql.gtid_executed`表[^4]: ```sql RESET MASTER; -- 清空表+内存+binlog ``` 2. **数据导入冲突风险** 当从库的`mysql.gtid_executed`表非空时,设置`gtid_purged`将报错: ```sql ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed... ``` 3. **持久化导致操作顺序敏感** 重建步骤必须严格按序执行,否则残留的GTID记录会引发冲突 #### 三、正确处理步骤(MySQL 8.0) ```mermaid graph TD A[停止从库] --> B[RESET MASTER] B --> C[清空mysql.gtid_executed] C --> D[禁用binlog导入数据] D --> E[设置gtid_purged] E --> F[配置主从] ``` 1. **完全重置从库环境** ```sql STOP SLAVE; RESET SLAVE ALL; -- 清除复制信息 RESET MASTER; -- 关键!清空持久化表[^4] ``` 2. **导入主库全量数据** ```sql SET sql_log_bin=0; -- 禁用binlog SOURCE /path/to/dump.sql; SET sql_log_bin=1; ``` **备份要求**:mysqldump需包含`--set-gtid-purged=ON` 3. **手动设置GTID状态** ```sql -- 获取主库的gtid_executed值 SHOW GLOBAL VARIABLES LIKE 'gtid_executed'; -- 在从库执行 SET GLOBAL gtid_purged='主库的GTID集合'; ``` **注意**:该操作会同步写入`mysql.gtid_executed`表[^4] 4. **重建复制链路** ```sql CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_AUTO_POSITION=1; START SLAVE; ``` #### 四、关键验证点 1. **GTID一致性检查** ```sql -- 从库应显示与主库相同的GTID集合 SHOW GLOBAL VARIABLES LIKE 'gtid_executed'; SELECT * FROM mysql.gtid_executed; ``` 2. **持久化表状态** ```sql -- 确保无残留GTID SELECT COUNT(*) FROM mysql.gtid_executed WHERE gtid_set NOT IN ('导入的GTID集合'); ``` #### 五、特殊场景处理 1. **物理备份(xtrabackup)** 恢复后需立即执行: ```sql SET GLOBAL gtid_purged='备份的GTID集合'; ``` 2. **部分GTID丢失** 若主库已清除部分binlog(`gtid_purged=1-200`): ```sql -- 从库设置必须包含主库purged的GTID SET GLOBAL gtid_purged='1-200,300-500'; ``` > **重要提示**:MySQL 8.0持久化机制虽增强了安全性,但提高了主从重建的复杂度。操作前务必验证`mysql.gtid_executed`表状态,避免残留GTID导致失败[^3][^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值