mysql主从配置

MHA 官方网址 Manager : https://github.com/yoshinorim/mha4mysql-manager Node : https://github.com/yoshinorim/mha4mysql-node MHA 工作原理 主库宕机处理过程 1. 监控节点 (通过配置文件获取所有节点信息) 系统,网络,SSH连接性 主从状态,重点是主库 2. 选主 (1) 如果判断从库(position或者GTID),数据有差异,最接近于 Master 的 slave,成为备选主 (2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主. (3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主. 1. 默认情况下如果一个 slave 落后 master 100M的 relay logs 的话，即使有权重,也会失效. 2. 如果 check_repl_delay=0 的话,即使落后很多日志,也强制选择其为备选主 3. 数据补偿 (1) 当SSH能连接,从库对比主库 GTID 或者 position 号,立即将二进制日志保存至各个从节点并且应用( save_binary_logs ) (2) 当SSH不能连接, 对比从库之间的relaylog的差异( apply_diff_relay_logs ) 4.

GTID (Golobal Transaction ID) 是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。 GTID 复制和传统复制的区别：在启动主从复制时，不需要指定 binlog 文件名和 postion 号，直接 auto 即可。MySQL 会自动读取最后一个 relay，获取到上次已经复制的 GTID 号，从此号码开始向后复制即可。在 MHA 高可用环境下，在主库无法 SSH 时，从库进行数据补偿更加便捷。eg: change master to master_host='192.168.31.205' ,master_user='rep',master_password='Rep_123456',master_auto_position=1; 在 /etc/my.cnf 上额外增加下面配置参数 [mysqld] gtid-mode=on # 启用gtid类型，否则就是普通的复制架构 enforce-gtid-consistency=true # 强制GTID的一致性 log-slave-updates=1 # slave更新是否记入日志 在主库创建了一个数据库，查看到 gtid 号 登录从库，查看现在执行到的 gtid 号 show binlog events in 'mysql-bin.000001'; 总结 在主从复制环境中，主库发生过的事务

各位老铁们，你们有没有想老张，最近老张的才华被工作的繁忙所限制了，所以一直没时间更博，今儿个时隔数日我们终于再次见面啦（很开心）！最近有部特别火的宫廷戏，不知道大家有没有看，剧名叫做《延禧攻略》，讲述得是一个宫女，一路过关斩将，最后成为皇上最宠爱的令贵妃的故事。加上我本人巨爱这类题材，所以痴迷得不得了。（好像暴露了自己没有更博的真正原因哈哈）。宫廷类的剧，都是后宫嫔妃之间的尔虞吾诈，勾心斗角，有你没我，有我没你的残酷事实。胜者为王，败者为寇这种思想好像从古代就一直延续到今日。非要分出个胜负，分出个谁好，谁坏才罢休。 在数据库领域也会有此类问题，老张我混迹开源数据库圈多年。MySQL数据库占领着开源数据库的头把交椅，MongoDB占领着NoSQL数据库的第一位。我们来看下数据库的整体排名情况； 两者都是第一，所有总会拿来比较。也会经常被人问及到诸如此类的问题MongoDB4.0已经问世了，而且支持事务了，是不是将来可以取代MySQL了。MySQL和MongoDB哪个数据库好用啊。今天老张想通过这篇文章，带着大家全方位解读MySQL与MongoDB的区别。让有困惑的老铁们明白，没有谁替代谁，只有哪个场景更适合谁。 我们从下面四个方向依次阐明两者的区别。只有更了解彼此，让能更好地利用它们的功能性。 第一部分：数据库概述 我们先来了解一下MySQL这个数据库；

一、MySQL复制流程 官方文档流程图如下： 1、绝对的延时，相对的同步 2、纯写操作，线上标准配置下，从库压力大于主库，最起码从库有relaylog的写入。 二、MySQL延迟问题分析 1、主库DML请求频繁 原因：主库并发写入数据，而从库为单线程应用日志，很容易造成relaylog堆积，产生延迟。 解决思路：做sharding，打散写请求。考虑升级到MySQL 5.7+，开启基于逻辑时钟的并行复制。 2、主库执行大事务 原因：类似主库花费很长时间更新了一张大表，在主从库配置相近的情况下，从库也需要花几乎同样的时间更新这张大表，此时从库延迟开始堆积，后续的events无法更新。 解决思路：拆分大事务，及时提交。 3、主库对大表执行DDL语句 原因：DDL未开始执行，被阻塞，检查到位点不变；DDL正在执行，单线程应用导致延迟增加，位点不变。 解决思路：找到被阻塞DDL或是写操作的查询，干掉该查询，让DDL正常在从库上执行；业务低峰期执行，尽量使用支持Online DDL的高版本MySQL。 4、主从实例配置不一致 原因：硬件上：主库实例服务器使用SSD，而从库实例服务器使用普通SAS盘、cpu主频不一致等；配置上：如RAID卡写策略不一致，OS内核参数设置不一致，MySQL落盘策略(innodb_flush_log_at_trx_commit和sync_binlog等)不一致等

参考文章： https://ieevee.com/tech/2018/05/16/k8s-rbd.html https://zhangchenchen.github.io/2017/11/17/kubernetes-integrate-with-ceph/ https://docs.openshift.com/container-platform/3.5/install_config/storage_examples/ceph_rbd_dynamic_example.html https://jimmysong.io/kubernetes-handbook/practice/using-ceph-for-persistent-storage.html 感谢以上作者提供的技术参考，这里我加以整理，分别实现了多主数据库集群和主从数据库结合Ceph RDB的实现方式。以下配置只为测试使用，不能做为生产配置。 K8S中存储的分类 在K8S的持久化存储中主要有以下几种分类： volume: 就是直接挂载在pod上的组件，k8s中所有的其他存储组件都是通过volume来跟pod直接联系的。volume有个type属性，type决定了挂载的存储是什么，常见的比如：emptyDir，hostPath，nfs，rbd，以及下文要说的persistentVolumeClaim等

本文主要是介绍在 centos 上搭建 mysql 的主从服务器。如果没有搭建过的，可以查看我以前的博客，里面有详细的安装 centos 和在 centos 上安装 mysql 的说明。 一.安装从虚拟机： 1. 右键— > 管理— > 克隆 2.选择完整克隆 3. 修改虚拟机的位置，默认在 C 盘下。 4.当克隆完成后，就有这样两台虚拟机了， 由于克隆的两台服务器， ip 是一样的，所以需要修改从服务虚拟机 ip ； 5.修改从服务虚拟机的配置，打开配置文件 vi /etc/sysconfig/network-scripts/ifcfg-ens33 　　如果不知道配置文件是哪个，可以按照下面的方式找到， 6. 找到下面红线部分，将 ip 地址修改，我这里将 150 改为 151： 7.修改完成后，重启 systemctl restart network 8. 使用 xShell 连接新配置的虚拟机 二.配置mysql主服务： 不管哪个项目， 80% 都是以读为主。所以一般要求从库的配置要高于主库。 对于主库的配置，主要是开启binlog日志。 1.进入 mysql 查看状态： show master status; 可以看到，执行的结果为空，所以需要开启 binlog 日志； 2. 找到 mysql 的配置文件： vi /etc/my.cnf 3. 在配置文件中添加 binlog

目录 背景 环境说明 安装并配置主库master 安装从库slave 主从库实现关联 背景 最近在学习用Spring Aop来实现数据库读写分离的功能。 在编写代码之前，首先是要部署好mysql的环境，因为要实现读写分离，所以至少需要部署两个mysql实例，一主一从，并且主从实例之间能够自动同步，因为我的本机内存并不高，所以就打算在windows上直接搭建mysql的主从实例(不想开虚拟机)，但这个过程中却遇到了一些麻烦，虽然最后都解决了，但也花费了不少的时间。为了避免以后在同样的事情上浪费时间，同时也方便读者们能复制相同的场景，所以就写下这篇博客来记录一下搭建环境的过程。 环境说明 本机地址：127.0.0.1(localhost) mysql版本：mysql-5.7.28-winx64 主库服务名：master，端口3307 从库服务名：slave，端口3308 安装并配置主库master 下载 首先是下载mysql，直接到 官网 下载zip版的安装包，这里建议下载比较新的版本，比如笔者的版本是5.7，这也是网上很多大神的建议， 解压并创建my.ini文件 解压安装包，命名文件夹为master，进入文件夹，创建一个名为my.ini的空文本， 文本中的内容如下： [client] # 端口号，默认是3306，同一个环境下不同的mysql实例端口号不能相同 port=3307

17.1 MySQL主从介绍 17.2 准备工作 17.3 配置主 17.4 配置从 17.5 测试主从同步 有的同学，遇到主从不能正常同步，提示uuid相同的错误。这是因为克隆机器导致。 https://www.2cto.com/database/201412/364479.html https://blog.csdn.net/sunbocong/article/details/81634296 报错 No query specified https://blog.csdn.net/tenfyguo/article/details/7566941 17.1 MySQL主从介绍： ~1. MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后，在A上写数据，另外一台B也会跟着写数据，两者数据实时同步的 比如对一个表插入了一行数据，那B机器上的这个表也会同样的插入一行数据 ~2. MySQL主从是基于binlog的，主上须开启binlog才能进行主从。 binlog是二进制的。比如主机器插入一行都会记录在binlog里，然后从机器，将主的binlog同步到从机器上，并记录在从机器自己的binlog里。我们把它叫做relaylog，中文叫中继日志，他会按照这个relaylog，严格按顺序执行 主从过程大致有3个步骤 1）主将更改操作记录到binlog里