tplinux
TA的个人档案
tplinux_个人页
文章
38
问答
0
视频
0
个人介绍
云和恩墨 MySQL DBA
擅长的技术
-
发表了文章 2021-12-15
初探TiDB-TiFlash
简介TiFlashTiFlash是TiDB生态组件之一，专门解决OLAP场景。借助ClickHouse实现高效的列式计算。介绍TiFlash架构一开始，我个人以为他会是用binlog或其他方式把数据同步到TiFlash中，读取数据有专门的接口，结果我的理解是错误的。如图，TiFlash是通过TiKV把数据同步到TiFlash。大家都知道TiKV中的Region是分leader和Follower。TiFlash通过Region的leader节点进行数据全量和增量同步。增量同步是通过Raft Log异步复制，相当于MySQL的redo log同步。我这里就好奇，为啥不通过TiKV Follower 节点进行全量和增量的同步呢？因为本身TiKV的数据就是强一致的，并且TiKV的Leader节点还要承担日常的读写压力。答： 这个是因为 Raft 协议实现的问题，目前都是以 leader 为准的。（来自神秘好友的解答）目前TiKV应该不支持读写分离，如果把同步的节点改完TiKV的Follower节点，也不会影响数据的一致性，并且能分担Leader节点的压力。答： 这个的话，现在有 Follower Read 的功能，可以理解为读写分离，但是目前读是强一致性的，后续会允许异步读取数据，也就是从 follower 上读到一段时间之前的数据（来自神秘好友的解答）核心特性异步复制TiFlash节点和TiKV节点进行复制同步期间，发生网络延迟或者网络抖动，不会影响到TiKV的运行。如果TiFlash节点宕机了，也不会影响TiKV的运行。只要TiKV的数据不丢失，TiFlash的数据就可以通过TiKV进行恢复。简单来说 你可以把TiFlash和TiKV的关系理解为MySQL的主从架构。MySQL主库和从库之间发生网络抖动，或者MySQL从库挂了。并不会影响MySQL主库的写入和读取（这里说的是MySQL异步复制）。智能选择TiDB可以自动选择使用 TiFlash 列存或者TiKV行存。不需要通过其他接口访问TiFlash 。其实在这里就实现了一个入口根据实际SQL选择列存或者行存。实验环境：2张表一个是sbtest1、sbtest2有相同的数据。但sbtest1做了TiFlash同步，sbtest2还是保留TiKV存储。当sbtest1和sbtest2同时执行count的操作，二个表的执行计划就不同了。发现sbtest1表走了TiFlash列存储，而sbtest2表则走了TiKV行存储。实验2：sbtest1表执行不同的SQL，选择行存或者列存就会发生转变。1154×448 120 KB计算加速通过列式引擎来提升TiDB读取的效率的提升。TiDB架构中本身就实现了计算下推，把计算任务推给了存储引擎层也就是TiKV。在新增列式存储TiFlash环境中，TiFlash也承担计算任务。一致性TiFlash和TiKV一样提供快照隔离的支持，并且保证读取数据最新。这个一致性是通过复制进度校验来实现的。每次接收到读取请求，TiFlash 会向 Leader 发起进度校对。只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取。部署TiFlashTiDB版本大于TiDB3.1和TiDB4.0 。在tidb-ansible找到[tiflash_servers] 填写主机名和data目录。其他操作和部署TiDB无异，目前官方推荐使用TiUP进行部署，可以参考官方。需要注意的是 不建议TiFlash和TiKV混合部署，不建议部署多实例。个人建议TiFlash的配置比TiKV的配置要高一点。因为毕竟TiFlash要跑OLAP业务，消耗资源可能会多一点。使用TiFlashTiFlash接入后，默认不会进行数据同步。可以针对表来进行TiFlash副本。按照表构建TiFlash。ALTER TABLE table_name SET TIFLASH REPLICA countcount表示副本数 ALTER TABLE table_name SET TIFLASH REPLICA 1查看表的同步进度SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '<db_name>' and TABLE_NAME = '<table_name>'TiSpark可以直接读取TiFlash中的数据。优点业务可以通过TiDB直接跑OLAP场景的SQL。减少维护成本 数据库（MySQL）到分析类型的数据库（例如hadoop）之间的链路同步工具。减少分析数据库（例如hadoop）的维护成本。美中不足资源隔离和资源调度虽然TiFlash和TiKV中有资源隔离。TiFlash不会影响到TiKV的性能。但我想说的是TiFlash里的资源调度。如果大量的消耗资源的SQL在TiFlash中运行，TiFlash会不会把整个系统的资源跑满？导致重要的其他SQL无法运行。可以把一些慢的 不重要的SQL分配较少的系统资源。重要的SQL分配更多的系统资源。总结 TiFlash还是一款非常不错的组件，能够解决一些痛点，满足一些场景的需求，在官方持续维护下TiFlash的未来还是非常可期的。一开始，我个人以为他会是用binlog或其他方式把数据同步到TiFlash中，读取数据有专门的接口，结果我的理解是错误的。
-
发表了文章 2019-03-21
tidb VS MySQL 性能篇
tidb和MySQL配置信息sysbench版本：sysbench-1.0.17压测表大小:90000测试线程数：16tidb和MySQL均属单机版本。 tidb和MySQL均属默认配置测试结果tidb: MySQL： 性能对比图： 测试结论：1、tidb 属于分布式数据库，而我测试的是单机性能。对tidb有些不公2、tidb和MySQL均为进行性能优化，测试结果可能出现变差。3、tidb属于海量数据计算，对硬件有一定要求，而我用虚拟机做测试。自己随手测着玩，不用太当真，一切以生产环境为准。
-
发表了文章 2019-01-27
终于等到你，Percona MySQL8.0 GA版本发布
Percona 在12月21日 发布对Percona Server 8.0 GA版本。 在支持MySQL8.0社区的基础版上。Percona Server for MySQL 8.0版本中带来了许多新功能： 一、安全性和合规性： 审计日志插件：提供数据库活动的监视和日志记录。此功能与MySQL Enterprise Auditing相当。 基于PAM的身份验证插件：通过与PAM模块的基础，双重验证单登陆（SSO）和双因素身份验证（2FA）系统集成。此功能与MySQL Enterprise Auditing相当。 增强加密：增强对二进制日志加密，临时文件加密，对所有innodb表空间类型和日志的机密支持，并行双写缓冲区加密。此功能与MySQL Enterprise Auditing相当。 二、性能和可扩展性： Threadpool：支持10000多个连接，此功能与MySQL Enterprise Auditing相当。 InnoDB引擎增加功能：通过并行双写，多线程LRU刷新和单页去除，实现高度并发的IO绑定工作负载，从而显著提高性能。Percona Server for MySQL与MySQL Community Edition进行比较时，某些工作负载的性能提升了60％ MyRocks存储引擎：基于RocksDB存储库，MyRocks通过针对nVME SSD等现代硬件进行优化。 三、可观察性和可用性 改进检测：Percona Server for MySQL 8.0提供了超过两倍的可用性能和统计计数器，以及支持收集每用户和每线程统计数据，以及扩展的慢查询日志记录功能。 减少备份影响：更轻的重量备份锁定可降低对执行备份的性能和可用性的影响。与Percona XtraBackup 8.0一起使用时，此功能可使您的备份运行更快，并且您的应用程序在长时间运行的备份中表现更好。 Percona Server for MySQL 8.0中将要被废用功能： 1、TokuDB存储引擎：整个Percona Server for MySQL 8.0系列支持TokuDB，但在下一个版本将不会提供。Percona鼓励TokuDB用户探索MyRocks存储引擎。 Percona Server for MySQL 8.0中删除的功能： CSV存储引擎。 ALL_O_DIRECT InnoDB的刷盘方式。 查询缓存。 感谢Percona 公司对MySQL以及MySQL周边的大力支持，以及对开源社区的回报。
-
发表了文章 2019-01-27
MySQL很慢... 怎么破？？
老王：最近我的MySQL数据库很慢.... 很忧伤，这可肿么办？ 帅萌：老王，老王你莫心慌，听我跟你唠~ MySQL性能有问题，先应该关注的是慢查询日志（slow log）。 MySQL性能慢，多半是SQL引起的（慢查询日志会把执行慢的SQL，一五一十的记录下来，就像你的身体一样诚实..）需要根据慢查询日志的内容来优化SQL。 其次，除了MySQL慢查询日志，还需要更多的关注liunx系统的指标和参数。 top 命令帮你观察大橘(局)。 观察 load average 1分钟 、5分钟、 15分钟的平均负载值。 然后是us% 用户使用的CPU占比，如果us%太高，极有可能索引使用不当。 sy%系统内核使用的CPU占比，如果sy%太高，要注意MySQL的连接数和锁等信息。 wa% io使用CPU的占比，如果wa%太高，要关注MySQL是否使用了硬盘临时表，或者大量刷盘等操作，也有可能是硬盘太慢，或硬盘故障,可以使用iostat等工具来观察。 还需要关注各个逻辑CPU之前的负载是否均衡（可能是中断不均衡导致性能问题）,可以使用mpstat命令来进行详细观察。 MySQL是数据库服务，不建议跟其他应用混跑。 其次是内存的使用信息,先通过free来观察。 要观察 是否使用了SWAP，剩余多少内存，是否发生内存泄漏。 说到SWAP,就要说到NUMA，通过numactl来观察NUMA的使用情况，建议关闭NUMA。至于为什么，建议阅读《NUMA架构的CPU -- 你真的用好了么?》 。 阅读地址：http://t.cn/RAZ3hw9 内存泄漏观察方法 buff/cache 和used 对比。 如果发生了内存泄漏，解决方案： 重启MySQL 。 升级到最新的小版本MySQL 。 还可以通过vmstat 来观察每秒的进程、内存、swap、io、cpu等详情情况。 然后要关注IO的使用情况,可以通过 iostat -x来观察，主要观察。 rrqm/s #每秒读取的扇区数。 wrqm/s #每秒写入的扇区数。 avgrq-sz #平均请求扇区的大小 。 avgqu-sz #是平均请求队列的长度。 await #每一个IO请求的相应时间。 %util #在统计时间内所有处理IO时间，除以总共统计时,暗示了设备的繁忙程度。 MySQL观察层面 主要关注tps、qps、并发连接数(Threads_connected)、并发活跃线程数(Threads_running)、临时表(tmp_disk_tables)、锁(locks_waited, Innodb_row_lock*)等指标。 关注当前是否有不良线程状态，例如：copyto tmp table、Creating sort index、Sorting result、Creating tmp table、长时间的Sending data等。 关注InnoDB buffer pool page的使用情况，主要是Innodb pages_free、Innodb wait_free两个 。 关注InnoDB的redo log刷新延迟，尤其是checkpoint延迟情况，并关注unpurge list大小。 关注innodb status中是否有long semaphore wait的情况出现。 观察是否有大事物的阻塞。 在观察MySQL运行状态方面，帅萌丢一个py脚本。写的时间久，迭代N个版本，不过这个版本很方便....（其他的在项目里拆起来有点费劲）。但是编程这方面越写越精，需要磨练，各位可以参考一下，相信你们会写的更棒。 如果实在看不懂的请联知数堂zizi老师，我负责挖坑，他负责教你会，带你飞。 代码地址：http://t.cn/E4n7O6S 还提供一个SOS.sh脚本，当性能遇到问题，可以根据实际情况进行修改，并自行把相关内容打包，以便探讨和交流。 （杨奇龙老师的图） 、##参考 知数堂-叶问(20181218） 、##感谢，有赞杨奇龙老师提供的帮助，以及图片支持。
-
发表了文章 2019-01-27
论如何安心过大年-MySQL巡检篇
今天距农历新年还有10天，3306π社区提前给大家拜年啦~ 为了让大家安心过大年，现3306π社区特别推出"论如何安心过大年-MySQL巡检篇"，希望大家能给借鉴和学习到知（zi）识（shi）。也真心的祝福大家新年快乐，开开心心过大年。 下面说的都是重点，请各位同学哪笔和纸记好。 首先，业务稳定为主 何为业务稳定为主： 马上就要过年了，一般公司都有要求 暂停业务开发，暂停系统上线。除非紧急bug，可紧急上线。这点主要是为了，防止上线新业务或新代码导致在过年期间引发bug。因为过年大家都各自回家了，新的bug修复不及时，从而印象业务。 其次，扩容为辅 何为扩容为辅： 一般为了让自己安安心心过年，会对磁盘进行扩容。例如磁盘使用率到80%，运维同学或DBA同学一般就会选择进行磁盘扩容，不过扩容的时候要小心。千万、千万、千万要保证备份的可用性。 不过一般来说，很少有业务在过年期间是高峰期的，在进行磁盘扩容之前，应该先检查一下是否有无用的大文件。可以对磁盘瘦身，也能达到扩容的效果。 最后，业务信息，心中藏 何为业务信息，心中藏：要收集好自己对应的业务线的业务负责人，系统、网络、开发、测试等等等，一级负责人、二级负责人、还有自己B岗、自己的同事等等。一旦出现问题，可以召唤同事，一起排查。无论是谁的锅，首要要解决故障啊。 下面说的不是那么重点了。但也请大家牢记。 网络通：要确保手机有余额，自己家中有网络，有3G有4G... 手机看：定期看看手机和微信（万一领导发红包呢） 要报告：如果去无网络的环境要通知自己的同事、B岗。帮忙叮一下 最后在年前，大家还要坚守自己的岗位啊！巡检工作要在最后一周内完成。这样才能安安心心过大年。 关于巡检的文章推荐阅读： MySQL很慢... 怎么破 [http://t.cn/EtZh4XF] MySQL巡检怎么做 [ http://t.cn/EtZPlrA ] 最后3306π祝大家安安心心过大年，好好陪家人，过年无人扰。
-
发表了文章 2018-12-09
《叶问》第10期
2018年11月6日，周二 Show proceslist时发现大量的sleep，有什么风险吗，该如何处理？ 答：（一）可能的风险有： 1、大量sleep线程会占用连接数，当超过max_connections后，新连接无法再建立，业务不可用；2、这些sleep线程中，有些可能有未提交事务，可能还伴随着行锁未释放，有可能会造成严重锁等待；3、这些sleep线程中，可能仍有一些内存未释放，数量太多的话，是会消耗大量无谓的内存的，影响性能。 （二）建议应对措施： 1、升级到5.7及以上版本，连接性能有所提升；2、采用MariaDB/Percona版本，根据情况决定是否启用thread pool功能；3、适当调低wait_timeout/interactive_timeout值，例如只比java连接池的timeout时间略高些即可；4、利用pt-kill或辅助脚本/工具巡查并杀掉无用sleep进程；5、利用5.7的新特性，适当设置max_execution_time阈值，消除长时间执行的SQL；6、定期检查show processlist的结果，找到长时间sleep的线程，根据host&port反推找到相关应用负责人，协商优化 2018年11月16日，周五 MySQL如何对只对个别列授权？ 答：其实挺简单的，用GRANT授权即可，例如： GRANT SELECT (c1), INSERT (c1, c2) ON zhishutang.yewen TO 'yewen'@'zhishutang.com'; 2018年11月20日，周二 如何正确监控MySQL主从复制延迟(请考虑5.6版本前后区别，即并行复制及GTID等因素)? 1、通过观察io线程减去sql线程对比的方式对比： Master_Log_File == Relay_Master_Log_File && Read_Master_Log_Pos == Exec_Master_Log_Pos。 基于GTID复制 2、通过接受事务数减去已经执行事务数对比：Retrieved_Gtid_Set == Executed_Gtid_Set。 基于并行复制 3、先通过P_S库replication_applier_status_by_coordinator和replication_applier_status_by_worker表来观察每个复制线程的状态，后配合postion复制或GTID复制方法来监控复制延迟。4、可以采用pt-heartbeat工具。 大家不要再相信Seconds_Behind_Master。至于为什么，先卖个关子，关注下期叶问哦。
-
发表了文章 2018-12-09
《叶问》第9期
2018年10月23日，周二 MongoDB服务器CPU一直很高，最高达到900%，可能是哪些原因？ 答：可能原因如下： 1、高并发场景下，服务器开启numa2、mongo查询无索引，消耗大量内存和io3、服务器硬件故障，例如CPU 内存 raid卡等4、高并发写入下开启读写分离+oplog应用加锁 5、高并发短链接+最新SCRAM-SHA-1认证的情况 2018年10月30日，周二 MySQL运行环境中，当发现系统已经用到了swap，该怎么处理？ 答：一般来说，发生swap的原因是系统认为内存不够了 那么，当物理内存真的不够了，或者著名的NUMA都是引起swap的可能原因。通常的应对方法有几种： 1、通过BIOS、系统内核参数关闭NUMA，或者在mysqld启动时，利用numactl关闭NUMA的使用2、调低系统使用swap的权重，设置内核参数 参数 vm.swappiness 不高s 不高于103、Linux下使用free命令查看内存使用情况，确认是否发生了内存泄露，可以去微信公众号「老叶茶馆」中发送“OOM”4、修改MySQL参数innodb_flush_method = O_DIRECT，这样InnoDB在读写物理数据的时候会绕过cache来访问磁盘5、优化SQL效率，避免产生额外的分组、排序、临时表情况发生，参考文章：文章：http://t.cn/EwLIuFv6、在【夜间或业务不繁忙】时适合执行 swapoff -a，并执行sync刷新操作系统内存脏页到硬盘 2018年11月1日，周四 大量SQL语句文本，如何快速导入到MySQL中？ 1、可在SQL文本前，添加set session sql_log_bin=0（需要在从库也导入一次）。2、导入期间临时修改参数sync_binlog=10000、innodb_flush_log_at_trx_commit=0、innodb_autoinc_lock_mode=2。3、导入前，根据业务情况看能否删除除了自增列主键外的其他索引。4、将SQL文件切割成多份，再并发多线程导入。5、若该SQL文件是每个INSERT一行，需要先行将多行合并成一行，即启用extended-insert模式。6、以上建议，在线上环境请谨慎评估该骚操作的风险性。7、以上建议，仅考虑尽快导入，涉及到和具体业务需求相冲突时（例如太快导入反倒会影响在线数据库性能），以实际情况为主。
-
发表了文章 2018-11-29
赞，Percona一天内放出二个版本
Percona 在10月31日 发布对Percona Server 8.0 RC版本。 Percona 在10月31日 发布对MongoDB 4.0的支持。 Percona 在10月31日 发布对XtraBackup 测试第二个版本。 Percona 坚持努力为开源事业做贡献，感谢Percona 。 Percona Server for MySQL 8.0下面看看Percona Server 8.0.12-2rc1这个版本和MySQL8.0版本的主要区别 Features Percona Server 8.0.12 MySQL 8.0.12MyRocks Storage Engine Yes NoTokuDB Storage Engine Yes NoInnoDB Full-Text Search Improvements Yes NoExtra Hash/Digest Functions Yes NoINFORMATION_SCHEMA Tables 75 61Global Performance and Status Counters 385 355Per-Table Performance Counters Yes NoPer-Index Performance Counters Yes NoPer-User Performance Counters Yes NoPer-Client Performance Counters Yes NoPer-Thread Performance Counters Yes NoGlobal Query Response Time Statistics Yes NoEnhanced SHOW ENGINE INNODB STATUS Yes No更多详细信息请看 https://www.percona.com/doc/percona-server/8.0/feature_comparison.html Percona XtraBackup 8.0-3-rc1 新增功能 更好的兼容MySQL8.0和Percona Server 8.0 实验性MySQL5.7通过Percona升级到MySQL8.0后执行mysql_upgrade 备份MySQL8.0时，新增选项--lock-ddl #为了支持 LOCK INSTANCE FOR BACKUP 命令 更多详细信息请看 https://www.percona.com/blog/2018/10/31/percona-xtrabackup-8-0-3-rc1-is-available/ Percona Server for MongoDB 4.0官方并没有说具体发布日期，只是说今年可能发布。Percona Server for MongoDB 4.0继续兼容MongoDB 4.0，并加入企业级特性 主要特性 支持多文档事物ACID 支持SCRAM-SHA-256身份验证 新类型转换和字符串运算符 加密的WiredTiger存储引擎 SASL身份验证插件 开源审计 热备份 Percona Memory Engine 兼容和支持Percona Toolkit和PMM 更多详细信息请看 https://www.percona.com/blog/2018/10/31/percona-server-for-mongodb-4-0/ Percona官方还即将推出Percona Server for MySQL 8.0.x GA版，让我们一起期待吧。 感谢Percona 公司对MySQL周边的大力支持，以及对开源社区的回报。
-
发表了文章 2018-11-29
Xtrabackup 8.0.1对MySQL8.0の初体験
在9月12号，Percona Xtrabackup 发布关于支持MySQL8.0的备份支持的测试版本。（作者严重怀疑，是不是因Percona的工程师想听iPhone发布会，所以提前放出Percona Xtrabackup8.0.1~） 版本名称：percona-xtrabackup-80-8.0.1-1.alpha 下载地址：http://t.cn/EvzsG6B （centos7系列）http://t.cn/EvzsCA6 （centos6系列）。 我的老师兼好友 吴sir说过："什么时候能上MySQL8.0，需要等他和他的周边小伙伴都成熟后，方可使用"。 虽然 Percona Xtrabackup 刚刚只发布了测试版本。但是，这是 Percona的一小步，这是产线使用MySQL 8.0的一大步。 关于MySQL8.0的好处，不是本文重点有兴趣的同学可以看 关于MySQL 8.0的几个重点，都在这里 。 下面就让我们看看Percona Xtrabackup 8.0.1 。 首先 大家熟悉的命令 innobackupex 彻底消失了，不过在 percona-xtrabackup2.4中是软件连接的方式存在的。Percona Xtrabackup 8.0.1 备份命令：其次 Percona Xtrabackup 8.0.1对MySQL8.0的备份兼容性测试： 大家都知道MySQL8.0修改了默认认证方式：caching_sha2_password ； 目前市面上的应用想兼容MySQL8.0，则需要修改MySQL8.0的默认认证插件模式 mysql_native_password 。 [root@node2 backup]# xtrabackup Failed to connect to MySQL server: DBI connect(';mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/data/mysql/3306/data/mysql.sock','root',...) failed: Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib64/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory at - line 1314.在Percona Xtrabackup 8.0.1会到指定目录寻到caching_sha2_password.so文件。如没有则会报错，但不影响使用。笔者并没有在MySQL8.0的软件目录中找到caching_sha2_password.so文件，也没有安装后Percona Xtrabackup8.0.1的目录中找到该文件。 [root@node2 backup]# xtrabackup Failed to connect to MySQL server: DBI connect(';mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/data/mysql/3306/data/mysql.sock','root',...) failed: Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib64/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory at - line 1314.在Percona Xtrabackup 8.0.1会到指定目录寻到caching_sha2_password.so文件。如没有则会报错，但不影响使用。笔者并没有在MySQL8.0的软件目录中找到caching_sha2_password.so文件，也没有安装后Percona Xtrabackup8.0.1的目录中找到该文件。 让我们在再来看看恢复的情况 执行命令如下： 需要注意： 恢复后 MySQL datadir权限，MySQL binlog目录以及权限 percona-xtrabackup-2.4 系列针对MySQL5.5、5.6、 5.7的备份恢复，大家都熟悉了，就不在这里介绍了。 原理方面：基本上跟percona-xtrabackup2.4是一致。 备份时候用的锁仍然是 FLUSH NO_WRITE_TO_BINLOG TABLES。而不是MySQL8.0新的备份锁 LOCK INSTANCE FOR BACKUP 和UNLOCK INSTANCE。 Percona官方还即将推出Percona Server for MySQL 8.0.x，让我们一起期待吧。 感谢Percona 公司对MySQL周边的大力支持，以及对开源社区的回报。
-
发表了文章 2018-11-29
怎么让MySQL自动化平台再快10倍？
我的前文《构建MySQL自动化平台思路》中提过的MySQL平台自第一期上线后，一直都是顺风顺水的。 不过.... 在某次代码联调的过程中被前端妹子给喷了一脸：启动关闭页面响应灰常慢，疑似卡死了，好弱鸡啊，顺便还给了我一个神之鄙视... 在苦思N天之后，我完美地解决了这个问题，页面响应效率也得到大幅提升。 下面就来嗦嗦这个问题的解决方案吧。 本次被吐槽的是MySQL实例启停功能，以及查看MySQL状态功能。多说一句，查询MySQL状态功能尤为重要，就像黑暗中的灯塔，指引你的正确的操作。功能页面如下图：下面嗦一下这个功能的设计思路： 前端读取后台数据，并且转递id值返回后台。后端的API接口根据id值进行操作，返回成功或者失败给前端页面。 接口代码如下相信机智的你可能已经感觉到这段代码的问题了： 1、随着MySQL的数量越多，这个页面响应时间就越长。MySQL数量的增长跟响应时间时长成正比。 2、程序造成阻塞，容易崩溃。当MySQL数量为4个的时候，响应时间为10S左右。 当时前端妹子并不知道有这个坑，一顿不耐烦的F5神操作后，系统无可救药地被刷挂了...为了证明男人的尊严：我一定要解决这个问题，让妹子刮目相看....在和zizi老师讨论后，我制定了下面的改进方案：利用现有的组件celery，开启celery定时任务+Redis缓存。大概思路是这样的：1、把当前的主机ID主键和处理结果缓存储到Redis中，格式{id:'True'}代码如下： 2、启用定时任务，每60秒执行一次。（并不需要很强的实时性，因不是监控系统） 3、前端接口返回，通过读取Redis中的结果，返回给前端页面。 代码如下：调整完后，功能页面就再也不卡顿啦，几乎都是秒级响应，妹子的眼神又从俯视变成了仰视。我又重拾了失落的自信心~~~
-
发表了文章 2018-11-29
关于MySQL 8.0的几个重点，都在这里
一、关于MySQL Server的改进 1.1 redo log 重构 在MySQL8.0中重新设计了redo log，主要改进fsync，使得效率更高，减少锁，优化flush机制，不会频繁flush。同时，支持更高用户并发请求。 http://dimitrik.free.fr/blog/archives/2017/10/mysql-performance-80-redesigned-redo-log-readwrite-workloads-scalability.html1.2 MySQL DDL 在MySQL8.0中实现了DDL的原子性。 https://mysqlserverteam.com/atomic-ddl-in-mysql-8-0/1.3 直方图 在MySQL8.0中添加了直方图的概念，用于索引的统计和分析。 https://mysqlserverteam.com/histogram-statistics-in-mysql/1.4 降序索引 MySQL 8.0 开始提供按降序啦~ https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html1.5 隐藏索引 MySQL8.0支持隐藏索引，在对索引的添加和修改，可以通过隐藏索引来实现，方便了索引的管理。 https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html1.6 临时表的改进 在5.7以来，所有内部临时表成为"ibtmp1"的共享表空间。此外临时表的元数据也存储在内存中。 在MySQL8.0中，MEMORY存储引擎也将被TempTable存储引擎替换为内部临时表的默认存储引擎。这个新引擎为VARCHAR和VARBINARY列提供更高效的存储空间。 https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html1.7 持久的全局变量 MySQL8.0通过新语法restart，使下次重启仍然生效。 http://lefred.be/content/mysql-8-0-changing-configuration-easily-and-cloud-friendly/1.8 redo和undo的加密 在MysQL 5.7中，可以为每个表的表空间进行加密。而在MySQL8.0中，还可以为UNDO和REDO LOG进行加密，从而提高了MySQL的安全性。 https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-encryption.html#innodb-tablespace-encryption-redo-log1.9 Innodb 锁的修改 在SQL里添加参数FOR UPDATE NOWAIT和FOR UPDATE SKIP LOCKED，可以设置跳过锁的等待，或者跳过锁定。 https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html#innodb-locking-reads-nowait-skip-locked1.10 窗口函数 在MySQL8.0中，添加了窗口函数，它可以用来实现若干新的查询方式，以便更好地用于数据统计和分析。 http://elephantdolphin.blogspot.com/2017/09/mysql-8s-windowing-function-part-1.html1.11 新的优化器 在MySQL 8.0.3中，引入了新的优化器SET_VAR，用于在SQL中指定参数配置。 https://mysqlserverteam.com/new-optimizer-hint-for-changing-the-session-system-variable/1.12 角色 在MySQL8.0中，添加了角色的功能。更方便了用户的管理 http://datacharmer.blogspot.com/2017/09/revisiting-roles-in-mysql-80.html1.13 字符集的修改 在MySQL8.0.1中，MySQL支持了Unicode 9.0，并且修改了默认字符集为utf8mb4 http://lefred.be/content/mysql-clients-and-emojis/二、关于MySQL 复制的改进 2.1 复制方面修改 在MySQL8.0.3中，关于binlog和复制方面的新的改变。 http://datacharmer.blogspot.com/2017/09/revisiting-roles-in-mysql-80.html2.2 更高效Json复制 在MySQL8.0.3中，关于JSON复制更高效，并提供了新的json功能。在binlog中只记录了update修改的内容，而不是全部记录。 https://mysqlhighavailability.com/efficient-json-replication-in-mysql-8-0/2.3 复制增强 在MySQL8.0.3中，关于对复制的默认参数的修改、对组复制，都增加了“动态跟踪、调试日志”等更多性能方面的监控工具。 https://mysqlhighavailability.com/replication-features-in-mysql-8-0-3/2.4 MySQL 复制新功能 在MySQL8.0中，对于复制的改进，增加了可观察性，提供了复制的效率（基于WRITESET的并行复制）。 https://mysqlhighavailability.com/mysql-8-0-new-features-in-replication/三、关于MySQL MGR的改进 3.1 组复制白名单的支持 在MySQL8.0.4 中，对组复制白名单的支持，有效地提高了组复制的安全性。 https://mysqlhighavailability.com/hostname-support-in-group-replication-whitelist/3.2 MySQL INNODB Cluster 新功能 在MySQL INNODB Cluster 新增加的功能： https://mysqlserverteam.com/mysql-innodb-cluster-whats-new-in-the-8-0-ga-release/3.3 MySQL MGR的监控 提高了MySQL组复制的可观察性和可管理性，并在MySQL8.0.4中增强了相关工具。 https://mysqlhighavailability.com/more-p_s-instrumentation-for-group-replication/四、关于MySQL bug修复 4.1 自增列bug修复（199） 在MySQL8.0 关于自增列的bug的修复。不再采用max（自增id）+1的做法来确定下一个自增id。 http://lefred.be/content/bye-bye-bug-199/
-
发表了文章 2018-11-29
《叶问》第8期
2018年9月21日，周五 innodb已经使用了独立undo表空间，那么ibdata1还会增长吗，为什么？ 1、答：使用独立undo表空间后，ibdata1里主要存储Data dictionary、Rollback segments、Double write buffer、change buffer、Foreign key constraint system tables等数据。 下面两种情况可能还会导致ibdata1文件增长： 1、当使用共享表空间模式时（设置innodb_file_per_table=0），ibdata1还会存储用户数据，导致ibdata1文件增长。（当然了，现在应该几乎没人再这么用了） 2、在高I/O负载时，可能会来不及刷新和回收change buffer page，也会导致ibdata1文件增长。（此种情况再高并发压测情形下更容易出现） 2018年9月30日，周日 怎么安心过好国庆节？ 1、检查备份。不管是逻辑备份、物理备份，还有binlog也要备份。备份文件可恢复，才是好备份。 2、做好安全措施。授权合理不要过大，在外不要连陌生的网络办公。危险操作，尽量等节后执行。 3、健康巡检。节前巡检包括：数据库桩体、硬盘空间、日志信息、物理硬件、系统负载是否预警等。 「知数堂」祝大家节日快乐，DB不宕机跑得欢。 2018年10月9日，周二 MySQL线上实例insert慢常见原因有哪些？ 1、锁等待：SQL产生的间隙锁、自增锁、死锁、MDL锁、外键检查锁，锁等待时间2、iops达到瓶颈：例如备份任务、高频binlog redolog等文件写入3、semi-sync：因为网络抖动，MySQL半同步、增强半同步导致语句卡住4、高并发：高并发场景下，导致系统资源达到瓶颈，从而SQL执行慢5、大字段：当前表索引过多，或者写入大量的text类型数据6、硬件故障：因为磁盘、raid卡、内存等物理硬件故障导致写入慢7、磁盘资源耗尽：操作系统的磁盘、inode资源耗尽8、文件系统故障：MySQL data目录的所在挂在的不可写、或者被设置为只读9、binlog group commit等待 10、参数配置：innodb_buffer、redo_buffer过小 11、autocommit：事物非自动提交，等待程序提交。 2018年10月12日，周五 1、索引字段重复值或者空值太多。 2、查询条件范围太广返回结果数太多，全索引扫描 3、没有利用到覆盖索引，造成大量回表 4、查询字段过多，并且包含大字段 5、索引字段数据分布太随机，回表不多也会引起大量随机io 6、统计信息不准 7、表的单行数据值很大，需要较多io 8、表中包含多个索引， 命中的索引不是最优的索引。
-
发表了文章 2018-11-29
《叶问》第7期
2018年8月9日，周四 MySQL的表中有唯一索引，设置unique_checks为0时，还能否写入重复值？ 1、首先，即便设置unique_checks=0，也无法往唯一索引中写入重复值。2、其次，设置unique_checks=0的作用在于，批量导入数据（例如load data）时，在确保导入数据中无重复值时，无需再次检查其唯一性，加快导入速度。3、所以，unique_checks=0并不是允许唯一约束失效，而是再批量导数据时不再逐行检查唯一性。 2018年8月15日，周六 某人曰，在数据检索的条件中使用!=操作符时，存储引擎会放弃使用索引。 理由：因为检索的范围不能确定,所以使用索引效率不高，会被引擎自动改为全表扫描。你认可他的说法吗？ 1、答：通常情况下，这个说法是正确的。当然，也有特殊情况，话不能说绝对了。 有一个测试表共80万条数据，其中type列只有1、2两个值，分别占比97%和3%。 这种情况下，查询条件 WHERE type != 1，是有可能也可以走索引的。 下面是两个SQL的执行计划： mysql> desc select * from t1 where type = 1G 1. row id: 1 select_type: SIMPLE table: t1 partitions: NULL type: ref possible_keys: type key: type key_len: 4 ref: const rows: 399731 filtered: 100.00 Extra: NULLmysql> desc select * from t1 where type != 1G 1. row id: 1 select_type: SIMPLE table: t1 partitions: NULL type: ref possible_keys: type key: type key_len: 4 ref: const rows: 10182 filtered: 100.00 Extra: NULL type数据分布 mysql> select type, count(*) as cnt from t1 group by type order by cnt; +------+--------+ | type | cnt | +------+--------+ | 2 | 38304 | 2018年8月17日，周一 Redis集群的slot迁移是如何实现的? 1、答：迁移源slot设置为migrating 状态，迁移目标slot设置为importing状态。2、在内部用dump & restore命令，把数据迁移到目标节点，迁移结束之后，移除migrating和importing状态。3、在迁移过程中如果有数据访问，如果数据没迁移到目标节点，那么直接返回结果，如果迁移到目标节点，那么给客户端返回ASK重定向。 2018年8月27日，周一 在大表执行ddl的过程中，若临时中断，会发生什么状况，需要特别处理吗 ？ 前提说明：MySQL5.7.23、innodb表、“双1” 1、添加/删除列，采用copy的方式 1.1、ctrl+c。在当前session中，手动执行ctrl+c。无影响，并且会自动删除产生的临时文件。 1.2、kill -9。在执行ddl的时候，服务器发生意外宕机或者手动执行kill -9。待MySQL启动后，则会自动执行InnoDB Recovered流程。并且不会删除产生的临时文件，需要手工处理。 2、添加/删除索引，采用INPLACE方式 2.1、ctrl+c，同1.1 2.2、kill -9。不会删除临时文件，也不会执行InnoDB Recovered流程并且报错 Operating system error number 2 in a file operation ....OS error: 71 在开始执行alter table的过程中，在没有结束的时候，并不会写入到binglog文件中。
-
发表了文章 2018-11-29
《叶问》第6期
2018年7月26日，周四 专访黄炎:MySQL中间件的性能测试和常规业务性能测试相比有什么不同？ 1、性能测试的方法论基本都一样, 以“观察-分析-改进-再观察”这个循环进行。2、常规业务由于业务交互复杂、技术栈庞杂、性能瓶颈通常集中于业务, 性能测试使用的分析方法比较简单, 通过诊断业务通常可以低成本地找到性能瓶颈。3、MySQL中间件的应用场景比较简单、技术栈稳定、性能瓶颈通常集中于架构和环境, 性能测试使用的分析方法比较多, 对性能瓶颈的分析通常成本比较高. 另外在这一方面的现有知识积累并不很成体系, 也是成本较高的原因之一。 2018年8月2日，周四 《全方位认识SYS系统库》公开课精彩互动问答： 1、为什么我用root用户调用call ps_setup_enable_instrument('wait');报错说存储过程不存在？ 1、答：sys schema是从MySQL 5.7之后才默认支持，请确保你的数据库版本正确，且先使用use语句切换默认数据库，否则请带上 sys.库名称限定前缀。 2、myisam锁如何查询？ 1、答：MyISAM 不支持事务，所以不存在事务锁，但可以查询表级锁（例如：MDL锁），通常表级锁是Server层添加的锁，与具体的存储引擎无关，所以与InnoDB存储引擎查询方法一致，建议多多尝试即可得出答案。 3、为什么我查询session系统表，当前正在执行SQL的会话的progress为 NULL 呢？ 1、答：对于progress信息，仅支持stages事件（performance_schema.setup_instruments表的name字段以stages开头的采集项），其他事件类型不支持，且就算是stages类型事件，也不是所有的采集项都支持，可以通过观察performance_schema.events_stages_current表的WORK_COMPLETED和WORK_ESTIMATED字段，需要不为NULL值，progress信息就是根据这些不为NULL的值进行计算的 注意：要成功采集stages性能数据，必须打开stages事件相关的instruments和consumers如果不满足以上条件，session视图查询到的progress字段就会显示NULL。 4、线上数据库，开启ps和关闭ps功能，mysqld使用的内存会相差20G，可以判断ps会用到很多主机内存。怎么判断ps功能回来多少内存？怎么进行优化ps对内存的使用？ 1、答：ps的整体功能无法动态开关，必须在数据库启动之前就设置好，能够动态开关的只是ps的具体的instruments采集项和consumers存储表，对于查询ps使用的内存总量，可以使用语句 select sys.format_bytes(sum(current_alloc)) from sys.x$memory_global_by_current_bytes where event_name like 'memory/performance_schema%'; 查询，对于ps内存使用的优化，MySQL 提供了一系列performance_schema打头的系统变量来进行灵活配置，请根据需要自行调整，默认情况下不建议调整，除非你真的需求，否则就会浪费内存空间。 2018年8月7日，周二 在MySQL中如果发现乱码的情况该如何判断原因及应对？ 1、直接修改法. alter或者pt-osc等其他工具直接对数据进行修改。2、备份修改法. 利用mysqldump或者其他逻辑备份进行备份，备份的结果集再利用iconv进行转换3、跳过字符集备份.利用mysqldump备份的时候跳过字符集-t --skip-set-charset。在恢复的时候指定表的字符集。 那么应该如何避免乱码呢？ 1、首先要从应用端到MySQL，采用统一编码格式。2、在MySQL的配置中,指定编码格式。3、在上线或者导入SQL的时候，要注意本地的编码集。
-
发表了文章 2018-11-29
《叶问》第5期
2018年7月17日，周二 MongoDB高并发写场景开启读写分离读从库为何阻塞? 我们该如何处理? 1、按业务拆分逻辑降低读写并发度2、添加分片均衡读写 3、升级至即将到来的4.0通过读snapshot解决从库读阻塞 2018年7月19日，周四 MongoDB 4.0有哪些新特性，你最期待的有哪些，为什么？ 1、多文档事务的支持，解决了多文档操作的原子性问题2、snapshot读相关支持，使得可在某个timestamp点上读到一个一致性的快照3、Change Streams 支持实例及库级别粒度为业务提供了更多实时捕获变更的选择4、聚合框架支持类型转换及字符前后空格截断操作5、加入对SCRAM-SHA-256认证策略以支持更强的认证加密验证6、提供通过简单的命令开启免费监控功能7、更多的操作支持w:majority 比如对集合进行分片，创建删除集合等8、listCollections 可以指定nameOnly:true 而不加锁9、增加 rollbackTimeLimitSecs参数控制节点回滚的最大时间限制10、支持直接在mongos路由节点直接kill具体操作无需按分片进行11、使用WiredTiger引擎不允许关闭journal日志 2018年7月24日，周二 Redis如何获取所有的key，不阻塞？ 1、在slave上执行Save命令，拷贝rdb文件到其他redis实例上用于统计key。 2、可以利用scan命令，来遍历当前数据库中的数据库键。、 2018年7月26日，周四 MySQL中间件的性能测试和常规业务性能测试相比有什么不同？ 1、性能测试的方法论基本都一样，以观察-分析-改进-再观察这个循环进行。2、常规业务由于业务交互复杂、技术栈庞杂、性能瓶颈通常集中于业务, 性能测试使用的分析方法比较简单, 通过诊断业务通常可以低成本地找到性能瓶颈。3、MySQL中间件的应用场景比较简单、技术栈稳定、性能瓶颈通常集中于架构和环境, 性能测试使用的分析方法比较多, 对性能瓶颈的分析通常成本比较高。另外在这一方面的现有知识积累并不很成体系, 也是成本较高的原因之一。
-
发表了文章 2018-11-29
《叶问》第3期
2018年6月24日，周日 MySQL 8.0相对于5.7的复制改进，都有哪些呢？ 宋利兵老师：《MySQL 8.0相对于5.7的复制改进》的公开课也讨论了这个命题，简单概括主要有两部分 一、普通复制功能改进 1、新增WRITESET并行复制模式，提高并行度，降低延迟 2、在多源复制中，可在线动态修改每个channel的filter rule，并且能在P_S中查看/监控 3、Binary Log中存储更多元数据，并支持毫秒级别的延迟监控 4、对JSON Documents的复制效率更高了 5、支持DDL Crashsafe 6、增加caching_sha2_password安全策略，提高复制安全性 二、MGR功能改进: 1、支持设置节点权重，且权重最大的在线节点将被选举为主 2、每个节点中存储更多的状态信息，如版本、角色等 3、可根据从节点的事务状态，自动化流控 4、离开集群的服务器自动被设置为read only，避免被误操作更新数据 5、可监控MGR的内存使用情况 2018年6月25日，周一 跑truncate table，4亿条数据会不会造成长时间锁表呢?有什么更好的方法吗? 最好是create新表，然后交叉rename对调，再drop/truncate table或其他方式清除数据。 一、可操作步骤： 1、创建新的 tmp 表，正式表与tmp表表名交换（注意在一个SQL里完成，并锁表） 2、对 tmp 表创建硬链接 ln tmp.ibd tmp.ibd.hdlk 3、mysql中删除表tmp（truncate / drop 都行）4、然后找个业务不繁忙的时间删除数据文件或者用coreutils 的truncate慢慢搞 二、关于truncate table，官档解释： 1、Logically, TRUNCATE TABLE is similar to a DELETE statement that deletes all rows, or a sequence of DROP TABLE and CREATE TABLE statements When a table is truncated, it is dropped and re-created in a new .ibd file, and the freed space is returned to the operating system 2018年6月26日，周二 明明有个索引“感觉”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的原因有哪些？ 一、执行计划如下： 1、desc select * from t1 where c2 >= 2; key: NULL key_len: NULL rows: 14 filtered: 92.86 Extra: Using where 二、可能的原因如下： 1、隐式转换2、表碎片，因为表的碎片率过高3、根据索引读取到的数据在整个表中的数据占比超过30%4、统计信息没有及时更新 三、上述执行计划的结果是： 预计扫描的行数为14行，filtered（是指返回结果的行占需要读到的行的百分比）的值为92%。 当前执行计划中filtered值92% 说明根据索引查询获取的结果占整张表的92%，在MySQL中根据索引查询的结果占整张表的数据30%则不会走索，所以不会走索引。 另外，也有可能是表的碎片率过高或隐式转换导致的。 2018年6月27日，周三 主从复制线程均正常（为Yes，也没报错），Master的binlog已到binlog.000100，但slave上看到Master_Log_File却只到binlog.000090，可能的原因有哪些? 首先要注意，这是Master_Log_File IO线程延迟，并不是Relay_Master_Log_File SQL线程延迟。 一、可能的原因如下: 1、由于sync_relay_log值过低，导致Slave频繁刷新relay_log文件，使 Slave的硬盘资源消耗过高，所以导致SlaveIO Thread很慢。 2、Master/Slave压力过大导致Slave IO Thread不能及时响应， 无法及时获得Master的event。 3、网络丢包严重。小包可以连接并且保持连接不断，但是大包就无法发送。可能是Master和Slave关于TCP MTU值设置不一致导致。 4、Master和Slave网络链接已经断开。但slave_net_timeout值等于0（表示完全禁用心跳）或者slave_net_timeout和Slave_heartbeat_period非常大（表示检测主从心跳的时间）。 5、Master的binlog非常大，io线程的file很长时间都在读同一个。 二、总结 本次案例是在主库进行压力测试，在压力测试的过程中，因为Master本身的压力就很大Master来不及把binlog发送给Slave。所以表面上看起来没有延迟，但实际上已经产生了延迟。
-
发表了文章 2018-11-29
《叶问》第2期
2018年6月20日，周三 为什么说pt-osc可能会引起主从延迟，有什么好办法解决或规避吗？ 1、若复制中binlog使用row格式，对大表使用pt-osc把数据从旧表拷贝到临时表，期间会产生大量的binlog，从而导致延时2、pt-osc在搬数据过程中insert...select是有行锁的，会降低事务并行度；且pt-osc搬数据过程中生成的binlog不是并行的，所以在slave不能并行回放3、可以通过设定参数 --chunk-size、--chunk-time控制每次拷贝数据大小，也可以设定--max-log、check-interval、check-slave-lag等参数控制主从复制延迟程度（但这样可能会造成pt-osc工作耗时太久，需要自行权衡） 2018年6月21日，周四 你遇到过哪些原因造成MySQL异步复制延迟？ 1、master上多为并发事务，salve上则多为单线程回放（MySQL 5.7起，支持真正的并行回放，有所缓解）2、异步复制，本来就是有一定延迟的（否则也不叫做异步了，介意的话可以改成半同步复制）3、slave机器一般性能比master更弱（这是很常见的误区，其实slave对机 器性能要求并不低）4、有时为了节省机器资源，会在slave上运行多个实例5、表结构设计不合理，尤其是在MySQL 5.6之前没主键，几乎会造成所有更新都全表扫描一遍，效率非常低5、slave上运行大量只读低效率的SQL6、大量大事务，也会造成slave无法并行回放 7、业务设计缺陷，或网络延迟等导致延迟 2018年6月22日，周五 MySQL每天产生了多大容量的binlog，用SQL语句能查到吗？ 首先，这是个假设性命题（又一个钓鱼题）。 1、这个需求完全可以通过系统层命令，配合MySQL中的“FLUSH BINARY LOGS”快速完成。 2、运行SHOW MASTER/BINARY LOGS命令能查看全部binlog列表，但没办法区别哪些是当天内生成的。 2018年6月23日，周六 用什么方法可以防止误删数据？ 以下几个措施可以防止误删数据，如下： 1、生产环境中，业务代码尽量不明文保存数据库连接账号密码信息2、重要的DML、DDL通过平台型工具自动实施，减少人工操作3、部署延迟复制从库，万一误删除时用于数据回档，且从库设置为read-only4、确认备份制度及时有效5、启用SQL审计功能，养成良好SQL习惯6、启用 sql_safe_updates 选项，不允许没 WHERE 条件的更新/删除7、将系统层的rm改为mv8、线上不进行物理删除，改为逻辑删除（将row data标记为不可用）9、启用堡垒机，屏蔽高危SQL10、降低数据库中普通账号的权限级别11、务必开启binlog
-
发表了文章 2018-11-29
《叶问》第1期
2018年6月10日，周日 MySQL主从复制什么原因会造成不一致，如何预防及解决？ 一、导致主从不一致的原因主要有： 1、人为原因导致从库与主库数据不一致（从库写入）2、主从复制过程中，主库异常宕机3、设置了ignore/do/rewrite等replication等规则4、binlog非row格式5、异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。 但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。6、从库中断很久，binlog应用不连续，监控并及时修复主从7、从库启用了诸如存储过程，从库禁用存储过程等8、数据库大小版本/分支版本导致数据不一致？，主从版本统一9、备份的时候没有指定参数 例如mysqldump --master-data=2 等10、主从sql_mode 不一致11、一主二从环境，二从的server id一致12、MySQL自增列 主从不一致13、主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点14、采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致，要看binlog是否传到了从库15、启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复制 二、预防和解决的方案有： 1、master:innodb_flush_log_at_trx_commit=1&sync_binlog=12 、slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=13 、设置从库库为只读模式4 、可以使用5.7增强半同步避免数据丢失等5 、binlog row格式6 、必须引定期的数据校验机制7 、当使用延迟复制的时候，此时主从数据也是不一致的（计划内），但在切换中，不要把延迟从提升为主库哦~8 、mha在主从切换的过程中，因主库系统宕机，可能造成主从不一致（mha本身机制导致这个问题） 2018年6月11日，周一 你为什么会决定进行分库分表，分库分表过程中遇到什么难题，如何解决的？ 一、为什么决定进行分库分表？ 1 、根据业务类型，和业务容量的评估，来选择和判断是否使用分库分表2 、当前数据库本事具有的能力，压力的评估3 、数据库的物理隔离，例如减少锁的争用、资源的消耗和隔离等4 、热点表较多,并且数据量大，可能会导致锁争抢，性能下降5 、数据库的高并发，数据库的读写压力过大，可能会导致数据库或系统宕机6 、数据库（MySQL5.7以下）连接数过高，会增加系统压力7 、单表数据量大，如SQL使用不当，会导致io随机读写比例高。查询慢（大表上的B+树太大，扫描太慢，甚至可能需要4层B+树）8 、备份和恢复时间比较长 二、都遇到什么问题? 1 、全局pk（主键和唯一索引）的冲突检测不准确，全局的自增主键支持不够好2 、分片键的选择。如没有选择好，可能会影响SQL执行效率3 、分布式事务，中间价产品对分布式事务的支持力度4 、对于开发来说，需要进行业务的拆分5 、对于开发来说，部分SQL不兼容则需要代码重构，工作量的评估6 、对于开发来说，跨库join，跨库查询 三、如何解决? 1 、使用全局分号器。或者使用全局唯一id，（应用生成顺序唯一int类型做为全局主键）2 、应用层来判断唯一索引3 、配合应用选择合适的分片键，并加上索引4 、配合应用，配合开发，对不兼容SQL的进行整改 2018年6月12日，周二 MySQL高可用架构应该考虑什么? 你认为应该如何设计？ 一、MySQL高可用架构应该考虑什么？ 1 、对业务的了解，需要考虑业务对数据库一致性要求的敏感程度，切换过程中是否有事务会丢失2 、对于基础设施的了解，需要了解基础设施的高可用的架构。例如 单网线，单电源等情况 3 、对于数据库故障时间掌握，业务方最多能容忍时间范围，因为高可用切换导致的应用不可用时间4 、需要了解主流的高可用的优缺点：例如 MHA/PXC/MGR 等。5 、考虑多IDC多副本分布，支持IDC级别节点全部掉线后，业务可以切到另一个机房 二、你认为应该如何设计? 1 、基础层 和基础运维部门配合，了解和避免网络/ 硬盘/ 电源等是否会出现单点故障 2、应用层 和应用开发同学配合，在关键业务中记录SQL日志，可以做到即使切换，出现丢事务的情况，也可以通过手工补的方式保证数据一致性，例如：交易型的业务引入状态机，事务状态，应对数据库切换后事务重做 3、业务层 了解自己的应用，根据不同的应用制定合理的高可用策略。 4 、单机多实例 环境及基于虚拟机或容器的设计不能分布在同一台物理机上。 5 、最终大招 在数据库不可用 ，可以把已提及的事务先存储到队列或者其他位置，等数据库恢复，重新应用 2018年6月13日，周三 MySQL备份，使用xtrabackup备份全实例数据时，会造成锁等待吗？那么如果使用mysqldump进行备份呢？ 一、xtrabackup和mysqldump会造成锁等待吗？ 1 、xtrabackup会，它在备份时会产生短暂的全局读锁FTWL(flush table with read lock)，用于拷贝frm/MYD/MYI等文件，以及记录binlog信息。如果MyISAM表的数据量非常大，则拷贝时间就越长，加锁的时间也越长2、mysqldump有可能会。如果只是添加 --single-transacton 选项用于保证备份数据一致性，这时就不会产生FTWL锁了。但通常我们为了让备份文件和binlog保持一致，通常也会设置 --master-data 选项用于获得当前binlog信息，这种情况也会短暂加锁3 、数据量特别大的话，建议优先用 xtrabackup，提高备份/恢复速度。而如果数据量不是太大或者想备份单表，则建议用mysqldump了，方便逻辑恢复。各有利弊，注意其适用场景 二、xtrabackup冷知识 1 、基于MySQL 5.6版本开发的xtrabackup，会在备份过程中生成内部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，备份结束后文件删除，默认文件位置 /tmp/xtrabackup_suspended 2 、如果在备份过程中，修改了 /tmp 的访问权限或该文件的权限，则两个程序间直接不能通信，会造成 xtrabackup hang 住，正在备份的表不能正常释放锁，会造成锁等待，此时需要强制 kill 掉 xtrabackup 进程 2018年6月15日，周五 MySQL 5.7开始支持JSON，那还有必要使用MongoDB存JSON吗？请列出你的观点/理由。 一、观点A：支持MySQL存储JSON 1 、MongoDB不支持事务，而MySQL支持事务2 、MySQL相对MongoDB而言，MySQL的稳定性要优于MongoDB3 、MySQL支持多种存储引擎 二、观点B:支持MongoDB存储JSON 1 、从性能的角度考虑，对于JSON读写效率MongoDB要优于MySQL2 、MongoDB相对MySQL而言，MongoDB的扩展性要优于MySQL3 、MongoDB支持更多的JSON函数 三、总结 1 、如果应用程序无事务要求，存储数据表结构复杂并且经常被修改， 例如游戏中装备等场景用MongoDB比较适合2 、如果应用程序有事务要求，存储数据的"表"之间相互有关联，例如有订单系统等场景用MySQL比较合适3 、整体来看相对看好MySQL的JSON功能，在未来官方的努力下MySQL的JSON功能有机会反超MongoDB 2018年6月17日，周日 当数据被误删除/误操作后造成数据丢失。你尝试过用什么手段来挽救数据/损失？ 一、前提 1 、当数据被误删除/误操作后，第一时间要关闭数据库。业务方需要紧急挂停机公告，避免数据二次污染，用于保护数据的一致性2 、BINLOG格式为ROW格式，不讨论其他格式的BINLOG 二、数据被误操作(update/delete/drop)造成数据丢失，可以用哪些手段来恢复？ 1 、BINLOG恢复：可以使用逆向解析BINLOG工具来恢复。例如：binlog2SQL等2 、延迟从库: 可以通过解除延迟从库，并指定BINLOG结束位置点，可以实现数据恢复 三、数据被误删除(rm/物理文件损坏)造成数据丢失，可以用哪些手段来恢复？ 1 、如果有备份，可以通过备份恢复 mysqldump/xtrabackup + binlog 来实现全量+增量恢复2 、如果无备份但是有从库，可以通过主从切换，提升从库为主库，从而实现数据恢复3 、如果无备份并且无从库，但MySQL没有重启，可以通过拷贝/proc/$pid/fd中的文件，来进行尝试恢复4 、如果无备份并且无从库，但MySQL有重启，可以通过extundelete或undrop-for-innodb来恢复 2018年6月19日，周二 MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中，该如何选择？ 一、生产环境中： 几种复制场景都有存在的价值。下面分别描述一下： 1 、从成熟度上来选择，推荐：异步复制(GTID+ROW)2 、从数据安全及更高性能上选择：增强半同步 （在这个结构下也可以把innodb_flush_log_trx_commit调整到非1， 从而获得更好的性能)3、对于主从切换控制觉的不好管理，又对数据一致性要求特别高的场景，可以使用MGR 二、理由： 1 、异步复制，相对来讲非常成熟，对于环境运维也比较容易上手 2 、增强半同步复制，可以安全的保证数据传输到从库上，对于单节点的配置上不用要求太严格，特别从库上也可以更宽松一点，而且在一致性和性能有较高的提升，但对运维上有一定的要求3 、MGR组复制。相对增强半同步复制，MGR更能确保数据的一致性，事务的提交，必须经过组内大多数节点（n/2+1）决议并通过，才能得以提交。MGR架构对运维难度要更高，不过它也更完美 总的来讲，从技术实现上来看：MGR> 增强半同步>异步复制。 未来可能见到更多的MGR在生产中使用，对于MySQL的运维的要求也会更上一层楼。
-
发表了文章 2018-07-02
一次MySQL反应慢排查
MySQL反应慢排查 前言 话说某天的一个阳光明媚的下午，我正在公司的楼下喝着咖啡，听着歌。本来心情美滋滋，突然微信收到一条消息：‘现在10.X.X.X MySQL 反应很慢，xx库反应都很慢’，婉如晴天霹雳，百米冲刺的速度跑到办公桌前开始排查问题。 第一招 纵览大局 登录到MySQL系统中，第一件事，先进行top来确定一个大范围。如下几个比较重要的信息 load average #当前OS的系统负载，分别是1分钟，5分钟，15分钟。主要目的是确定当前的系统大概的压力范围。 %Cpu(s): 0.0 us, 0.3 sy, 0.0 wa #分别对应用户执行程序所消耗的资源占CPU的百分比、内核所消耗占CPU的百分比、等待IO输入输出占CPU时间百分比 KiB Mem : 481876 total, 9300 free, 269364 used, 203212 buff/cache KiB Swap: 2096124 total, 2094580 free, 1544 used. 165964 avail Mem #MEM、SWAP的总量、使用、空闲 一般情况，在观察top输出中，如果发现 us很高，可能是慢查询，SQL执行效率差导致，等其他原因导致的。 如果是sy很高，可能是锁、NUMA等导致。 如果是wa很高，可能是MySQL大量使用临时表、在进行存在备份任务 需要iotop在一次确认等。 如果是Mem中的free空闲内存较少，请检查是否发生内存泄漏，是否使用大量的内存临时表或者错误的参数配置等。 如果是KiB Swap频繁使用，请检查vm.swappiness参数和NUMA是否关闭。 第二招 细化分析 登录到系统中打开慢查询日志 tail -0f 慢查询.log 或者查询最近期间的慢查询日志，主要检查是否有复杂的SQL 有大量的排序、分组、like %等大量不走索引或者需要临时表操作。 并且登录到MySQL中进行查看是否有事物未提交，是否有发生锁等待。select * from information_schema.INNODB_TRX 查看大事物。主要观察当前事物执行状态和事物执行时间。 select * from information_schema.INNODB_LOCKS#查看当前锁信息。主要观察当前有多少行被锁住 select * from information_schema.PROCESSLIST #查看当前的SQL执行情况。主要观察是否有 Waiting for table metadata lock 或者表锁、全局读锁等SQL。 还有观察当前的MySQL每秒的TPS、QPS、当前的连接数、错误连接数。如果你的TPS、QPS达到了历史高峰，并和业务确认是业务猛增，那么恭喜了。如果是连接数达到了高峰期，请和开发同学确认，是否代码出现了bug，例如连接未关闭等。 IO排查需要使用iotop、pt-ioprofile、sar等，主要关注每秒的顺序和随机写入、读取量，当前的队列数等值。 网络排查则需要使用ping 网关orAPP，检查是否丢包，是否有延迟。补充知识点ping可以指定参数 -l 和 -f快速检测丢包和检测丢包。 总结 上述MySQL反应慢是常见问题，几乎每个DBA或多或少都遇见过，但每个人使用的工具和排查思路的方式和方法是不一样的。本文也是简单介绍一下改如何排查，除了这些方法以外还有其他原因导致MySQL反应慢嘛，有的 笔者曾经出来过一起故障 MySQL反应慢，MySQL版本是6.0的比较特殊。希望能给你的学习和工作带来收获。
-
发表了文章 2018-06-05
有爱有恨的MDL锁
一。前言 MySQL 5.5 中就引入了metadata lock（元数据锁）。用于对管理 database objects（数据库对象）的并发访问，保证数据的一致性。 二.了解MDL锁 2.1 MDL锁消耗 MDL的引入会导致一定的性能的损耗，对同一个database objects的访问越多，就会导致该对象的MDL的争用。 2.2了解MDL锁 为了维护表元数据的数据一致性，在表上有活动事物（显示或者隐式）的时候，不可以对元数据进行写入操作，MySQL引入了metadata lock，来保护表的元数据信息。因此在对表进行上述操作时，如果表上有活动事物（未提交或回滚），请求写入的会话，会等待在metadata lock wait。 2.3什么场景会导致MDL 场景一 session1 session2 begin null select * from t null null alter table t xx | 6 | root | localhost | d1 | Query | 144 | Waiting for table metadata lock | alter table t1 ENGINE=InnoDB | 当session1 开启事物没有提交对t表进行查询，同时session2 对t表进行alter 修改。则会造成MDL锁 场景2 session1 session2 begin null select * from t null null drop table t 当session1 开启事物没有提交对t表进行查询，同时session2 对t表进行dorp操作。则会造成MDL锁； | 6 | root | localhost | d1 | Query | 6 | Waiting for table metadata lock | drop table t1 那些操作会获得metadata lock 1.表结构的更改（alter） 2.创建删除索引 3.删除表 4.对表加写锁，进行读操作。对表加读锁，进行写操作。 三.恨MDL 因为MDL锁，会导致表级别的锁，无论是读或者写操作，都无法进行，导致SQL的阻塞。如监控不到位，在高并发的情况下，就会造成大量的SQL阻塞。除非人工干预或者ddl结束。 四.爱MDL MDL的主要目的是为了保护元数据，假如、假如没有MDL锁，会导致什么 读到的元数据不一致，写入的时候发生元数据冲突。MDL不是洪水猛兽，不是可怕灾难，是有办法避免的。例如DDL可以在业务低峰期使用pt-osc进行操作或者gh-ost，来进行操作。备份也要放到业务低峰期去做，当然也要做好监控和报警，对于未提交的事物要尽快提交，或者kill到没有commit的事物。 五.如何监控MDL MySQL 5.5 select * from information_schema.processlist where state = 'Waiting for table metadata lock'; MySQL 5.6 select * from performance_schema.metadata_locks; 开启performance_schema root@mysqldb 10:03: [performance_schema]> update performance_schema.setup_instruments set ENABLED = 'YES',TIMED='YES' where name = 'wait/lock/metadata/sql/mdl'; root@mysqldb 10:02: [performance_schema]> update performance_schema.setup_consumers set ENABLED = 'YES' where name in ('global_instrumentation'); MySQL5.7 select * from schema_table_lock_waits 六.如何kill掉MDL 6.1.第一种情况 session1 开启先大事物，session2后执行DDL第一种情下还分为二种情况 6.1.1 session1的事物没有执行完毕 则kill session2 可以通过下面的SQL进行观察，可以自行评估 root@mysqldb 10:17: [information_schema]> select * from information_schema.INNODB_TRX\G 6.1.2 session1的事物没有提交，后面的事物没有对该表进行操作 则kill session1 6.2 第二种情况，session1先执行DDL，session2执行DML语句如果DDL执行到10% 到20% 。则kill session1 选择业务低峰期执行如果DDL执行到80%到90%。则kill session2 优先执行DDL需要根据实际情况自行执行。 七.总结 MDL是保护数据库对象，保证数据一致性。MDL不是洪水猛兽，DDL和备份需要跟业务方沟通后，在业务低峰期去执行，不要给开发DDL权限哦~ 做对MySQL的监控信息包括锁信息或者死锁信息。
-
发表了文章 2018-04-10
用了并行复制居然还有延迟
环境描述 前端是ogg 后端是mariadb galera cluster 2个节点，其中一个galera节点挂了一个slave从库。 大概环境是这样的 ogg -->mariadb galera cluster*2 -->slave。 简单理解就是mariadb master-->slave 直接的延迟。（另外一个galera节点没有用到）。 mariadb版本为10.1.14。开启了并行复制 模式为optimistic。线程数为20 在通过业务层面模拟压力测试。发现mariadb master-->slave 延迟大约为1分钟左右。希望MySQL DBA帮整延迟延迟时间最好限制在3秒甚至没有延迟。 mariadb 并行复制概念描述 mariadb并行复制总体来说分为三种:按照顺序并行保守模式（默认模式），乱序并行复制，乐观模式的有序并行复制。 个人理解： 有序方式：并行执行事物，但对commit顺序进行排序。以确保主库上事物提交顺序和从库顺序一致。这种模式的并行复制对应用来说完全透明。 无序方式：并行执行事物，主库的提交的事物顺序可能跟从库的执行顺序不一致。无序方式只能在gtid模式和应用明确指定使用无序的时候才会被使用。无序方式性能是最好，但需要GTID和应用的配合。 乐观并行复制模式：任何DML语句都可以并行运行，这可能会在slave导致冲突，如果二个事物视图修改同一行，检测到这样的冲突。这二个事物，后者会回滚，前者会执行，一旦前着执行，后者事物重新尝试。这种模式会受到slave_domain_parallel_threads限制。 官方描述如下Any transactional DML (INSERT/UPDATE/DELETE) is allowed to run in parallel, up to the limit of @@slave_domain_parallel_threads. This may cause conflicts on the slave, eg. if two transactions try to modify the same row. Any such conflict is detected, and the latter of the two transactions is rolled back, allowing the former to proceed. The latter transaction is then re-tried once the former has completed. 问题排查 在业务层模拟压力测试的时候通过dstat， 观察发现 io利用率不超过50%,cpu利用率不超过50%。通过dstat观察发现瓶颈可能不在主从服务的性能上，而是参数的配置。从而进行参数的调整。首先是并行复制的模式，把乐观并行复制模式（optimistic）调整为conservative，并行的线程数进行调整为12个。本人用sysbench 模拟客户的环境进行压力测试。我的环境为1C2G 版本跟线上环境一致，threads 为200。测试结果 optimistic conservative 5s 0s 14s 7s 24s 15s 33s 24s 42s 32s 51s 41s 60s 49s 69s 58s 78s 67s 87s 75s 发现确实通过对模式的修改，能够缓解主从复制的延迟，但不能彻底的解决。在次测试，通过pt-ioprofile发现redo写入占大部分。通过对参数的调整 sync_binlog = 0 innodb_flush_log_at_trx_commit =0 master_info_repository = TABLE relay_log_info_repository = TABLE log_slave_updates=off 再次进行测试 conservative_old conservative_new 0s 2s 7s 4s 15s 0s 24s 1s 32s 0s 41s 0s 49s 0s 58s 2s 67s 0s 75s 0s 通过这次调整，发现确实已经几乎没有延迟了。那么为什么调整innodb_flush_log_at_trx_commit参数会对主从延迟有影响呢。 0 每秒刷出一次log，避免性能问题。 1 在事务提交的时候，强制必须刷出所有log才算提交成功。 2 在0和1之间自动调整。 在从库的环境中设置了innodb_flush_log_at_trx_commit=0和sync_binlog=0，在主从切换的过程中可以在脚本中把这二个参数修改为1，避免在切换主库后，主库宕机导致事物的丢失。 问题解决 按照剧本来说，调整了上面的参数，理论上能够解决了复制延迟，然而 然而 实际情况并没有。只是减少了延迟度，并没有根本解决延迟，这时候就很奇怪了，测试环境已经解决了延迟，为什么在实际环境中没有解决呢。，通过解析binlog 发现binlog的事物比没有ogg的环境中要大。后来，我ORACLE的同事协助排查。居然发现是OGG那层进行事物合并，把原来小的事物进行合并成了大事物，然后因为大事物产生了延迟。后来他调整了OGG的参数GROUPTRANSOP，终于搞定。# 注 GROUPTRANSOPS为以事务传输时，事务合并的单位，减少IO操作； 导致延迟的因素 MySQL或者mariadb复制的瓶颈点？ 默认的 MySQL的从库 io线程和sql线程 都是单线程。而MySQL的主库是并行写入。MySQL的并行复制是增加多个SQL线程，其原理大概是 首先主库必须标记某几个事物是同时提交，也就是last_commited的值是相同的才能在从库上并行回放。从库会有N个线程来等待事物处理。slave_parallel_threads 值建议为8到12个为最佳 如果大于12个，会增加MySQL维护sql线程的成本，反而会影响性能。 是什么导致 MySQL或mariadb复制? 大体分类为 主库的表没有主键 唯一 普通索引 或者有大事物在阻塞。从库的延迟因素有从库的性能跟不上主库，主从之间网络延迟,抖动阻塞,从库的参数配置不争取等。 那些参数可以减少主从延迟？1.增大从库innodb_buffer_pool_size 可以缓存更多数据 减少由于转换导致的io压力2.增大 innodb_log_size innodb_log_files_in_group的值 减少buffer pool的刷盘io 提示写性能3.修改参数 innodb_flush_method 为o_DIRECT 提升写入性能4.把从库的binlog关闭 或者关闭log_slave_updates5.修改参数innodb_flush_log_at_trx_commit 为0或26.如果binlog没关闭 修改sync_binlog 参数为0或者一个很大的值 减少磁盘io压力7.如果binlog格式为row 则需要加上主键8.binlog格式为statement模式 存在ddl复制 可用讲tmpdir参数改到内存中 比如 dev shm9.修改参数 master_info_repository relay_log_info_repository 为table 减少直接io导致的磁盘压力
-
发表了文章 2018-04-10
基于MGR高可用异地多活方案
一．概述主要目的实现MySQL高可用解决方案，实现异地多活。二．实现构思 基于MGR实现高可用异地多活首先要基于位置信息进行分片，例如华北 华中，华南，程序层要进行ip过滤和判断，针对不同的ip 写入到不同的分片集合中，每张表需要有一个地理位置字段。例如获得ip为华北，Create table xx（id int，Name varchar（111），Position int）华北 表示为0华中表示为1华南表示为2根据Position 字段进行分片。其次可以根据时间维度或者用户id，或者其他分片规则进行二次分片。要具备二次分片的能力 每个分片节点需要提供2个slave。用于分担读请求的压力。 三．故障处理 假设 NODE1节点故障首先NODE1节点下面的slave 停止工作，此前通过DNS记录把NODE1的ip在指向相近的节点为NODE2NODE2节点提供本身的华中的读写请求，并再次同时也接管了NODE1的读写请求。 实现方式 基于consul的提供服务发现和健康检查，并提供DNS切换的功能。 NODE1 故障后的恢复首先提供最近的节点NODE2节点进行基于binlog的恢复。等数据追平，在进行slave1和slave2的数据同步，等全部同步完成后在对外提供服务。假设 NODE2的binlog已经清理，首先通过NODE2的slave1或者slave2上获取一份全备在NODE1节点进行恢复。等待恢复后，则通过主从的方式把数据追平。然后在添加到MGR集群环境中。等待数据追平，在挂着NODE1下面的slave1和slave2 等待数据追平后在提供服务 NODE1和NODE2同时故障整个集群会停止服务，MGR集群则无法继续工作。并触发s1级别告警。修复方法 首先修复NODE2 然后在修复NODE1可参考NODE1故障恢复方案进行恢复 四 难点1.首先需要中间件要支持MGR，并支持二次分片2.需要提供全局自增id，实现。每次insert 首先要获得一个全局的自增id，避免分片的合并造成的主键冲突，和产生自增锁3.基于consul的dns的重新指向，或者使用其他的dns api服务通过脚本来实现，但需要实现分布式的健康检查和监控。4.目前MGR并不成熟 需要等待官方成熟的MGR 可提供生产环境，预计今年的下半年。5.瓶颈在于网络，可以同城，不建议跨城。
-
发表了文章 2018-04-10
成为MySQL DBA 博客系列-数据库升级
数据库供应商通常每个月都会发布一些有bug /安全性修补程序的补丁，我们为什么要关心？新的版本可能对关于安全漏洞和黑客入侵系统的修复，所以除非安全性不被关注，否则您可能希望在您的系统上安装最新的安全修补程序。其中MySQL主要版本比较少见，通常是次版本升级。但是他们可能会带来一些重要的功能，使升级更值得付出。 在这篇博文中，我们将介绍DBA的一个最基本的任务 - 次要版本数据库升级和主要数据库升级 MySQL升级 有二个版本MySQL官方已经不在关注和修复，是因为在oracle收购MySQL之前的发行版本。它发生在2013年12月4日的MySQL 5.1以及2012年1月9日的MySQL5.0之前。在GA发布8年后的2018年，MySQL 5.5也会发生这种情况。这意味着对于MySQL 5.0和MySQL 5.1，用户不能依靠官方的修复 - 即使是严重的安全漏洞。这通常是您真正需要计划将MySQL升级到更新版本的一点。 友情建议 推荐使用MySQL5.6最新 或者 MySQL5.7.20之后的版本。叶师傅的朋友圈已经有说关于MySQL5.7.20之前的bug。 但是，您不会只处理主要的版本升级，而是在工作中更经常地升级到次要版本，例如5.6.x - > 5.6.y. 最有可能的是，最新版本会为影响工作负载的错误带来一些修复，但也可能是其他原因。 在执行主版本和次版本升级方式方面存在显着差异。 友情建议 关于版本子版本升级 尤其是成熟的版本，大多数是对bug的修复。可以根据发行说明来判断是否要升级。不过不建议使用子版本低于20 准备工作 在您考虑执行升级之前，您需要决定需要进行哪种测试。理想情况下，您有一个测试/开发环境，可以为常规版本进行测试。如果是这样的话，进行升级前测试的最好方法就是使用新的MySQL版本来构建临时环境的数据库层。一旦完成，您可以继续进行一组常规测试。更多更好 - 你不仅要关注“xx功能/xxbug”方面，还要关注性能。 在数据库方面，你也可以做一些通用的测试。为此，您需要一个慢日志格式的查询列表。然后，可以使用pt-upgrade在旧版本和新版本的MySQL上运行它们，比较响应时间和结果集。在过去，我们已经注意到，pt-upgrade会返回很多误报 - 它可能会将查询报告为慢，而事实上，两个版本的查询都是完全正确的。为此，您可能需要引入一些额外的完整性检查 - 解析pt-upgrade输出，获取报告的慢速查询，再次在服务器上执行这些查询，并再次比较结果。你需要记住，你应该以同样的方式连接到新旧数据库服务器（套接字连接将比TCP更快）。 这种通用测试的典型结果是执行计划发生变化的查询 - 通常添加一些索引或强制优化器选择正确的查询就足够了。您还可以看到结果集中存在差异的查询 - 这很可能是查询中缺少显式ORDER BY的结果 - 如果不对其进行排序，则无法依赖行的排序方式。 友情建议 关于升级 操作之前强烈要求备份。个人认为 一个DBA除了要考虑性能，更多的是稳定，安全。 次要版本升级 小升级相对容易执行 - 大多数情况下，您只需要使用发行版的软件包管理器来安装新版本即可。一旦你这样做，你需要确保升级后MySQL已经启动，然后你应该运行mysql_upgrade脚本。该脚本遍历数据库中的表，并确保它们与当前版本兼容。它也可能修复你的系统表，如果需要的话。 显然，安装新版本的软件包需要停止服务。因此您需要规划升级过程。如果使用Galera Cluster或MySQL复制，它可能会略有不同。 MySQL复制 当我们处理MySQL复制时，升级过程相当简单。您需要通过升级slave，在执行升级所需的时间内将其停止运行（如果一切顺利，不超过几分钟的停机时间，则是很短的时间）。为此，您可能需要在代理配置中进行一些临时更改，以确保流量不会被路由到正在维护的slave设备。这里很难给出任何细节，因为这取决于你的设置。在某些情况下，可能甚至不需要进行任何更改，因为代理可以自行适应拓扑更改，并检测哪个节点可用，哪个不可用。顺便说一句，这就是你应该如何配置你的代理。 一旦每个从机都被更新，您需要执行一个计划的故障切换。我们在较早的博客文章中讨论了这个过程。该过程也可能取决于您的设置。如果你有自动化的工具（例如MHA），它不一定是手动的。一旦选出新的主服务器并完成故障切换，则应该对旧主服务器执行升级，此时应该将新服务器从新主服务器上删除。这将结束MySQL复制设置的次要版本升级。 个人建议 升级从库的时候 一定要留心主从的报错 show slave status中的error。 Galera升级使用Galera，执行升级要容易一些 - 您需要逐个停止节点，升级停止的节点，然后重新启动，然后再转到下一个节点。如果您的代理需要一些手动调整来确保流量不会受到正在进行维护的节点的攻击，则必须进行这些更改。如果它可以自动检测所有的东西，你只需要停止MySQL，升级并重新启动。一旦您浏览了集群中的所有节点，升级就完成了。 个人建议 升级Galera 一定要测试 测试 测试 备份 备份 备份。有个比较完善的回退方案.猥琐发育，不要浪。 主要版本升级 MySQL中的主要版本升级将是5.x - > 5.y甚至4.x> 5.y。这样的升级比较复杂，比较复杂，我们刚刚在前面的段落中提到的小升级。 执行升级的推荐方式是转储并重新加载数据 - 这需要一些时间（取决于数据库的大小），但是在从站不在旋转的情况下执行升级通常是不可行的。即使使用mydumper / myloader，这个过程也会花费很长时间。一般来说，如果数据集大于几百GB，则可能需要额外的准备工作。 尽管可能只是进行二进制升级（安装新软件包），但不建议这样做，因为旧版本和新版本之间可能存在一些二进制格式的不兼容问题，甚至在执行mysql_upgrade之后，仍然可能造成一些问题。我们已经看到了二进制升级导致的一些奇怪的行为，如何在优化器的工作原理，或导致不稳定。所有这些问题都通过执行转储/重新加载过程来解决。所以，虽然运行二进制升级也许可以，但是您也可能遇到严重的问题 - 这是您的要求，最终是您的决定。如果您决定执行二进制升级，则需要执行详细（耗时）的测试，以确保不会破坏任何内容。否则，你有风险。 MySQL复制 如果我们的设置基于MySQL复制，我们将在新的MySQL版本上构建一个从站。假设我们正在从MySQL 5.5升级到MySQL 5.6。由于我们必须执行一个很长的转储/重新加载过程，我们可能需要为此构建一个单独的MySQL主机。最简单的方法是使用xtrabackup从一个从站获取数据以及复制坐标。这些数据将允许您将新节点从旧节点上删除。一旦新节点（仍在运行MySQL 5.5 - xtrabackup只是移动数据，所以我们必须使用相同的，原始的MySQL版本）启动并运行后，是时候转储数据了。您可以使用我们之前在“备份和还原”中发布的任何逻辑备份工具。只要您稍后可以恢复数据，则无关紧要。 转储完成后，该停止MySQL，清除当前数据目录，在节点上安装MySQL 5.6，使用mysql_install_db脚本初始化数据目录并启动新的MySQL版本。那么是时候加载转储 - 这个过程也可能需要很长时间。一旦完成，你应该有一个新的和干净的MySQL 5.6节点。现在是时候把它和master一起同步了 - 你可以使用xtrabackup收集的坐标将节点从运行MySQL 5.5的生产集群的成员中删除。这里需要记住的重要一点是，如果您最终要将节点从当前的生产群集中删除，则需要确保二进制日志不会旋出。对于大型数据集，转储/重新加载过程可能需要几天，因此您需要调整expire_logs_days因此在主人。你也想确认你有足够的可用磁盘空间用于所有这些binlog。 一旦我们拥有一个MySQL 5.5从属MySQL 5.5主服务器，现在是时候浏览5.5个从服务器并升级它们了。现在最简单的方法是利用xtrabackup从5.6节点复制数据。所以，我们把一个5.5从机停掉，停止MySQL服务器，清除数据目录，将MySQL升级到5.6，使用xtrabackup从其它5.6从机恢复数据。一旦完成，您可以再次设置复制，并且应该全部设置。 这个过程比为每个从站执行转储/重新加载要快得多 - 每个复制群集执行一次就可以了，然后使用物理备份来重建其他从站。如果您使用AWS，则可以依靠EBS快照而不是xtrabackup。与逻辑备份类似，只要能够正常工作，重建从站的方式并不重要。 最后，一旦所有从站都升级完毕，您需要从5.5主站到5.6从站之一进行故障切换。在这一点上，可能发生的情况是，您将无法在复制中保留5.5（即使您在它们之间设置了主 - 主复制）。一般来说，不支持从新版本的MySQL复制到较旧的版本 - 复制可能会中断。不管怎么样，您都需要使用与从服务器相同的流程来升级和重建旧的主服务器。 Galera升级 与MySQL复制相比，Galera同时更加容易升级。用Galera创建的集群应该被看作是一个MySQL服务器。在讨论Galera升级时，记住这一点至关重要 - 它不是一个拥有一些slave或者相互连接的master - 就像一台服务器一样。要执行单个MySQL服务器的升级，您需要执行脱机升级（使其不能轮换，转储数据，将MySQL升级到5.6，加载数据，重新启动它）或创建一个从属服务器，升级它并最终故障转移到它（我们在上一节讨论MySQL复制升级时描述的过程）。 同样的事情适用于Galera集群 - 您要么升级所有节点（所有节点），要么必须构建一个从属节点 - 另一个通过MySQL复制连接的Galera集群。 在线升级过程可能如下所示。对于初学者来说，你需要在MySQL 5.6上创建slave - 进程与上面完全一样：创建一个包含MySQL 5.5的节点（可以是Galera但不是必须的），使用xtrabackup复制数据和复制坐标，dump数据使用逻辑备份工具，清除数据目录，将MySQL升级到5.6 Galera，引导集群，加载数据，从节点关闭5.5 Galera集群。 此时，您应该有两个Galera群集 - 5.5和一个Galera 5.6的单个节点，都通过复制连接。下一步将是建立一个生产规模的5.6集群。很难说如何做 - 如果你在云端，你可以旋转新的实例。如果您在数据中心中使用共置服务器，则可能需要将某些硬件从旧群集移到新群集。您需要记住系统的总容量，以确保它能够处理一些不能轮换的节点。虽然硬件管理可能会非常棘手，但最好不要过多关注构建5.6群集 - Galera将使用SST自动填充新节点。 一般来说，这个阶段的目标是建立一个足够处理生产工作量的5.6集群。一旦完成，您需要故障转移到5.6 Galera群集 - 这将结束升级。当然，您可能仍然需要添加更多的节点，但现在是一个定期调配Galera节点的过程，现在只使用5.6而不是5.5。
-
发表了文章 2018-04-10
MySQL DBA 日常工作
导读： 最近有很多同学在跑路，有的会选择加入到DBA这个行业，可能之前做过开发，或者运维等相关行业，写这篇文章就是想让大家了解一下MySQL DBA正常工作的内容。也让大家更了解MySQL DBA。 DBA（Doctorate of Business Administration，工商管理硕士），然而并不是。也许在有些人眼中看DBA这个行业很闲一天没什么事喝喝茶水，看看报纸就下班了。也许有人看我司的DBA为啥忙成狗啊，也不知道天天在忙些什么。那么下面就简单说一下MySQL DBA的日常工作。 首先你刚来一个新的环境，或内部转岗位。第一件事就是要尽快的熟悉你的库，实例，主机等相关的信息。要做到心中有数，其中包括（高可用，备份信息等）如果这些已经完善了。那么恭喜你，今晚可以睡一个安稳觉了。当然在以后的上班期间，你要校队和检查备份，要保证高可用和备份都是可用的。 其次要熟悉MySQL的配置参数，linux系统的参数的，是否前任或者运维人员是否有配置错误，或者高可用的选择上有误，如果发现有误，要记录下来。并有计划整改。不要太过激。工作要有工作的方法和方式。 然后要进行系统和MySQL的错误日志还有slow log的查看。检查是否有错误，如果有，要提出解决办法，和避免措施。 最后要检查MySQL的版本，表的存储引擎，表是否有主键。是否有大字段，表的容量，是否有大表。包括后期的DDL执行，还有锁和隔离级别的选择。这些都是一个长期修改的过程，一定要配合开发同学，尽量的去说服他们。（表示遇见过直接去修改没有任何通知的，这种事你改出故障，那么活该你背锅）。 以上是针对新人入职或者内部转岗，新来一家单位要做的一些首要问题。那么在说说入职了一段时间后的工作内容。 首先要完善 备份 高可用 监控 巡检这些工作内容，要根据单位的实际情况做出合理划的选择。其次就是sql的变更，优化（包括SQL语句和参数等）。如果有必要就需要考虑审计。根据实际情况配合开发做新的业务数据库的表的设计的工作。 当有一定规模的时候就要考虑自动化。首先要考虑好标准化的设计，包括数据库的版本 数据库的data目录等信息，为后期的自动化做准备。尝试的写一些自动化的脚本或者工具。逐步的去尝试写自动化的平台。 最后，上述内容已经包含了升级 db的选型，监控 备份 高可用 巡检 主从 当然还有优化的内容，除此以为还有故障处理，日志分析等等，需要一定的知识储备，这些只是MySQL的内容 可能会接管其他类型的db 例如redis mongo等，还需要多留意每个版本的更新，更新了那些功能，修复那些bug。DBA要保证数据库的安全和稳定。愿各位工作顺利~
-
发表了文章 2017-11-17
如何优雅的添加MGR 节点
引言 MySQL Group Replication（简称MGR）是MySQL官方于2016年12月份推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用,高扩展、高可靠的MySQL集群服务。MGR是MySQL数据库未来发展的一个重要方向。 场景描述 操作系统 MySQL版本 CentOS Linux release 7.3.1611 MySQL5.7.20 二进制 ip地址规划 IP地址 hosts port 192.168.74.134 mgr-node1.up.com 330623306 192.168.74.135 mgr-node2.up.com 330623306 192.168.74.136 mgr-node3.up.com 330623306 一个已经运行很久的MGR集群，以single-master模式运行（单主模式），binlog过期策略为7天。 参数设置 Key Value enforce_gtid_consistency ON master_info_repository TABLE relay_log_info_repository TABLE binlog_checksum NONE log_slave_updates ON binlog_format ROW ==expire_logs_days== ==7== 需求描述因为不可抗力的因素 mgr-node3.up.com 节点永久性的down 并且无法恢复，或者mgr-node3.up.com 宕机超过时间7day， 或需要快速添加节点。那么改如何快速添加或扩容呢？ 猜想 1.如果这个问题发送在Percona XtraDB Cluster（pxc）或者Mariadb Galera Cluster解决方案是通过SST(全量)或者IST（增量）来实现，那么MGR是否SST或者IST的方案呢？ 2.假设MGR也是通过SST或者IST来的解决方案入 MGR是否使用MySQLdump 或者rsync来获得一份全量？ 3.假设是通过MySQLdump来实现传递增量。是否可以用xtrabackup来替换呢？ 根据上述的猜想和假设来求证，如何优雅的添加MGR节点。 验证 猜想一 在MySQL官方文档中没有找到关于SST或IST的描述,既然官方文档没有写那么在实验环境中是否能模拟出来。 -实验在mgr-node1.up.com主节点创建一张表 "root@localhost:mysql3306.sock [aa]>show create table aa; +-------+-------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+-------------------------------------------------------------------------------------------------------------------------------------------+ | aa | CREATE TABLE `aa` ( `id` int(11) NOT NULL, `name` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 | +-------+-------------------------------------------------------------------------------------------------------------------------------------------+ "root@localhost:mysql3306.sock [aa]>select * from aa; +----+------+ | id | name | +----+------+ | 1 | a | | 2 | a | | 3 | a | | 4 | a | | 5 | a | +----+------+ 5 rows in set (0.00 sec) 加入新的节点mgr-node4.up.com并初始化，开启现有环境所有节点的general_log观察general的输出 mgr-node1.up.com 节点 2017-11-16T15:38:52.818216Z 32 Connect slave@mgr-node4.up.com on using TCP/IP 2017-11-16T15:38:52.829195Z 32 Query SELECT UNIX_TIMESTAMP() 2017-11-16T15:38:52.829836Z 32 Query SELECT @@GLOBAL.SERVER_ID 2017-11-16T15:38:52.835000Z 32 Query SET @master_heartbeat_period= 30000001024 2017-11-16T15:38:52.842449Z 32 Query SET @master_binlog_checksum= @@global.binlog_checksum 2017-11-16T15:38:52.843032Z 32 Query SELECT @master_binlog_checksum 2017-11-16T15:38:52.843355Z 32 Query SELECT @@GLOBAL.GTID_MODE 2017-11-16T15:38:52.843529Z 32 Query SELECT @@GLOBAL.SERVER_UUID 2017-11-16T15:38:52.843726Z 32 Query SET @slave_uuid= '5d03ede3-cae1-11e7-9319-000c299354d5' 2017-11-16T15:38:52.844093Z 32 Binlog Dump GTID Log: '' Pos: 4 GTIDs: '' 2017-11-16T15:39:52.972984Z 33 Connect slave@mgr-node4.up.com on using TCP/IP 从general_log中找到了蛛丝马迹,目前版本的MGR，不支持SST或IST。实现的方式是根据GTID的方式来实现的。 同时在general_log中也发现，目前版本的MGR也不支持MySQLdump或者rsync方式来给新加入的节点传递全量。如果binlog被清空的话 则显示为空 新的节点无法加入集群但 "root@localhost:mysql3306.sock [aa]>start group_replication;提示成功 正确姿势 1.首先需要手动在MGR集群中获得一致性备份。 2.初始化新节点，并应用备份。注意如下操作 否则无法正常添加到集群 "root@localhost:mysql3306.sock [aa]>reset master; Query OK, 0 rows affected (0.00 sec) "root@localhost:mysql3306.sock [aa]>SET @@GLOBAL.GTID_PURGED='3db33b36-0e51-409f-a61d-c99756e90155:1-14, '> ecf5373e-cad7-11e7-b854-000c293dbc8e:1' -> ; Query OK, 0 rows affected (0.00 sec) 3.安装官方文档正常初始化集群 步骤略 4.验证 "root@localhost:mysql3306.sock [aa]>start group_replication; Query OK, 0 rows affected (3.16 sec) "root@localhost:mysql3306.sock [aa]>select * from aa; +----+------+ | id | name | +----+------+ | 1 | a | | 2 | a | | 3 | a | | 4 | a | +----+------+ 总结 1.如果需要添加一个节点 添加节点 需要自己手动在MGR集群中获得一致性备份，MGR集群不存在SST和IST概念,而是完全通过GTID和binlog来实现“追数据”的一个操作 2.节点宕机 如果MGR集群中某个节点宕机,如果宕机节点会询问存活集群，是否能补全binlog 如果能补齐，那么就会正常传输，进行追数据 。如果宕机节点需要的日志不存在了，则该节点无法正常加入集群环境中。 对于MGR一个建议 在宕机节点加入MGR集群中，如果发现需要的binlog日志不存在，则无法启动集群start group_replication
-
发表了文章 2017-10-28
基于consul高可用
1.介绍consul Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对.命令行超级好用的虚拟机管理软件 vgrant 也是 HashiCorp 公司开发的产品.一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制. 2.consul优势 2.1 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接2.2 支持多数据中心2.3 支持健康检查2.4 支持http和dns协议封口2.5 官方提供web管理界面2.6 部署简单，运维友好相比同类的服务发现与配置的主流的产品，我个人更看好的功能是DNS API，并且提供简单的web管理界面。 3.consul的使用场景 3.1 docker 实例的注册与配置共享3.2 coreos 实例的注册与配置共享3.3 redis &MySQL 高可用的实现3.4 与 confd 服务集成，动态生成 nginx 和 haproxy 配置文件 4. 基于consul redis高可用 首先部署一个3节点的consul server 集群，用于提供主要服务。其次redis主从服务部署，consul client 并且注册服务，并提供读域名和写域名。最后 APP应用服务的DNS解析指向consul server 节点，通过consul dns解析 获得后端的redis master和slave的ip地址。当故障发生，redis的主从切换时。consul会自动做DNS和域名的对应关系。 5.基于consul MySQL高可用 基本于redis的高可用类似，需要MHA高可用做配合，proxysql做读写分离。不过不再需要MHA的vip，只需要使用MHA的补binlog日志功能。 https://www.percona.com/blog/2016/09/16/consul-proxysql-mysql-ha/ #可以参考下percona博客分享 6.关于consul dns缓存问题 consul dns缓存可以设置为 有缓存状态和无缓存状态。默认TTL值是0。可调整有缓存的参数是 dns_config.node_ttl。建议使用默认的无缓存状态。 7.结束语 关于 consul 1.0 如何具体实现server搭建和实现redis的高可用 参考我的好基友言伟同学的博客。目前网上流传的都是consul 老的版本，感谢言伟同学的分享。也请关注知数堂分享的新姿势。 http://412166174.blog.51cto.com/3102369/1975822 http://412166174.blog.51cto.com/3102369/1976520
-
发表了文章 2017-10-13
叮咚~您的MySQL云备份已上线
前戏一 开篇简述 作为一名合格的MySQL DBA，备份是重中之重。为了保证备份集的安全可靠，除了集中存储以外还有其他更好的方案嘛？当然是有的，可以存储在OSS上或者分布式存储上。那么问题来了如何能够实现自动备份，并且上次到OSS上，不需要人工干预，节约大量的时间去悠哉悠哉的喝喝茶、看看报呢。 前戏二 常见的MySQL备份方式 2.1 逻辑备份 常见的逻辑备份 MySQLdump 和MySQLpump 2.2 物理备份 常见的物理备份 xtrabackup 2.3 冷备份 关闭MySQL 拷贝文件 启动MySQL#本文重点和程序都使用xtrabackup备份，其他备份姿势请报名“知数堂” ，吴老司机带你飞。 前戏三 xtrabackup原理简述 首先会启动一个 xtrabackup_log后台检测的进程 实时检测mysql redo的变化 一旦发现redo有新的日志写入 立刻将日志写入到xtrabackup_log中 复制innodb的数据文件和系统表空间文件 idbata1到对应的默以默认时间戳为备份目录的地方 复制结束后 执行 flush table with read lock操作 复制 .frm .myd .myi文件 并且在第一时刻获得binary log 位置 将表进行解锁 unlock tables 停止xtrabackup_log进程 #附上一张原理图 来自阿里数据库内核月报 基本操作 1.全量备份 innobackupex --defaults-file=/etc/my.cnf --user=root --password=redhat /data/backup --defaults-file 配置文件 --user 表示用户名 --password 表示密码 /data/backup 备份路径 2. 应用redo innobackupex --apply-log 2017-02-17_11-50-43 3.恢复 1，需要恢复地方的MySQL需要关闭 2.目前datadir 为空 3.手工把刚applu的文件cop过去或者 innobackupex --copy-back /data/backup/2017-02-17_11-36-47/ 4.更改copy过去的权限 chow -R mysql:mysql /data/backup/2017-02-17_11-36-47/ 5.启动mysql 正文 自动备份 并上次oss上 https://github.com/enmotplinux/mysql_backup 主要实现目标 能够实现 基于xtrabackup 的MySQL自动化备份 并且上传到OSS上（ceph暂时不支持 ，需要那位好心的小伙伴提供一个ceph的测试环境，后续就可以支持。）目录lib下 innodb_backup.py 主要实现 xtrabackup备份和自动apply-log 根目录的index.py 主要实现 调用lib下面的innodb_backup下面的函数 并且自动上次到oss上，需要配置oss的认证信息。根目录test.py 主要实现 下载最新的备份，并且配置启动。目的主要是为了实现自动校验。关于备份校对 我推荐使用“心跳表”的方式来校队备份。#关于“心跳表”请来知数堂学习一下MySQL复制监控或者私信田帅萌~ 结尾 注意事项 1 需要单独的物理网络做备份网络，避免在执行备份传输的时候造成网络阻塞，从而影响业务2很多个备份同时执行的时候，需要考虑一个队列问题。避免同时上传，导致网络阻塞。后果本地备份成功，上次oss或者ceph失败。需要设计一个合理的队列并限速。先上传核心的库。每次同时上传4个，等待上传成功后在进行下一个队列的传输。3 本地备份留2天，oss上或者ceph根据空间大小和库的大小自行决定设计 欢迎各位有想法的或者想要实现更好的备份姿势，请联系我 一起交流~
-
发表了文章 2017-09-22
【巡检】MySQL巡检到底巡检什么
MySQL巡检 一 。操作系统巡检 如果有zabbix或者其他监控类型的工具，就方便了很多。首先看 CPU 内存 硬盘io的消耗程度。其中重点是硬盘使用率，要为十一小长假做好准备啊，避免十一期间业务写入增长，磁盘占满。每家业务不一样，所以参考标准不一样。 如果没有zabbix 建议使用 ```sar```这个小工具，能够收集历史的信息。它的历史数据在```/var/log/sa```下面，通过 -f 来指定文件。举例 1.1 cpu资源监控 [root@mongodb01 data]# sar -u 10 3 Linux 2.6.32-642.el6.x86_64 (mongodb01) 09/22/2017 _x86_64_ (8 CPU) 10:26:44 AM CPU %user %nice %system %iowait %steal %idle 10:26:54 AM all 0.55 0.00 0.41 5.61 0.03 93.40 1.2 内存和交换空间监控 [root@mongodb01 data]# sar -r 10 3 Linux 2.6.32-642.el6.x86_64 (mongodb01) 09/22/2017 _x86_64_ (8 CPU) 10:28:36 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit 10:28:46 AM 223084 32658252 99.32 143468 16549080 18774068 37.81 1.3I/O和传送速率监控 [root@mongodb01 data]# sar -b 10 3 Linux 2.6.32-642.el6.x86_64 (mongodb01) 09/22/2017 _x86_64_ (8 CPU) 10:30:25 AM tps rtps wtps bread/s bwrtn/s 10:30:35 AM 67.17 61.63 5.54 16169.99 86.20``` 1.4系统交换活动信息监控 [root@mongodb01 data]# sar -w 10 3Linux 2.6.32-642.el6.x86_64 (mongodb01) 09/22/2017 x86_64 10:31:56 AM proc/s cswch/s10:32:06 AM 0.00 2234.44` 当然还有其他的监控项目，就不一一赘述了，还需要查看当前的磁盘和内存使用情况df -h ，free -m，是否使用numa和swap 是否频繁交互 等信息。除此以外，还可以需要关注日志类信息 例如 [root@mongodb01 data]# ll /var/log/messages [root@mongodb01 data]# ll /var/log/dmesg MySQL error log MySQL 慢查询日志 等信息 二。MySQL本身巡检2.1重点参数 "innodb_buffer_pool_size" "sync_binlog" 'binlog_format' 'innodb_flush_log_at_trx_commit': 'read_only': 'log_slave_updates' 'innodb_io_capacity' 'query_cache_type' 'query_cache_size' 'max_connections' 'max_connect_errors' 'server_id' 2.2MySQL的状态 例如每秒的tps，qps，提交了多少事物，回滚了多少事物，打开文件数，打开表数，连接数，```innodb buffer```使用率，锁等待等等 查看mysql状态 show full processlist show global status show engine innodb status\G taill -f show.log show status中的一些状态信息 wait 等待 Innodb_buffer_pool_wait_free Innodb_log_waits 锁等待 Innodb_row_lock_current_waits 当前等待的待锁定的行数 Innodb_row_lock_waits 一行锁定必须等待的总时长 Table_locks_waited 表锁等待次数 mysql 锁监控 表级锁 Table_locks_waited Table_locks_immediate 行级锁 Innodb_row_lock_current_waits 当前等待锁的行锁数量 Innodb_row_lock_time 请求行锁总耗时 Innodb_row_lock_time_avg 请求行锁平均耗时 Innodb_row_lock_time_max 请求行锁最久耗时 Innodb_row_lock_waits 行锁发生次数 等待事件 Innodb_buffer_pool_wait_free /Innodb_log_waits 临时表/临时文件 Created_tmp_disk_tables/Created_tmp_files 打开表/文件数 Open_files/Open_table_definitions/Open_tables 并发连接数 Threads_running /Threads_created/Threads_cached Aborted_clients 客户端没有正确关闭连接导致客户端终止而中断的连接数 Aborted_connects 试图连接到mysql服务器而失败的连接数 Binlog Binlog_cache_disk_use 使用临时二进制日志缓冲但超过 binlog_cache_size 值并使用临时文件 Binlog_cache_use 使用临时二进制日志缓冲的事务数量 Binlog_stmt_cache_disk_use 当非事务语句使用二进制日志缓存 Binlog_stmt_cache_use 使用二进制日志缓冲非事务语句数量 链接数 Connections 试图连接到（不管成不成功）mysql服务器的链接数 临时表 Created_tmp_disk_tables 服务器执行语句时在硬盘上自动创建的临时表的数量。是指在排序时，内存不够 用(tmp_table_size 小于需要排序的结果集)，所以需要创建基于磁盘的临时表进 行排序 Created_tmp_files 服务器执行语句时自动创建的内存中的临时表的数量 索引 Handler_commit 内部交语句 Handler_rollback 内部 rollback语句数量 Handler_read_first 索引第一条记录被读的次数 如果高 它表明服务器正执行大量全索引扫描 Handler_read_key 根据索引读一行的请求数 如果较高 说明查询和表的索引正确 Handler_read_last 查询读索引最后一个索引键请求数 Handler_read_next 按照索引顺序读下一行的请求数 Handler_read_prev 按照索引顺序读前一行的请求数 Handler_read_rnd 根据固定位置读一行的请求数 如果值较高 说明可能使用了大量需要mysql扫整个表的查询或没有正确使用索引 Handler_read_rnd_next 在数据文件中读下一行的请求数 如果你正进行大量的表扫 该值会较高 innodb Innodb_buffer_pool_wait_free 一般情况 通过后台想 innodb buffer pool 写 Innodb_log_waits 日志缓冲区太小 我们在继续前必须先等待对它的清空 Innodb_row_lock_current_waits 当前等待锁的行锁数量 Innodb_row_lock_time 请求行锁总耗时 Innodb_row_lock_time_avg 请求行锁平均耗时 Innodb_row_lock_time_max 请求行锁最久耗时 Innodb_row_lock_waits 行锁发生次数 Open_table_definitions 被缓存的.frm文件数量 Opened_tables 已经打开的表的数量 如果较大 table_open_cache 值可能太小 Open_tables 当前打开的表的数量 Queries 已经发送给服务器的查询个数 Select_full_join 没有使用索引的联接的数量 如果该值不为0 你应该仔细检查表的所有 Select_scan 对第一个表进行完全扫的联接的数量 Slow_queries 查询时间超过long_query_time秒的查询个数 Sort_merge_passes 排序算法已经执行的合并的数量 如果值较大 增加sort_buffer_size大小 线程 Threads_cached 线程缓存内的线程数量 Threads_connected 当前打开的连接数量 Threads_created 创建用来处理连接的线程数 Threads_running 激活的（非睡眠状态）线程数 等我的不成熟的小程序有获取相关的值 有兴趣看看 2.3MySQL 是否有锁如果有监控的话可以获取监控信息，或者其他工具，如果没有请定期收集MySQL锁信息 INFORMATION_SCHEMA.INNODB_LOCKS; INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 参考一下《老司机带你体验SYS库多种新玩法》这篇文章2.4MySQ 自增id的使用情况 'SELECT table_schema,table_name,engine,Auto_increment FROM information_schema.tables whereINFORMATION_SCHEMA. TABLE_SCHEMA not in ("information_schema" ,"performance_schema","mysql")' 参考一下《老司机带你体验SYS库多种新玩法》这篇文章2.5 存储引擎是否为innodb INFORMATION_SCHEMA.TABLES engine=innodb 2.6MySQL 主从检测 ```show slave status``` 2.6.1 主从状态 主从状态是否双yes 2.6.2 主从是否延迟 Master_Log_File == Relay_Master_Log_File && Read_Master_Log_Pos == Exec_Master_Log_Pos 三 高可用巡检 3.1.MHA && keepalived 观察日志看是否有频繁主从切换，如果有分析一下是什么原因进行频繁切换 3.2中间件的巡检 mycat && pproxysql 这些中间价的巡检，首先参考系统巡检，在过看一下中间价本身的日志类，和状态类信息，网络延迟或丢包的检查，也是必须要做工作 总结 关于巡检来说，每个环境是不一样的，所以xunj的侧重点也是不一样的，但基本的巡检是避免不了的，如果有其他的巡检姿势也欢迎一起讨论。顺便 前几天花1天的功夫写了一个MySQL的巡检，只能巡检MySQL的状态和参数配置，（因为客户的环境不能直连linux但可以直连MySQL） https://github.com/enmotplinux/On-Site-Inspection
-
发表了文章 2017-09-14
【新特性】MySQL5.7新特性query_rewrite 插件
一。使用场景 在业务繁忙并且紧急上线，对就是那种特别繁忙，又不能停的那种。在系统不忙的时候 明明跑的很好。**但是**一旦业务繁忙，造成业务阻塞。当查看MySQL的满查询日志中发现大量慢查询日志，（不是单单加索引就能搞定的哦）。这时候怎么办，难道怒对开发一顿，这时候你需要MySQL5.7新特性query_rewrite _Plugin插件了。 二。安装配置插件2.1安装 [root@localhost share]# /usr/local/mysql/bin/mysql -u root -p < install_rewriter.sql Enter password: [root@localhost share]# pwd /usr/local/mysql/share 验证 "root@localhost:mysql.sock [(none)]>show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | query_rewrite | | sys | +--------------------+ 安装完成了 似不似很简单呢~QAQ~ 2.2配置一发 "root@localhost:mysql.sock [(none)]>use query_rewrite; Database changed "root@localhost:mysql.sock [query_rewrite]>show tables; +-------------------------+ | Tables_in_query_rewrite | +-------------------------+ | rewrite_rules | +-------------------------+ 查看rewrite_rules表，表结构大概是这样的 CREATE TABLE `rewrite_rules` ( `id` int(11) NOT NULL AUTO_INCREMENT, `pattern` varchar(10000) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, `pattern_database` varchar(20) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `replacement` varchar(10000) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, `enabled` enum('YES','NO') CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT 'YES', `message` varchar(1000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `pattern_digest` varchar(32) DEFAULT NULL, `normalized_pattern` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 id :规则id ，此列是表的主键。pattern：需要改写的源SQLpattern_database：需要改写的DB名称replacement：指定改写后的样子enabled：是否启用 2.3举个栗子 CREATE TABLE `aa` ( `id` int(11) DEFAULT NULL, `name` varchar(10) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 "root@localhost:mysql.sock [aa]>insert into aa values (1,'a'); "root@localhost:mysql.sock [aa]>insert into aa values (2,'a'); 在query_rewrite中修改规则 "root@localhost:mysql.sock [aa]>insert into query_rewrite.rewrite_rules(pattern, replacement, pattern_database) values ( -> "select * from aa ","select * from aa where id=1", "aa"); "root@localhost:mysql.sock [aa]>call query_rewrite.flush_rewrite_rules(); #加载一下 验证 root@localhost:mysql.sock [aa]>select * from aa; +------+------+ | id | name | +------+------+ | 1 | a | +------+------+ 是不是感觉很神奇呢，对于那种SQL隐式转换啦，强制走个索引啦 子查询的优化啦 等等等等 。尤其是系统繁忙来不及修改程序 来不及修改SQL的时候。真的能够救你的系统一命哦。如果你想让某个SQL变慢哦，让某个程序员背锅也是可以的哦。。 三.总结建议多关注一下MySQL的新特性。不知不觉就能使用到，有效提升和改善业务环境。
-
发表了文章 2017-09-10
【巡检】MySQL巡检
# MySQL巡检# 周末无聊 写了一个MySQL巡检程序 底层是用mongdo，刚开始写 不太成熟。有兴趣的话可以看看码云地址http://git.oschina.net/tplinuxenmo/On-Site-InspectionGitHubhttps://github.com/enmotplinux/On-Site-Inspection
-
发表了文章 2017-09-08
【bug】发现pt-table-checksum bug一例
发现pt-table-checksum bug例子 一.起因 由于全公司在组织学习MySQL。正在学到MySQL安装、 复制这一块，我的霸道总裁突然霸气十足的问我 ‘’你如何检测主从不一致呢‘’，我回答说 当然是``` pt-table-checksum` ,从而引出了下文.二.描述 MySQL5.7 主从环境 percona-toolkit-2.2.20-1.noarch 创建了一个test_xx的库 Query OK, 1 row affected (0.01 sec)``` 创建表 | aa | CREATE TABLE aa (id int(11) NOT NULL,name varchar(10) DEFAULT NULL, PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=latin1 | 插入数据 ```"root@localhost:mysql.sock [test_xx]>insert into aa values(1,'a'),(4,'a');``` 从库删除数据 "root@localhost:mysql.sock [test_xx]>delete from aa;Query OK, 2 rows affected (0.01 sec) 执行pt语句校队 [root@localhost ~]# pt-table-checksum --no-check-binlog-format --replicate=pt.cheksum --databases=test_xx -h 192.168.230.132 -u aa -predhat -P 3306 --recursion-method='processlist' 我的霸道总裁就喊我了 快来给我看看 。只能放下手里的砖先，开开心心的过去。 **三 排错** 开始以为是我的参数问题，各种调试。霸道总裁在旁边坐着好紧张QAQ 过了10分钟 还是没搞定。 霸道总裁突然说是不是**_**（下划线）问题呢。 去除**_**（下划线）重新创建库 插入表 插入数据 从库删除数据 还是不好使。。。 淡淡的忧伤 今天果然运气不好啊。 突然机智的总裁说 是不是 数据库的名字有长度限制呢。这就给了我一丝希望 就安装霸道总裁的意思 创建库名casdfdsfsf 创建表 插入数据 从库删除数据 结果好用了 好神奇 突然感觉世界都亮了。 我的霸道总裁告诉我 会不会是 因为test或者_的原因呢。经过各种 创建库 创建表 插入数据 从库删数据 等等操作。。 结果发现 机智的霸道总裁的结论的是对的 因为有test开头。 霸道总裁有没有好机智， 是不是快爱上霸道总裁了。 然后通过阅读```pt-table-checksum``` 的代码 发现 代码7617行 if ( $db =~ m/information_schema|performance_schema|lost+found|percona|percona_schema|test/ ) { 在percona-toolkit-3.0.3 已经修复了 if ( $db =~ m/^(information_schema|performance_schema|lost\+found|percona_schema)$/ ) { 在/usr/bin/pt-table-checksum 中修复 if ( $db =~ m/information_schema|performance_schema|lost+found|percona|percona_schema/ ) { [root@localhost ~]# pt-table-checksum --no-check-binlog-format --replicate=pt.cheksum --databases=test_xx -h 192.168.230.132 -u aa -predhat -P 3306 --recursion-method='processlist' TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE 09-08T10:48:15 0 1 2 1 0 0.044 test_xx.aa **四总结**
-
发表了文章 2017-09-01
【MySQL基础】MySQL安装第三弹-mariadb-10.2.8
MySQL安装第二弹-Percona5.7安装 一.操作系统选择 Centos/RHEL/ORACLE LIUNX 5.X/6.X/7.X x86_64 发行版 二.操作系统参数调整 2.1 selinux设置 [root@localhost ~]# cat /etc/selinux/config SELINUX=disabled #关闭selinux 2.2调整最大文件数限制 [root@localhost ~]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 7861 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 7861 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited #open files 最大打开文件数限制 #max user processes 每个用户最大processes数量 vim /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535 * soft nproc 65535 * hard nproc 65535 [root@localhost ~]# ulimit -a open files (-n) 65535 max user processes (-u) 65535 #每个操作系统修改方式可能不一样，参考一个操作系统的官方文档或google一下 2.3 io调度器修改 io调度器修改为deadline echo “deadline” > /sys/block/sdb/queue/scheduler 这里的sdb 修改为实际的设备名称 例如 sda 或者sdc。 /data所在的设备名称 B) 需要加入到 /etc/rc.local 中开启自动加载 2.4系统内核参数修改 vm.swappiness =5 #控制linux物理RAM内存进行SWAP页交换的相对权重 vm.dirty_ratio =5 #脏页占整个内存的比例，开始刷新 vm.dirty_background_ratio = 10 #脏页占程序的百分比 ,开始刷新 2.5关闭NUMA特性 新一代架构的NUMA不适用于跑数据库的场景。它本意是为了提高内存利用率，但实际效果不好，反而可能导致一个CPU的内存尚有剩余，但另一个不够用，发生SWAP的问题，因此建议直接关闭或者修改NUMA的调度机制。 a) 修改/etc/grub.conf，关闭NUMA，重启后生效 修改/etc/grub.conf 配置文件，在kernel 那行增加一个配置后重启生效，例如： kernel /vmlinuz-2.6.18-308.el5 ro root=LABEL=/1elevator=deadlinenuma=off rhgb quiet b) 修改/etc/init.d/mysql 或者mysqld_safe 脚本，设定启动mysqld进程时的NUMA调度机制，例如： numactl --interleave=all /usr/local/mysql/bin/mysqld_safe ....... c) BIOS硬件中关闭 #注 a b c 方法中任选其一。 2.6关闭CPU的节能模式 CPU启用节能模式后，会节约电量，但也可能带来CPU性能下降的问题。因此，运行数据库类业务时，建议关闭节能模式，发挥CPU的最大性能。 A）BIOS硬件中关闭 # 如果不是非核心业务 并且不繁忙的情况下 可以不用调整 三 MySQL环境 3.1 环境规范定义 MySQL安装包下载地址：https://downloads.mariadb.org/ #选择MariaDB 10.2 Series 版本 最新的分支版本 已经GA的 目录定义 #/usr/local/mysql #MySQL程序目录 #/data/mysql{端口号}/data 数据目录 #/data/mysql{端口号}/log binlog目录 3.2安装MariaDB a) 创建MySQL用户 useradd mysql -s /sbin/nologin b) 上传MySQL二进制包并解压 tar -zxvf mariadb-10.2.8-linux-glibc_214-x86_64.tar.gz c) 创建软链接 [root@localhost local]# ln -s mariadb-10.2.8-linux-glibc_214-x86_64 mysql d）根据目录定义创建目录 e）修改权限 [root@localhost local]# chown mysql:mysql /data/ [root@localhost local]# chown mysql:mysql /data/* -R [root@localhost local]# chown mysql:mysql /usr/local/mysql [root@localhost local]# chown mysql:mysql /usr/local/mysql/* -R f)安装需的软件包 yum groupinstall Development Tools g) 修改MySQL配置文件 [client] port = 3306 socket = /tmp/mysql.sock [mysql] prompt="\\u@\\h:\\p [\\d]> #pager="less -i -n -S" ##tee=/home/mysql/query.log no-auto-rehash [mysqld] #misc user = mysql basedir = /usr/local/mysql datadir = /data/mysql3306/data port = 3306 socket = /tmp/mysql.sock event_scheduler = 0 binlog_format = row server-id = 63306 log-bin = /data/mysql3306/log/mysql-bin#一个最基础的配置文件 ，后续会针对做讲解和配置优化 k）初始化MySQL cd /usr/local/mysql/scripts [root@localhost scripts]# ./mysql_install_db --basedir=/usr/local/mysql --user=mysql h）启动MySQL /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf & [root@localhost data]# /usr/local/mysql/bin/mysql -u root -p #登录 i）安全设置 "root@localhost:mysql.sock [(none)]>drop database test; "root@localhost:mysql.sock [mysql]> delete from user where not(host='localhost' and user='root'); "root@localhost:mysql.sock [mysql]>update mysql.user set password=password("redhat") where user='root'; "root@localhost:mysql.sock [mysql]>truncate table mysql.db; "root@localhost:mysql.sock [mysql]>FLUSH PRIVILEGES; 安装完成
-
发表了文章 2017-09-01
【MySQL基础】MySQL安装第二弹-Percona5.7安装
MySQL安装第二弹-Percona5.7安装 一.操作系统选择 Centos/RHEL/ORACLE LIUNX 5.X/6.X/7.X x86_64 发行版 二.操作系统参数调整 2.1 selinux设置 [root@localhost ~]# cat /etc/selinux/config SELINUX=disabled #关闭selinux 2.2调整最大文件数限制 [root@localhost ~]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 7861 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 7861 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited #open files 最大打开文件数限制 #max user processes 每个用户最大processes数量 vim /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535 * soft nproc 65535 * hard nproc 65535 [root@localhost ~]# ulimit -a open files (-n) 65535 max user processes (-u) 65535 #每个操作系统修改方式可能不一样，参考一个操作系统的官方文档或google一下 2.3 io调度器修改 io调度器修改为deadline echo “deadline” > /sys/block/sdb/queue/scheduler 这里的sdb 修改为实际的设备名称 例如 sda 或者sdc。 /data所在的设备名称 B) 需要加入到 /etc/rc.local 中开启自动加载 2.4系统内核参数修改 vm.swappiness =5 #控制linux物理RAM内存进行SWAP页交换的相对权重 vm.dirty_ratio =5 #脏页占整个内存的比例，开始刷新 vm.dirty_background_ratio = 10 #脏页占程序的百分比 ,开始刷新 2.5关闭NUMA特性 新一代架构的NUMA不适用于跑数据库的场景。它本意是为了提高内存利用率，但实际效果不好，反而可能导致一个CPU的内存尚有剩余，但另一个不够用，发生SWAP的问题，因此建议直接关闭或者修改NUMA的调度机制。 a) 修改/etc/grub.conf，关闭NUMA，重启后生效 修改/etc/grub.conf 配置文件，在kernel 那行增加一个配置后重启生效，例如： kernel /vmlinuz-2.6.18-308.el5 ro root=LABEL=/1elevator=deadlinenuma=off rhgb quiet b) 修改/etc/init.d/mysql 或者mysqld_safe 脚本，设定启动mysqld进程时的NUMA调度机制，例如： numactl --interleave=all /usr/local/mysql/bin/mysqld_safe ....... c) BIOS硬件中关闭 #注 a b c 方法中任选其一。 2.6关闭CPU的节能模式 CPU启用节能模式后，会节约电量，但也可能带来CPU性能下降的问题。因此，运行数据库类业务时，建议关闭节能模式，发挥CPU的最大性能。 A）BIOS硬件中关闭 # 如果不是非核心业务 并且不繁忙的情况下 可以不用调整 三 MySQL环境 3.1 环境规范定义 MySQL安装包下载地址：https://www.percona.com/downloads/Percona-Server-LATEST/ #选择Percona5.7版本 最新的分支版本 已经GA的 目录定义 #/usr/local/mysql #MySQL程序目录 #/data/mysql{端口号}/data 数据目录 #/data/mysql{端口号}/log binlog目录 3.2安装Percona a) 创建MySQL用户 useradd mysql -s /sbin/nologin b) 上传MySQL二进制包并解压 tar -zxvf Percona-Server-5.7.19-17-Linux.x86_64.ssl101.tar.gz c) 创建软链接 [root@localhost local]# ln -s Percona-Server-5.7.19-17-Linux.x86_64.ssl101 mysql d）根据目录定义创建目录 e）修改权限 [root@localhost local]# chown mysql:mysql /data/ [root@localhost local]# chown mysql:mysql /data/* -R [root@localhost local]# chown mysql:mysql /usr/local/mysql [root@localhost local]# chown mysql:mysql /usr/local/mysql/* -R f)安装需的软件包 yum groupinstall Development Tools g) 修改MySQL配置文件 [client] port = 3306 socket = /tmp/mysql.sock [mysql] prompt="\\u@\\h:\\p [\\d]> #pager="less -i -n -S" ##tee=/home/mysql/query.log no-auto-rehash [mysqld] #misc user = mysql basedir = /usr/local/mysql datadir = /data/mysql3306/data port = 3306 socket = /tmp/mysql.sock event_scheduler = 0 binlog_format = row server-id = 63306 log-bin = /data/mysql3306/log/mysql-bin#一个最基础的配置文件 ，后续会针对做讲解和配置优化 k）初始化MySQL /usr/local/mysql/bin/mysqld --initialize --user=mysql --basedir=/usr/local/mysql h）启动MySQL [root@localhost local]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf & i）密码 2017-08-31T10:00:15.372625Z 1 [Note] A temporary password is generated for root@localhost: Nw!,dJKwa3)3 #初始化成功后屏幕会输出密码，或者errorlog中也会打印 登录后 "root@localhost:mysql.sock [(none)]>set password='new_password'; j）使用jemalloc 内存分配方式 ln -s /usr/local/mysql/lib/mysql/libjemalloc.so.1 /usr/lib64/libjemalloc.so.1 [mysqld_safe] malloc-lib=/usr/lib64/libjemalloc.so.1 安装完成
-
发表了文章 2017-09-01
【MySQL基础】MySQL安装第一弹-MySQL5.7安装
MySQL安装第一弹-MySQL5.7安装 一.操作系统选择 Centos/RHEL/ORACLE LIUNX 5.X/6.X/7.X x86_64 发行版 如果是其他操作系统 则参考官方文档 https://www.mysql.com/support/supportedplatforms/database.html MySQL支持的平台 二.操作系统参数调整 2.1 selinux设置 [root@localhost ~]# cat /etc/selinux/config SELINUX=disabled #关闭selinux 2.2调整最大文件数限制 [root@localhost ~]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 7861 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 7861 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited #open files 最大打开文件数限制 #max user processes 每个用户最大processes数量 vim /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535 * soft nproc 65535 * hard nproc 65535 [root@localhost ~]# ulimit -a open files (-n) 65535 max user processes (-u) 65535 #每个操作系统修改方式可能不一样，参考一个操作系统的官方文档或google一下 2.3 io调度器修改 io调度器修改为deadline echo “deadline” > /sys/block/sdb/queue/scheduler 这里的sdb 修改为实际的设备名称 例如 sda 或者sdc。 /data所在的设备名称 B) 需要加入到 /etc/rc.local 中开启自动加载 2.4系统内核参数修改 vm.swappiness =5 #控制linux物理RAM内存进行SWAP页交换的相对权重 vm.dirty_ratio =5 #脏页占整个内存的比例，开始刷新 vm.dirty_background_ratio = 10 #脏页占程序的百分比 ,开始刷新 2.5关闭NUMA特性 新一代架构的NUMA不适用于跑数据库的场景。它本意是为了提高内存利用率，但实际效果不好，反而可能导致一个CPU的内存尚有剩余，但另一个不够用，发生SWAP的问题，因此建议直接关闭或者修改NUMA的调度机制。 a) 修改/etc/grub.conf，关闭NUMA，重启后生效 修改/etc/grub.conf 配置文件，在kernel 那行增加一个配置后重启生效，例如： kernel /vmlinuz-2.6.18-308.el5 ro root=LABEL=/1elevator=deadlinenuma=off rhgb quiet b) 修改/etc/init.d/mysql 或者mysqld_safe 脚本，设定启动mysqld进程时的NUMA调度机制，例如： numactl --interleave=all /usr/local/mysql/bin/mysqld_safe ....... c) BIOS硬件中关闭 #注 a b c 方法中任选其一。 2.6关闭CPU的节能模式 CPU启用节能模式后，会节约电量，但也可能带来CPU性能下降的问题。因此，运行数据库类业务时，建议关闭节能模式，发挥CPU的最大性能。 Aï¼BIOS硬件中关闭 # 如果不是非核心业务 并且不繁忙的情况下 可以不用调整 三 MySQL环境 3.1 环境规范定义 MySQL安装包下载地址：https://dev.mysql.com/downloads/mysql/ #选择MySQL5.7版本 最新的分支版本 已经GA的 目录定义 #/usr/local/mysql #MySQL程序目录 #/data/mysql{端口号}/data 数据目录 #/data/mysql{端口号}/log binlog目录 3.2安装MySQL a)创建MySQL用户 useradd mysql -s /sbin/nologin b) 上传MySQL二进制包并解压 [root@localhost local]# tar -zxvf mysql-5.7.19-linux-glibc2.12-x86_64.tar.gz c) 创建软链接 [root@localhost local]# ln -s mysql-5.7.19-linux-glibc2.12-x86_64 mysql d）根据目录定义创建目录 e）修改权限 [root@localhost local]# chown mysql:mysql /data/ [root@localhost local]# chown mysql:mysql /data/* -R [root@localhost local]# chown mysql:mysql /usr/local/mysql [root@localhost local]# chown mysql:mysql /usr/local/mysql/* -R f)安装需的软件包 yum groupinstall Development Tools g) 修改MySQL配置文件 [client] port = 3306 socket = /tmp/mysql.sock [mysql] prompt="\\u@\\h:\\p [\\d]> #pager="less -i -n -S" ##tee=/home/mysql/query.log no-auto-rehash [mysqld] #misc user = mysql basedir = /usr/local/mysql datadir = /data/mysql3306/data port = 3306 socket = /tmp/mysql.sock event_scheduler = 0 binlog_format = row server-id = 63306 log-bin = /data/mysql3306/log/mysql-bin#一个最基础的配置文件 ，后续会针对做讲解和配置优化 k）初始化MySQL /usr/local/mysql/bin/mysqld --initialize --user=mysql --basedir=/usr/local/mysql h）启动MySQL /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf & i）密码 2017-08-31T10:00:15.372625Z 1 [Note] A temporary password is generated for root@localhost: Nw!,dJKwa3)3 #初始化成功后屏幕会输出密码，或者errorlog中也会打印 登录后
-
发表了文章 2017-09-01
【开篇】自我介绍和博客未来规划
开篇介绍和博客未来规划 一.自我介绍 大家好 我叫田帅萌，英文名字叫tplinux。我服务于云和恩墨，主要工作是负责MySQL相关内容的交付工作。我个人主要对MySQL、redis、mongodb 有兴趣，也希望大家和我交流互动，我的邮箱是tplinux@163.com。 二.博客未来规划 我个人本来不是很喜欢写博客，所以这是我第一篇博客。我的本意是打算 写一写MySQL、redis、mongodb一些基础、原理，深入浅出，在写一些工作中的日常故障等内容。还有一些朋友感兴趣、咨询过我的问题，都会整理一下，做为博客内容发布出来。 三.结束 关于这次能获得“SQL优化大师”称号。真的要感谢 知数堂“叶金荣”老师和云和恩墨“刘伟”老师。也希望大家多多关注我的博客，把想知道的或者想要了解的内容，留言或者邮件给我。我会抽时间来去整理和写出来。
2021年12月
-
12.15 16:41:58
发表了文章
2021-12-15 16:41:58
初探TiDB-TiFlash
初探TiDB-TiFlash
-
12.15 16:30:30发表了文章
2021-12-15 16:30:30
TiDB用什么保证备份的一致性？
TiDB用什么保证备份的一致性？
-
12.15 16:27:02发表了文章
2021-12-15 16:27:02
浅析 TiDB 二阶段提交
浅析 TiDB 二阶段提交
-
12.15 16:25:38发表了文章
2021-12-15 16:25:38
tidb开发规范
tidb开发规范
-
发表了文章
2021-12-15
初探TiDB-TiFlash
-
发表了文章
2021-12-15
TiDB用什么保证备份的一致性？
-
发表了文章
2021-12-15
浅析 TiDB 二阶段提交
-
发表了文章
2021-12-15
tidb开发规范
-
发表了文章
2019-03-21
tidb VS MySQL 性能篇
-
发表了文章
2019-01-27
终于等到你，Percona MySQL8.0 GA版本发布
-
发表了文章
2019-01-27
MySQL很慢... 怎么破？？
-
发表了文章
2019-01-27
论如何安心过大年-MySQL巡检篇
-
发表了文章
2018-12-09
《叶问》第10期
-
发表了文章
2018-12-09
《叶问》第9期
-
发表了文章
2018-11-29
赞，Percona一天内放出二个版本
-
发表了文章
2018-11-29
Xtrabackup 8.0.1对MySQL8.0の初体験
-
发表了文章
2018-11-29
怎么让MySQL自动化平台再快10倍？
-
发表了文章
2018-11-29
关于MySQL 8.0的几个重点，都在这里
-
发表了文章
2018-11-29
《叶问》第8期
-
发表了文章
2018-11-29
《叶问》第7期
-
发表了文章
2018-11-29
《叶问》第6期
-
发表了文章
2018-11-29
《叶问》第5期
-
发表了文章
2018-11-29
《叶问》第3期
-
发表了文章
2018-11-29
《叶问》第2期
滑动查看更多
暂无更多信息
暂无更多信息