MySQL升级最佳实践:
升级的原因 :
1、
旧版本的BUG
2、
旧版本的安全问题
3、
在新版中受益的地方(新特性,可扩展性,性能等)
4、
数据库支持受限
继续保留使用旧版本的原因:
1、
app处在一种隔离的网络状态,更新成本高
2、
app已不在有新的功能更新
3、
app活跃度下降已不在上升
4、
platform 中的硬件或者os 没有发生变化等
哪些情况版本升级危险性大:
1、
主版本的变化,比如5.1到5.5的升级
2、
MySQL to Percona or mariadb的升级
3、
一次性跳过太多的副版本号,比如从5.1.20 到 5.1.61
4、
从原来的开发版本升级到其他更高的稳定版或开发版
5、
跳过一个或多个主版本号如: 4.1到5.5 而不是从5.1到5.5
升级需要考虑的问题:
1、
数据、数据类型(是否兼容)
在磁盘上存储的格式,MySQL数据类型的变化,
排序方面的变化;
Timestamp类型是否自动更新时间
新的一些限制;哪些是保留字;统计信息的改变等
2、
Queries(reads and writes)
语法的变化;警告或错误等提示消息
查询使用方式所带来的结果是否与原先版本的结果一致。
在函数等其他查询中哪些是不确定的query
3、
性能和可扩展性
Query执行时间,query执行计划,在可扩展和locking方面的性能
4、
复制方面的变化
在一定压力负载下,复制的一些情况,在err_log中是否有报警或错误消息;
是否存在“data drift” 造成主从数据不一致?性能是否有波动等?
5、
资源的使用
内存的使用情况,是减少了还是增多啦?
6、
高级的新特性
更多的新特点前提是 是否牺牲了其他的特性
对 存储程序、plugin、触发器、events、视图 这些方面看看是否收到影响!
是直接升级还是使用复制的方式升级?
对于小的系统来说是直接进行升级,这样会造成宕机或造成其他的危险,使用LVM进行快照的话,可以很快的进行rollback。
对于使用shards 的环境:挨个对mysql进行升级 将危险降到最低;
使用replication 方式的升级方式是值得推荐的(将新版本server做slave,最后在切换)。
在Cloud 中进行升级:
建立一个“clone”的 updated server,直接进行测试;
升级过程中所涉及到其他的问题:
在升级MySQL的时候,是否还要升级硬件?OS?应用程序? 配置文件如何修改等?
如果单单进行MySQL升级的话,可以用很多时间进行测试;
还有升级其他组件的话,出现问题话,还要查询是否是其他组件的问题,这样做危险系数直线上升。
对存在复制架构的情况,进行升级:
1、
对于 MM双主的情况,先对不活跃的master进行升级;
对shard 环境的数据库,你可以走个捷径:
就是不需要对所有的MySQL进行测试,
先升级一个shard,并进行监控,等确认后,在批量升级其他的shard,在进行整体的测试。
升级的具体过程:
1、
先阅读新版本改进的地方,及新特性
2、
对新版本设置QA环节,列出哪些特性,及改进是需要使用并改变的。
3、
调整MySQL配置文件;移去过时的参数,对某些参数进行改进(比如:在5.5. 中 storage_engine=Innodb; innodb_file_format=Barracuda;例如某些兼容性的需求:在5.5 中 Read-Comitted 在 statement replication环境下是不起作用的。)
4、
迁移数据:
Mysqldump and import back; 最保险的方式,是整个的移动数据,但也最慢,这样对于跳过很多版本的数据库升级方式,是很有帮助的。
然后执行 MySQL_upgrade 会检查table 的兼容性并尝试进行修复;并且升级system table
5、
对数据进行校验
比较原先备份文件和升级后的备份文件的差别
Checksum table(pt-table_checksum工具的使用)
6、
如果不打算停掉业务,可使用replication的方式
使用 pt-table-checksum 进行同步数据check
在slave上检查错误日志或警告。
必要的情况下在进行一次回滚,即replication old-new- 来100%确定。
大部分情况下, 采用复制的方式,从5.0-5.5 还是有效果的。
Replication new-new 这样做的目的是 检查是否还有额外的安全或其他错误;升级的事后验证。
7、
验证复制的性能:
测量slave catch up 的速度。查看thread利用情况。
8、
从线上获取真实的查询:
可以打开general_log 或 slow log(long_query_time=0)
或使用tcpdump抓包,pt-query_digest 解包分析
截取部分数据:
Pt-query_digest --sample 5 –print --no-report queries.log > samples.log
9、
检查query
单connection测试:对这些 samples.log 运行 pt-upgrade
高并发测试: 运行pt-log-player 两次,第一次热机,第二次才是真正的运行。
Look at pt-query_digest report on full query log is good to check in both cases
10、进行压力测试: full application load testing