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