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
本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/1183247，如需转载请自行联系原作者
