MySQL基础 - 数据库升级 - 《MySQL》

参考文档
文章目的
升级环境
操作
参数调整重点!!!!!
重启MySQL 并建立主从即可

参考文档

From MySQL 5.6 partitioning to 5.7 and beyond : https://www.colabug.com/1943223.html
MySQL版本升级之5.6到5.7 : https://www.cnblogs.com/Bccd/p/5987426.html
my.cnf 生成器 :http://imysql.com/my-cnf-wizard.html
叶问: http://t.cn/AilcLws0
官方文档: https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_checksum_algorithm

文章目的

提供数据库升级思路及注意事项如升级参数,报错及一些细节记录.
由于升级升级操作与备份恢复只多一个mysql_update 操作因此不在此记录具体的数据库升级操作.

升级环境

数据库升级版本目标

5.6.10 > 5.7.25

数据库安装方式

5.6.10 为编译安装
5.7.25 为二进制安装

升级思路

利用就旧版本的xtrabackup全量备份+增量备份 + mysql_upgrade

系统环境

5.7.25:
CentOS Linux release 7.5.1804 (Core)
5.6.10
Centos release 6.4 (Final) Santiago

操作

1. 新环境安装mysql 5.7.25 版本

1)二进制安装,这里在操作的时候并没有将mysql 命令加到环境变量中,是为了防止在使用xtrabackup 调用mysql(但是应该没有必要,xtrabackup使用自己的mysql命令)

2.恢复旧版本MySQL

进行恢复的时候需要注意xtrabackup版本问题:
1)使用xtrabackup 的版本需要注意,由于5.6.10 使用的是percona-xtrabackup-2.3.9-1 ,因此最好在恢复的是时候用相同版本恢复
(MySQL 5.7 使用就会使用 percona-xtrabackup-24-2.4.x 版本,如果使用的是低版本percona-xtrabackup将会报错)
开始由于使用新版本恢复,在—apply-log 中有报错

InnoDB: Encryption algorithm support missing: N InnoDB: Encryption algorithm sup

2)在进行copy-back 的时候由于数据库较大最好使用脚本运行

3)此时需要将原库的my.cnf传过来, 将路径修改正确并创建出目录.此时候并没有修改升级后的参数
(这里不对备份恢复做操作记录)
3使用5.7.25 MySQL命令启动MySQL
使用5.7.25 MySQL启动实例
会有一堆报错
报错
a) 配置参数报错(由于5.6 一些参数在5.7中被移除了因此报参数不识别

2019-04-19T01:34:36.138161Z 0 [ERROR] InnoDB: Cannot open '/data/mysqldb/data/ib_buffer_pool' for reading: No such file or directory
2019-04-19T01:34:36.150694Z 0 [Warning] System table 'plugin' is expected to be transactional.
2019-04-19T01:34:36.150990Z 0 [ERROR] unknown variable 'myisam-recover=BACKUP,FORCE'
unknown variable 'innodb_additional_mem_pool_size=16M'

因此需要注释掉这些不识别的或者说是被弃用的参数
b)启动后会因版本报的错
实例正常启动会有升级提示

3.进行升级

进行升级操作

mysql_upgrade -uroot -p'123456' -S /tmp/mysql_3306.sock

其中会有一个分区表的error,在5.7.25 升级过程的最后会发现,程序自动单独的对分区表进行了升级
参考文档:https://www.colabug.com/1943223.html

user_mon.srss_eventerror    : Partitioning upgrade required. Please dump/reload to fix it or do: ALTER TABLE user_mon.srss_event UPGRADE PARTITIONING
warning  : The partition engine, used by table 'user_mon.srss_event', is deprecated and will be removed in a future release. Please use native partitioning instead.
user_mon.srss_grey_list                            OK
user_mon.srss_risk
error    : Partitioning upgrade required. Please dump/reload to fix it or do: ALTER TABLE user_mon.srss_risk UPGRADE PARTITIONING
warning  : The partition engine, used by table 'user_mon.srss_risk', is deprecated and will be removed in a future release. Please use native partitioning instead.
user_mon.srss_risk_engine_config                   OK
user_mon.srss_risk_upgrade
error    : Partitioning upgrade required. Please dump/reload to fix it or do: ALTER TABLE user_mon.srss_risk_upgrade UPGRADE PARTITIONING
warning  : The partition engine, used by table 'user_mon.srss_risk_upgrade', is deprecated and will be removed in a future release. Please use native partitioning instead.
mysql_upgrade 自动将分区表进行升级
Upgrading tables
Running  : ALTER TABLE anti_fraud.anti_request_main_log UPGRADE PARTITIONING
status   : OK
Running  : ALTER TABLE ubastat.f_ss_fi_investor UPGRADE PARTITIONING
status   : OK
Running  : ALTER TABLE ubastat.f_ss_fi_loan UPGRADE PARTITIONING
status   : OK
Running  : ALTER TABLE ubastat.f_ss_fi_loan_phase UPGRADE PARTITIONING
status   : OK
Running  : ALTER TABLE user_mon.srss_event UPGRADE PARTITIONING
status   : OK
Running  : ALTER TABLE user_mon.srss_risk UPGRADE PARTITIONING
status   : OK
Running  : ALTER TABLE user_mon.srss_risk_upgrade UPGRADE PARTITIONING
status   : OK
Upgrade process completed successfully.

对数据库进行重启后数据库升级操作就算完成了但是如果你认为直接重启就万事大吉的话那你就离跑路不远了

参数调整重点!!!!!

此时只是完成了数据库数据的升级,但是很多参数都没有进行修改,因此需在最后一次重启数据库前将不兼容的参数进行调整
修改配置文件

server_id=(该参数由于my.cnf 直接拷贝过来且要做主从因此需要修改)
innodb_checksum_algorithm = innodb(这里需要确人原数据库参数是什么参数原则:新版crc32 无法兼容旧版本的innodb; 在5.6中绝大部分版本默认值为innodb;5.7中版本>=crc32版本)
log_timestamps=SYSTEM(日志时间该参数为5.7 新加,不修改error日志时间会有时差)
sql_mode=设置通旧版本一致
optimizer_switch= (需要注意derived_merge 该优化器会造成升级前后SQL查询结果不一致)
innodb_strict_mode：控制CREATE TABLE, ALTER TABLE, CREATE INDEX, 和 OPTIMIZE TABLE的语法问题,(这里碰到过一个问题,导致复制中断,5.6中对一些语法报错只是warning,到了5.7 则会直接error,导致5.7的slave复制中断,案例报错为

'Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.' 
                   on query. Default database: 'ubastat'. Query: 'ALTER TABLE `report_loanafter_analy_result`
MODIFY COLUMN `analy_no`  varchar(60) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL AFTER `merchantNo`'

原因大概为:主5.6.10 对这类超限的操作只报warnings,自动进行改写,但是5.6 以后由于该参数直接error)

innodb_undo_directory && innodb_undo_logs：MySQL 5.7支持将undo从ibdata1独立出来（只支持实例初始化，不支持在线变更）

其他一些参数,

innodb_page_cleaners：MySQL 5.7将脏页刷新线程从master线程独立出来了，对应参数为innodb_page_cleaners
show_compatibility_56=ON：控制show变量及状态信息输出，如果未开启show status 命令无法获取Slave_xxx 的状态
disable_partition_engine_check：在表多的情况下可能导致启动非常慢
range_optimizer_max_mem_size：范围查询优化参数，这个参数限制范围查询优化使用的内存，默认8M
SQL兼容性问题：SQL在MySQL 5.7和MySQL 5.6环境下结果可能不一致，因此建议获取线上SQL，在同样数据的环境下，在两个实例运行获取到的结果计算hash，比较hash值做兼容性判断

数据库升级