这两天在做MySQL方向上的版本升级和高可用改造，在这个过程当中，还是遇到了不少的问题。从资源问题到级连的复制关系，虽然没有肉眼可见的困难环节，但是小细节还是挺多的，一不留神，可能会让你前功尽弃。
3月5号的文章中，对GTID做过一些基础的说明，这里就不在赘述了，今天这篇文章主要是对GTID部分的知识点的一个补充。
https://www.percona.com/software/mysql-tools/percona-toolkit
依托前文的解析来讲5.7中 GTID带来的运维改变，我想理解应该是更加深刻，这节主要讨论以下几个部分：
旧环境配置差一点(新环境的1/4的内存和CPU), 还是机械盘, 故想迁移到新环境
线上业务同学通常都会自己先搭建一套MySQL服务，自己维护，自己折腾，等到项目要上线，或者遇到某种性能瓶颈的时候，就会想到托管给DBA，这几天我们就遇到了这样一个场景。
迁移部分数据, 目标端还有数据, 基本上就确定使用mysqldump工具来做了
主从复制原理图
一般情况下，我们是通过"show slave status \G;"提供的Seconds_Behind_Master值来衡量mysql主从同步的延迟情况。具体说明见：mysql主从同步(4)-Slave延迟状态监控，这种方法在大多数情况下确实是可行的。但是经验告诉我，仅仅依靠Seconds_Behind_Master的值来监测主从同步数据是否延迟是绝对不可靠的！！！ 曾经遇到过的一个坑： Mysql主从环境部署后，刚开始主从数据同步是没问题的，也是通过监控Seconds_Behind_Master的值来判断
MySQL是现在互联网最常用的开源数据库产品。但是我们平常开发使用，大都是用的单机服务。而在实际生产中，往往数据量会极为庞大，并且数据的安全性要求也更高，这样单机的MySQL，不管是性能还是安全都是达不到要求的。所以在生产环境中，MySQL必须是要搭建一套主从复制的架构，同时可以基于一些工具实现高可用架构。然后，在此基础上，就可以基于一些中间件实现读写分离架构。最后如果数据量非常大，还必须可以实现分库分表的架构。
MySQL传统点位复制在5.7版本前是主要的主从复制模式，而随着MySQL5.6版本引入GTID，并且MySQL5.7进行各方面的优化以后，在mySQL5.7(尤其是MySQL5.7.6）版本后GTID模式的主从复制方式成为一个新的选择方式。要使用GTID模式，首先也需知其优缺点，其主要的优缺点如下：
脚本中记着修改vip地址以及用户密码，均为后续需要登录的数据库密码，方便切换主从。
凤凰网（纽交所上市公司，代码：FENG) 是全球领先的跨平台网络新媒体公司，整合旗下综合门户凤凰网、手机凤凰网和凤凰视频三大平台，秉承"中华情怀，全球视野，兼容开放，进步力量"的媒体理念， 为主流华人提供互联网、无线通信、电视网的三网融合无缝衔接的新媒体优质内容与服务。
环境 操作系统：CentOS-6.6-x86_64-bin-DVD1.iso MySQL版本：mysql-5.6.26.tar.gz 主节点IP：192.168.1.205 主机名：edu-mysql-01 从节点IP：192.168.1.206 主机名：edu-mysql-02 主机配置：4核CPU、4G内存 依赖课程 《高可用架构篇--第13节--MySQL源码编译安装（CentOS-6.6+MySQL-5.6）》 MySQL主从复制官方文档 http://dev.mysql.com/doc/refma
文章目录 什么是云原生 什么是Docker MySQL主从复制（1主1从） Master节点配置 Slave节点配置 测试主从同步 主从同步失败问题（Slave_SQL_Running:No） Slave_SQL_Running:No的解决办法 Redis集群（3主6从） 10亿条数据怎么进行缓存 哈希取余算法（小厂采用） 一致性hash算法（中大厂采用） hash槽算法（大厂采用、和Redis集群也是采用这种） 快速搭建Redis Cluster（3主6从） 快速生成9个容器实例 查看容器实例是否全部启
今天上午，做了一个比较有意思的操作，之前一直没有做过，就是把一套比较老的主从复制环境从基于偏移量的复制方式改为了基于GTID的复制方式，这里记录一下过程，如果大家有这方面的需求，可以参考一下：
MySQL 8.0.17的克隆插件允许在本地或从远程 MySQL 实例在线克隆数据，从此搭建从库可以不再需要备份工具（PXB或mysqldump）来实现了。克隆数据是存储在 InnoDB 其中的数据的物理快照，其中包括库、表、表空间和数据字典元数据。克隆的数据包含一个功能齐全的数据目录，允许使用克隆插件进行 MySQL 服务器配置。
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中， MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
今天在线上发现一个问题，由于监控没有覆盖到，某台机器的磁盘被写满了，导致线上MySQL主从复制出现问题。问题如下：
松哥原创的 Spring Boot 视频教程已经杀青，感兴趣的小伙伴戳这里-->Spring Boot+Vue+微人事视频教程
该问题来自某客户，据描述，他们在部署 MySQL 主从复制时，有时候仅在主库上创建复制用户，有时候主从实例上都会去分别创建复制用户，发现这两种方式都可以成功建立复制。针对这一现象，进行了一轮验证，来观察采用不同方式创建复制用户对主从复制的影响。
如果你还没有用docker搭建过mysql先不要急着搭建集群，可以显示着用docker搭建一个mysql，这里有教程，可以先试着去搭建一个mysql：
进入/mydata/mysql-master/conf目录下新建my.cnf(上面启动容器实例指定的路径)
Mysql主从同步，要求需要先搭建至少两个mysql实例，一主一从，使用推荐Docker搭建Mysql《Docker部署安装Mysql》
MySQL5.6加入了GTID的新特性，其全称是Global Transaction Identifier，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找到需要进行复制的点位，而无需像之前版本那样通过File_name和File_position来进行位置点的主从复制。
全局事务标识符（Global Transaction Identifier,GTID）是MySQL5.6版本开始在主从复制方面推出的重要特性，它是一个已提交事务的编号，并且是全局唯一编号，不仅是在主库上，在给定的复制设置中的所有数据库上，它都是唯一的。
主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。
今天中午，尝试着将线上rds的一套主从复制架构重新给搭建成一主两从的架构，在搭建的过程中，遇到了一些有意思的问题，记录一下：
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。
上文《MySQL数据被误删怎么办？》介绍了MySQL在故障或者误删数据后，可以通过备份+binlog的方式进行数据恢复。但是，当备份文件和binlog都丢失了呢？所以单节点是不可靠的，为了避免单节点故障带来的数据丢失以及MySQL服务的可用性，生产环境通常都是采用高可用或者集群模式。而在这背后则离不开主从复制技术，所以本文对主从复制的原理和操作展开介绍，从而全面了解这一技术。
1、在本地搭建两个linux虚拟机，其主服务器ip为192.168.0.1，从服务器ip为192.168.0.2。
docker run-p3339:3306--name mymysql-e MYSQL_ROOT_PASSWORD=123456-d mysql:5.7
现在OneDrive挂载目录程序越来越多了，之前水了很多了，包括PyOne、OneIndex、OLAINDEX和OneList，近期又出现了个CuteOne，一个基于Python3的OneDrive多网盘挂载程序，功能的话，看起来还是挺不错的，支持多盘负载、在线查看、在线上传、下载、多网盘同步、主从同步、在线分享、文件夹权限管理、会员功能、等级制度、付费查看、密码查看、支付模块、主题切换、极速缓存。至于体验的话，可能暂时会差点，毕竟才出来不到一个月的项目，不过看得出来作者也是有理想的人，所以会长期维护更新，让其越来越好，这里就大概介绍下如何用轻量应用服务器 Lighthouse搭建CuteOne。
在实际的生产中，为了解决Mysql的单点故障已经提高MySQL的整体服务性能，一般都会采用**「主从复制」**。
现今几乎每个大型技术峰会，都离不开互联网金融，企业数字化转型话题。国内外大型云计算独角兽企业，例如阿里云、Amazon、微软Azure等云计算供应商更是提供一站式服务，从底层硬件基础服务到顶层应用业务SaaS软件，帮助企业实现互联网架构的数字化转型。
美团点评技术沙龙由美团点评技术团队主办，每月一期。每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验，覆盖各主要技术领域。 目前沙龙会分别在北京、上海和厦门等地举行，要参加下一次最新沙龙活动？赶快关注微信公众号“美团点评技术团队”。 本次沙龙主要围绕数据库相关的主题，内容包括美团数据库自动化运维系统构建、点评侧MySQL自动化服务平台RDS、美团数据库中间件、和小米高级DBA带来的Redis Cluster的大规模运维实践。 讲师简介 宁龙，美团网高级DBA，现负责美团数据库自动化运维系统
搭建mysql主从的目的是让一台mysql作为主数据库，一台或多台mysql作为从数据库，主数据库只负责数据的写入，从数据库只负责数据的查询（读写分离），且主从数据库是实时同步的，这样就可以减轻单个数据库压力，从而提高项目的并发量。
业务不断地在增长，集群分片中的数据也会随着时间的推移而增加，其中有相当一部分的数据是很少被使用的，例如几年前的订单记录、交易记录、商品评论等数据。这部分数据就称之为冷数据，与之相反经常被使用的数据则称之为热数据。
在MySQL中，主从架构应该是最基础、最常用的一种架构了。后续的读写分离、多活高可用架构等大多都依赖于主从复制。主从复制也是我们学习MySQL过程中必不可少的一部分，关于主从复制的文章有很多，笔者也来凑凑热闹，写写这方面的内容吧，同时分享下自己的经验和方法。
修改mysql配置文件，不同的系统my.cnf路径不同（CentOS中位于/etc/my.cnf）
Hi,各位热爱技术的小伙伴您们好，好久没有写点东西了，今天写点关于mysql主从同步配置的操作日志同大家一起分享。最近自己在全新搭建一个mysql主从同步读写分离数据库简单集群，我讲实际操作步骤整理分享处理，希望对在学习路上的你有所以帮助，当然如果是你是老鸟，写的不好的地方，多多包涵。废话不多说，言归正传，直入主题。
在上篇文章中我们介绍了基于Docker的MySQL主从搭建，一主多从的搭建过程就是重复了一主一从的从库配置过程，需要注意的是，要保证主从库my.cnf中server-id的唯一性。搭建完成后，可以在主库show slave hosts查看有哪些从库节点。
MGR是MySQL官方开发的一个开源插件，和其他的异步复制和半同步复制不同，它是利用了MySQL的组复制技术来实现高可用的一种解决方案，保证了数据的强一致性。MySQL在5.7.17版本中正式引入。所谓的组是指多个MySQL服务器被Group Replication插件连接在一起，组内的成员通过组管理服务实现了自动化的管理功能。对于用户来讲，只需要将新的服务器加入到已有的组里面，或者从已有的组里面剔除故障服务器即可，组内的通信方式，用户可以无需关心。
MySQL发展至今，在高可用性方面不断前进，从最初的异步复制、半同步复制、群组复制，演进到现在的InnoDB Cluster和InnoDB Replica Set。在这一篇里将说明各种高可用架构以及其适用的场景。
上语文课，不小心睡着了，坐在边上的同桌突然叫醒了我，并小声说道：“读课文第三段”。我立马起身大声读了起来。正在黑板写字的老师吓了一跳，老师郁闷的看着我，问道：“同学有什么问题吗？”，我貌似知道了什么，蛋定的说了一句：“这段写的真好！我给大伙念念！”，老师还较真了：“你说说看，好在哪里？”，顿时我就无语了，脸黑着望向了同桌了，心想着：“这是个畜生啊！”
mysql主从复制： 一主一从 主主复制 一主多从---扩展系统读取的性能，因为读是在从库读取的； 多主一从---5.7开始支持 联级复制--- 用途及条件 mysql主从复制用途 实时灾备，用于故障
MySQL 主从搭建可以实现数据的实时备份和负载均衡。其中，主服务器负责写入操作，从服务器负责读取操作。以下是搭建 MySQL 主从架构的步骤：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
