mysql主从配置

主从从，也称为级联主从，数据流向：A(主)->B(从)->C(从从)，主从从级联复制。 应用场景 在主从配置的基础上，再增加一个从库，进一步提高数据安全，容灾备份。 读写分离，从库只用于查询，提高数据库整体性能。 从从库，用于备份，等同在线实时增量备份。 部署环境 ​ 注：使用docker部署mysql实例，方便快速搭建演示环境。但本文重点是讲解主从配置，因此简略描述docker环境构建mysql容器实例。 数据库：MySQL 5.7.x （相比5.5，5.6而言，5.7同步性能更好，支持多源复制，可实现多主一从，主从库版本应保证一致） 操作系统：CentOS 7.x 容器：Docker 17.09.0-ce 镜像：mysql:5.7 主库：IP=192.168.10.212; PORT=4200; server-id=200; database=test; table=user 从库：IP=192.168.10.212; PORT=4211; server-id=210; database=test; table=user 从从库：IP=192.168.10.212; PORT=4211; server-id=211; database=test; table=userk 配置约束 主从库必须保证网络畅通可访问 主库必须开启binlog日志 主从库的server-id必须不同

前言 自己在百度、Google一番踩坑搭建成功后，记录一下，也希望后来人不再被这些坑到。 这里为了方便使用 docker，不会的同学请移步相关 Docker 教程。 正文 1. 启动 mysql #启动 master docker run --name master -e MYSQL_ROOT_PASSWORD=123456 -d mysql #启动 slave docker run --name slave -e MYSQL_ROOT_PASSWORD=123456 -d mysql 备注：--name 是指定容器名称；-e MYSQL_ROOT_PASSWORD 是指定mysql密码 2. 修改 mysql 配置 docker 的正确用法应该是基于mysql镜像， 创建两个新的镜像 ，这里为了简单，直接进入容器修改 修改 master 的 mysql 配置 docker exec -it [master容器id] bash echo '[mysqld] pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock datadir = /var/lib/mysql secure-file-priv= NULL symbolic-links=0 #启用二进制日志 log-bin=mysql

这是我离线整理资料里的内容，大概是2012年时候开始使用此性能监控工具的，直到至今，接触到几个性能监控工具里，还是美国quest公司生产的Spotlight此产品相对比较牛！ 我也不知道现在发展到能支持监控多少资源，我就拿我之前整理的文档所对应的的工具版本进行讲解，至于下载软件支持某个资源或者某些资源，请自行百度搜索：quest Spotlight，官网下载的版本是需要收费的，因此自行在网上搜索下载破解版本。 Spotlight可以监控很多很资源，相关如下： Spotlight on web server //web应用程序服务 Spotlight on Active Directory //wwindows操作系统上的AD域应用程序服务 Spotlight on DB2 //DB2关系型数据库应用程序服务 Spotlight on MySQL //mysql关系型数据库应用程序服务 Spotlight on Oracle //oracle关系型数据库应用程序服务 Spotlight on SQL Serever // SQL Serever 关系型数据库应用程序服务 Spotlight on Sybase ASE // sybase OLTP关系型数据库应用程序服务 Spotlight on Unix/Linux //Unix/Linux操作系统 Spotlight on

有关于MySQL的高级部分笔记 这是一篇关于 MySQL 高级部分的笔记主要是，sql优化以及mysql锁的相关内容，以及主从配置等内容等比较基础的优化 一、逻辑架构部分 逻辑架构 逻辑架构介绍图如下 　　　　　　 连接层：最上层是一些客户端和连接服务，包含本地的sock通讯大多时基于客户端/服务端工具实现的类似于tcp/ip的通讯 服务层：完成大多数的核心服务的功能，如，SQL接口，并完成缓存的查询SQL的分析和优化以及部分内置函数的执行，所有款存储引擎的功能 引擎层：存储引擎真正的负责了MySQL中的数据的存储和提取，服务器通过api与存储引擎进行通讯，常用的有MyISAM和InnoDB 存储层：数据存储在裸设备上，并完成与存储引擎的交互 优化主要是只使SQL的解析格式符合优化器的优化格式 存储引擎 查看mysql的存储引擎命令 # 看你的mysql提供了生么存储引擎show engines;# 看当前默认的存储引擎show variables like '%storage_engine%'; MyISAM与InnoDB的对比如下表 对比项 MyISAM InnoDB 主外键 不支持 支持 事务 不支持 支持 行表锁 表锁，即使操作一条记录也会锁住整个表， 不适合高并发的操作 行锁，操作时只锁某一行，不对其他的行有影响， 适合高并发的操作 缓存 只缓存索引不缓存真实数据

@font-face { font-family: "Times New Roman"; }@font-face { font-family: "宋体"; }@font-face { font-family: "Calibri"; }@font-face { font-family: "微软雅黑"; }p.MsoNormal { margin: 0pt 0pt 0.0001pt; text-align: justify; font-family: Calibri; font-size: 10.5pt; }p.p { margin: 5pt 0pt; text-align: left; font-family: Calibri; font-size: 12pt; }span.msoIns { text-decoration: underline; color: blue; }span.msoDel { text-decoration: line-through; color: red; }div.Section0 { }div.Section1 { }div.Section2 { }div.Section3 { }div.Section4 { } 案例 1 ：配置逻辑卷 (192.168.4.11,192.168.4.22) 一 . 环境准备 : 1. 图形模式下手动添加磁盘 (2

部署环境： 系统环境CentOS release 6.5_x64 主mysql服务器ip：172.18.49.10 从mysql服务器ip：172.18.49.2 开始部署安装： Mysql服务器都已经搭建完成。 l 主mysql上 ： # cp /etc/my.cnf /etc/my.cnf.bak # vi /etc/my.cnf log_bin=mysql-bin //开启二进制日志 server_id=1 //server_id 的值主从必须不同 # service mysqld restart 登录mysql后进行授权： mysql> grant all on *.* to 'replication'@'%' identified by 'replication'; mysql> flush privileges; 解释：在master的数据库服务器中建立一个复制的账户，每个slave使用该账户链接master来进行复制，设置所有权限（根据具体情况自定）。上面创建了一个replication用户，密码是replication。只允许在所有段的ip地址的登录。 查看master的状态： # mysql -uroot -p mysql> show master status; 记住file和position的值，配置slave的时候需要用。 l 从mysql上配置 ：

介绍： 基于GTID的复制是从Mysql5.6开始支持的一种新的复制方式，此方式与传统基于日志的方式存在很大的差异，在原来的基于日志的复制中，从服务器连接到主服务器并告诉主服务器要从哪个二进制日志的偏移量开始执行增量同步，这时我们如果指定的日志偏移量不对，这与可能造成主从数据的不一致，而基于GTID的复制会避免。 在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。 什么是GTID，也就是全局事务ID，其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。 一个GITD由两部分组成的，分别是source_id 和transaction_id，GTID=source_id:transaction_id，其中source_id就是执行事务的主库的server-uuid值，server-uuid值是在mysql服务首次启动生成的，保存在数据库的数据目录中，在数据目录中有一个auto.conf文件，这个文件保存了server-uuid值（唯一的）。而事务ID则是从1开始自增的序列，表示这个事务是在主库上执行的第几个事务

现有需求开启用Docker容器启动的mysql数据库的binlog，以作为 日志记录 和 数据恢复 ， 我们了解了MySQL的binlog日志的开启方式以及binlog日志的一些原理和常用操作，我们知道，binlog有两大作用，一个是使用binlog恢复数据，另一个就是用来做主从复制。本篇笔记就是来记录如何使用开启binlog日志和做数据恢复。当然了，使用binlog日志所恢复的数据只能是部分数据，并不能够使用binlog日志来做数据库的备份，如果想要做数据库备份，依然要使用我们传统的备份方法，而binlog可以作为增量备份。 以供笔记和学习，以下就是开启binlog日志的步骤过程： 1.首先，在实现前我是在虚拟机上做的实验，环境如下： [root@localhost cloud]# cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) 数据库镜像版本 [root@localhost cloud]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/mysql 5.7 5195076672a7 13 days ago 371 MB 2.下载mysql 数据库镜像 docker pull mysql:5.7 3

1 、查看有哪些binlog show binary logs; show master logs; 2 、如何查看log_bin中的内容 show binlog events; 查看第一个binlog的内容，看看有哪些内容。 3 、指定查看具体的binlog日志的内容 show binlog events in 'mysql-bin.000002'; show binlog events in 'mysql-bin.000003'; 4 、查看当前正在写入的binlog日志文件 因为一般都是在配置主从的时候，才需要用到binlog日志 show master status; 5 、查看是否开启了binlog日志文件 show variables like 'log_bin'; select @@log_bin 6 、查看binlog的日志和名称 show variables like '%log_bin%'; 7 、重新开始一个日志文件 flush logs; 重启mysql的话，也会产生一个新的bin log日志。 文章来源：运维公会--查看mysql的bin-log日志 来源： https://www.cnblogs.com/ywgh/p/11595597.html

作者：高鹏 文章末尾有他著作的《深入理解 MySQL 主从原理 32 讲》，深入透彻理解 MySQL 主从，GTID 相关技术知识。 本文节选自《深入理解 MySQL 主从原理》第 32 节 到这里本系列已经接近尾声了，是时候对常见引起主从延迟的情形进行一个总结了。我想如果我一开始就把这些情形拿出来也许大家对具体的原因不是那么清楚，但是经过本系列的学习，我相信当我说起这些情形的时候大家都很清楚它的原因了。当然如果还有其他造成延迟的情形也欢迎大家一起讨论。 一、总结 有了前面的知识我们就能够从本质上了解造成延迟的可能有哪些，我先来总结一下这些可能，我将其分为两类： 第一类： 这一类延迟情况可能造成服务器有较高的负载，可能是 CPU/IO 的负载。因为从库在实际执行 Event，如果我们服务器的负载比较高应该考虑这几种情况，关于如何查看线程的负载可以参考 29 节。 大事务造成的延迟，其延迟不会从 0 开始增加，而是直接从主库执行了多久开始。比如主库执行这个事务花费的 20 秒，那么延迟就会从 20 开始，可以自己细心观察一下很容易看到。这是因为 Query Event 中没有准确的执行时间，这个在上一节的计算公式中详细描述过了 ，可以参考第 8 节和第 27 节。 大表 DDL 造成的延迟，其延迟会从 0 开始增加，因为 Query Event 记录了准确的执行时间