MySQL升级最佳实践-阿里云开发者社区

开发者社区> 像教授> 正文

MySQL升级最佳实践

简介:
+关注继续查看
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,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【巡检问题分析与最佳实践】RDS MySQL 实例IO高问题
RDS MySQL的IO性能受到硬件层存储介质类型、软件层的DB内核架构、具体SQL语句扫描或修改数据量的影响。
345 0
【巡检问题分析与最佳实践】RDS MySQL 实例空间问题
实例的空间使用率是RDS MySQL用户日常需要重点关注的监控项之一。如果实例的存储空间完全打满,将会导致严重的影响,包括:数据库无法写入、数据库备份无法正常完成、存储空间扩容任务的执行耗时可能更长等。 一般来说,当一个RDS MySQL实例的存储空间使用比例达到80-85%以上时,就应及时进行处理,要么降低数据库实际占用空间的大小,要么对存储空间进行扩容,以避免空间打满的风险。
308 0
MSSQL · 最佳实践 · 使用混合密钥实现列加密
摘要 在SQL Server安全系列专题的上两期月报分享中,我们分别分享了:如何使用对称密钥实现SQL Server列加密技术和使用非对称密钥加密方式实现SQL Server列加密。本期月报我们分享使用混合密钥加密方式实现SQL Server列加密技术,最大限度减少性能损失,最大程度保护用户数据安全。
1543 0
【巡检问题分析与最佳实践】RDS MySQL 内存使用问题
实例内存使用率和buffer pool命中率是RDS MySQL的关键指标之一,如果内存使用率过高会有OOM风险,如果buffer pool命中率低,大量的数据页无法命中buffer pool中缓存的数据页,需要从存储读取数据,造成IO吞吐增加和延迟增加。
443 0
MSSQL - 最佳实践 - 使用SSL加密连接
--- title: MSSQL - 最佳实践 - 使用SSL加密连接 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,往期我们已经陆续分享了:[如何使用对称密钥实现SQL Server列加密技术](http://mysql.taobao.org/monthly/2018/08/03/)、[使用非对称密钥实现SQL Server列加密](http:/
2525 0
MSSQL - 最佳实践 - 如何打码隐私数据列
--- title: MSSQL - 最佳实践 - 如何打码隐私数据列 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,我们已经分享了:如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥加密方式实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术、列加密技术带来的查询性能问题以及相应解决方案和行级别安全解决方
1115 0
+关注
1338
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载