网站备案主体变更网站宽度多少合适

网站备案主体变更,网站宽度多少合适,手机app是什么意思,自己做的网站怎么被百度收录一、背景说明生产环境中#xff0c;MySQL 在高并发写入或批量任务场景下#xff0c;容易出现 TPS 抖动、提交延迟上升等问题。 本次优化不涉及业务代码与 SQL 改造#xff0c;而是通过调整 InnoDB 底层参数#xff0c;在可控停机窗口内提升数据库整体稳定性与吞吐能力。二、…一、背景说明生产环境中MySQL 在高并发写入或批量任务场景下容易出现 TPS 抖动、提交延迟上升等问题。本次优化不涉及业务代码与 SQL 改造而是通过调整 InnoDB 底层参数在可控停机窗口内提升数据库整体稳定性与吞吐能力。二、优化目标降低 InnoDB 写入抖动减少频繁 checkpoint 带来的性能波动提升高并发与大事务场景下的稳定性确保操作可回滚、可验证、风险可控三、my.cnf配置文件核心参数调整说明重点#my.cnf配置文件中新增以下参数需结合实际内存大小 # --- REDOLOG需重启--- innodb_log_file_size2147483648 innodb_log_files_in_group2 # --- 内存与缓冲 --- innodb_buffer_pool_size12884901888 innodb_buffer_pool_instances8 innodb_log_buffer_size1342177281. REDO LOG 调整需重启 调整前 redo 总量约 96MB 调整后 redo 总量 4GB 优化收益 减少 checkpoint 频率 平滑写入压力 提升高峰期稳定性 2. Buffer Pool 调整 作用 提高缓存命中率 减少磁盘 IO 降低并发竞争 3. Log Buffer 调整 作用 优化大事务与批量写入 减少事务执行过程中的刷盘压力四、实施过程概述修改配置并进行mysqld --help 干跑校验短暂停机备份并移走旧 redo 文件重启触发 redo 重建启动后通过文件、日志、连接多维度验证强调一句整个过程具备明确回滚方案风险可控。五、整个实操过程重点注意先改配置并校验确认一切 OK 后再短暂停机重启。 ###############一、基本信息查询梳理################### [rootlocalhost ~]# mysql --version mysql Ver 8.0.19 for linux-glibc2.12 on x86_64 (MySQL Community Server - GPL) [rootlocalhost ~]# echo DATA_DIR/home/mysql/mysql/data DATA_DIR/home/mysql/mysql/data [rootlocalhost ~]# echo SOCKET/home/mysql/mysql/mysql.sock SOCKET/home/mysql/mysql/mysql.sock [rootlocalhost ~]# echo ERR_LOG/home/mysql/mysql/data/error.log ERR_LOG/home/mysql/mysql/data/error.log [rootlocalhost ~]# df -h /home/mysql/mysql/data 文件系统 容量 已用 可用 已用% 挂载点 /dev/mapper/centos-home 541G 134G 408G 25% /home [rootlocalhost ~]# ls -lh /home/mysql/mysql/data/ib_logfile* 2/dev/null || echo 旧 redo 暂未发现首次创建或已被清理过也ok -rw-r-----. 1 mysql mysql 48M 10月 29 08:04 /home/mysql/mysql/data/ib_logfile0 -rw-r-----. 1 mysql mysql 48M 10月 11 13:15 /home/mysql/mysql/data/ib_logfile1 [rootlocalhost ~]# mysqld --help --verbose --defaults-file/etc/my.cnf /dev/null 没有任何输出没问题 ##############二、下面开始备份配置 写入生产参数防重复键 干跑校验############### 1.备份 my.cnf回滚点 cp -a /etc/my.cnf /etc/my.cnf.bak.$(date %F-%H%M%S) 2.确认备份存在 # 按时间倒序列出所有 my.cnf 备份取最新那一个 ls -lt /etc/my.cnf.bak.* ls -lt /etc/my.cnf.bak.* | head -1 ls -lt /etc/my.cnf.bak.* 3. vim /etc/my.cnf 追加新的配置内容到配置文件的skip-name-resolve这一行之后# skip-symbolic-links 与 symbolic-links0 重复可任选其一 这一行之前新增以下内容 # --- REDOLOG需重启--- innodb_log_file_size2147483648 innodb_log_files_in_group2 # --- 内存与缓冲 --- innodb_buffer_pool_size12884901888 innodb_buffer_pool_instances8 innodb_log_buffer_size134217728 新增好后保存退出。 4.干跑校验0 停机 mysqld --help --verbose --defaults-file/etc/my.cnf /dev/null 没有输出内容即可 5.停库 systemctl stop mysqld 6.切到真实 datadir cd /home/mysql/mysql/data 7.创建一个带时间戳的备份目录。 BKP/root/old_redo_$(date %F-%H%M%S); mkdir -p $BKP 8.把旧的 ib_logfile0/ib_logfile1 移动到备份目录。 compgen -G ib_logfile* /dev/null mv -- ib_logfile* $BKP/ echo $BKP /root/last_redo_dir 9.检查第7、第8步生效情况 ls -lh /home/mysql/mysql/data/ib_logfile* 2/dev/null || echo 旧 redo 暂未发现首次创建或已被清理过也ok ls -lh $BKP/ 这里为什么这样操作答让 MySQL 下次启动时发现 redo 不存在/不匹配按你在 my.cnf 设置的 innodb_log_file_size2147483648、innodb_log_files_in_group2 自动重建 2×2G 的新文件。 10.重启mysql systemctl start mysqld InnoDB 会在 datadir 下新建 ib_logfile0 2G ib_logfile1 2G 这一步完成真正的 redo 扩容让新尺寸生效。 11.重启后检查验证 ls -lh /home/mysql/mysql/data/ib_logfile* # 看到 ib_logfile0、ib_logfile1 各 ~2.0G 12.基础校验 mysql -u root -p SELECT NOW() AS now; -- 能返回说明连通正常 SHOW GLOBAL STATUS LIKE Uptime; -- 重启后是较小秒数过几秒再查应该在增长 SHOW VARIABLES LIKE version%; -- 看清连到谁防止连错实例 SHOW DATABASES; -- 能列出库就 OK 13.查看到新一轮启动与 redo 创建/尺寸日志 tail -n 200 /home/mysql/mysql/data/error.log \ | egrep -i ready for connections|InnoDB|log file size|redo #说人话这是“验收单”确认你这次 redo 扩容确实生效而且启动没翻车。 11.失败场景下的标准回滚流程基于已存在的备份停库 → 恢复配置 → 恢复 redo → 启库 11.1停库 systemctl stop mysqld 11.2.恢复原有 my.cnf 配置文件配置回滚 注意这里我当时是把my.cnf保留在本地了如果失败我准备清空现有的my.cnf,将操作前的全选复制粘贴过来。 当然也可以 # 选择最新的 my.cnf 备份文件恢复 ls -lt /etc/my.cnf.bak.* | head -1 # 假设最新备份为 /etc/my.cnf.bak.2025-12-13-101530 cp -a /etc/my.cnf.bak.2025-12-13-101530 /etc/my.cnf 11.3 恢复旧的 redo 日志文件数据结构回滚 # 读取第 8 步记录的 redo 备份目录 latest_redo_dir$(cat /root/last_redo_dir) # 将旧的 ib_logfile* 移回 datadir mv -- $latest_redo_dir/ib_logfile* /home/mysql/mysql/data/ 11.4 启动 MySQL 服务完成回滚 systemctl start mysqld 11.5 回滚后快速验证建议 # 查看启动日志 tail -n 200 /home/mysql/mysql/data/error.log \ | egrep -i ready for connections|InnoDB|error|redo|log file # 登录验证 mysql -u root -p SHOW GLOBAL STATUS LIKE Uptime; 验证预期结果 error.log 中无 redo mismatch、InnoDB error MySQL 正常启动并可连接 Uptime 为较小值并持续增长 11.6.回滚逻辑总结 本次回滚流程完全基于前置备份设计 配置层通过 my.cnf.bak.* 实现快速配置回退 存储层通过备份的 ib_logfile* 恢复 redo 结构 回滚操作不涉及数据文件.ibd / 表空间风险可控恢复路径清晰。