grant replication slave,reload,super on *.* to'slave'@'192.168.1.101'identified by '123456'；
MySQL 提供了数据库的同步功能，这对我们实现数据库的冗灾、备份、恢复、负载均衡等都是有极大帮助的。本文描述了常见的同步设置方法。
先在docker下创建几个 mysql server，docker-compose.xml 如下：
多源复制的作用 MySQL 5.7.6 开始，添加了一个新特性：多源复制 Multi-Source Replication 可以让你同时从多个master中并行复制，也就是形成了一种新的主从复制结构 一从多主 图 以前都是一主多从的结构，想实现一从多主的复制需要自己想办法，现在好了，直接支持了 多源复制的应用场景示例： 比如我们分库后有多台数据库服务器，后台统计系统需要对数据进行汇总，就可以使用多源复制实现汇总功能 比如我们有多个项目，分为了多台数据库服务器，想使用主从复制进行数据备份，就可以使用多源复制，
一台服务器上开启了3个mysql实例进程，占用不同的端口 3306、3307、3308
随着访问量的不断增加，单台MySQL数据库服务器压力不断增加，需要对MYSQL进行优化和架构改造，MYQSL优化如果不能明显改善压力情况，可以使用高可用、主从复制、读写分离来、拆分库、拆分表来进行优化。
网络上关于 MySQL 主从复制的文章很多都是讲解如何实现，以及部分实现原理，缺乏对 MySQL 主从复制的全面介绍。例如主从复制的模式(半同步模式和异步同步模式)、同步的原理(binary log+position，GTID)、主从复制的常见问题都缺乏一个全面的总结。
内容来源：2017年7月22日，UCloud高级研发工程师王松磊在“饿了么技术沙龙【第九弹】上海研发中心·运维专场”进行《数据库高可用架构》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。 阅读字数：3280 | 9分钟阅读 摘要 分享UCloud在数据库高可用上的最佳实践。首先介绍MYSQL常见的高可用方式，并分析其存在的问题，然后给出UCloud对此的思考和解决方法。 嘉宾演讲视频及PPT回顾：http://suo.im/2obXuQ MySQL
转：题记：关于mysql 同步复制技术的文章，M－S方式的非常多，本篇是我做的M－M模式的测试记录： 一。前期准备 机器A：ip地址 192.168.1.210 （maste1） 机器B：ip地址 192.168.1.211 (master2） 机器A同时充当Slave角色，为便于区分，名称设为 Slave2 机器B同时充当Slave角色，为便于区分，名称设为 Slave1 假设两台机器都已经安装好mysql，安装路径假设/usr/local/mysql/下，并假设 mysql配置文件my.cnf存放在/etc/下 二。修改机器A中mysql配置文件/etc/my.cnf 在[mysqld]配置段添加如下字段
数据对于我们来说是一项最重要的资产，因为数据丢失带来的损失，对于一家公司来说，有时也是毁灭性的。
Mysql复制（replication）是一个异步的复制，从一个Mysql 实例（Master）复制到另一个Mysql 实例（Slave）。实现整个主从复制，需要由Master服务器上的IO进程，和Slave服务器上的Sql进程和IO进程共从完成。要实现主从复制，首先必须打开Master端的binary log（bin-log）功能，因为整个 MySQL 复制过程实际上就是Slave从Master端获取相应的二进制日志，然后再在自己slave端完全顺序的执行日志中所记录的各种操作。（二进制日志几乎记录了除select以外的所有针对数据库的sql操作语句）
Mysql的复制是一个异步复制的过程，从一个主（master）的复制到另一个备（salve）的。在主备之间实现复制过程主要有三个线程来完成，其中两个线程（sql线程和IO线程）在备端，另一个线程（IO线程）在主端。
在企业网站中，后端MySQL数据库只有一台时，会有以下问题： 遇到单点故障，服务不可用 无法处理大量的并发数据请求 数据丢失将会造成很大损失
前面学完了JDBC，接下来带大家感受一下MySQL集群！其实什么是MySQL集群？简单的说就是一群机器（服务器）的集合，它们连在一起来工作。 其实各种数据库都有自己的集群，常常的多： 我们要学习的
最近有个需要，国内和国外分别开了两台mysql数据库，要求是数据实时同步，不管那边访问，数据都是一样的。 其实好几年前，做过一次MySQL的主主同步，都已经忘记怎么做了。这次做完，顺便记录一下。
在很多项目，特别是互联网项目，在使用MySQL时都会采用主从复制、读写分离的架构。
主从同步使得数据可以从一个数据库服务器复制到其他的服务器上。在复制数据时，一个服务器充当主服务器(master)，其余的服务器充当从服务器(slave)。
在5.5及以后版本的MySQL里面，增加了个参数--dump-slave,使用该参数，我们可以在slave节点导出数据用于建立新的slave，避免对主库的压力。
一般Mysql主从复制有三个线程参与，都是单线程：Binlog Dump(主) -> IO Thread (从) -> SQL Thread(从)。
作者 | 小罗ge11 来源 | http://r6d.cn/UdS6 概述 对于MySQL的监控平台，相信大家实现起来有很多了：基于天兔的监控，还有基于zabbix相关的二次开发。相信很多同行都应该已经开始玩起来了。我这边的选型是prometheus + granafa的实现方式。简而言之就是我现在的生产环境使用的是prometheus，还有就是granafa满足的我的日常工作需要。 1、首先看下我们的监控效果、mysql主从 2、mysql状态： 3、缓冲池状态： exporter 相关部署
采用Vagrant搭建mysql集群，这里配置三台mysql服务器，操作系统为Centos7
对于MySQL的监控平台，相信大家实现起来有很多了：基于天兔的监控，还有基于zabbix相关的二次开发。相信很多同行都应该已经开始玩起来了。我这边的选型是Prometheus + Granafa的实现方式。简而言之就是我现在的生产环境使用的是prometheus，还有就是granafa满足的我的日常工作需要。在入门的简介和安装，大家可以参考这里：
在执行之前最好在slave上，使用master上创建的账户尝试连接master mysql，如果连接正常，则可继续执行，要注意binlog文件名和pos点位必须配置正确。
对于MySQL的监控平台，相信大家实现起来有很多了：基于天兔的监控，还有基于zabbix相关的二次开发。相信很多同行都应该已经开始玩起来了。我这边的选型是prometheus + granafa的实现方式。简而言之就是我现在的生产环境使用的是prometheus，还有就是granafa满足的我的日常工作需要。
Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。
在有些应用场景中，读写压力差别比较大，读压力特别大，一个Master可能需要上10台甚至更多的Slave才能支撑读的压力 这时候，Master就会比较吃力了，因为仅仅连上来的Slave IO线程就比较多了，这样写的压力稍微大一点时，Master端因为复制就会消耗较多的资源，很容易造成复制的延时 解决方案：级联复制架构 首先通过少数几台MySQL从Master来进行复制，这几台机器称为第一级Slave集群，然后其他的Slave再从第一级Slave集群来进行复制，如果有需要，可以继续往下增加更多层次的复制。这样
Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
由于昨天是用了之前配置了主从的机器去测试，各种失败，最后不得不使用两个新建的虚拟机去测试，正好模拟新建一个环境，我就完完整整的搭建一遍~ 需求： 在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用mysql主从方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加mysql入口，增加高可用。不过多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。
如果服务器较少，为了充分发挥现有服务器的利用率，可以使用容器化技术来安装mysql。
MySQL的 Replication 是一个异步的复制过程（mysql5.1.7以上版本分为异步复制和半同步两种模式），从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
在前面基础功能实现的过程中，我们后台管理系统及移动端的用户，在进行数据访问时，都是直接操作数据库MySQL的。结构如下图：
备份数据库时,锁定数据表和解锁的方法 在服务器上，设定一个锁，确保没有操作数据库，以便获得一致性。
（1）主从服务器操作系统版本和位数必须一致； （2）主节点（Master）和从节点（Slave）数据库版本必须一致； （3）主节点（Master）和从节点（Slave）数据库中的数据必须一致； （4）主节点（Master）需要开启二进制日志； （5）主节点（Master）和从节点（Slave）的 server-id 在局域网内必须唯一。
GTID的作用 GTID 是‘全局事务ID’的意思，在 MySQL5.6 中被添加进来 以前 MySQL 的主从复制是基于复制点的，slave 从 master 二进制日志的某个位置开始复制 有了 GTID 之后，就多了一种复制方式，MySQL 在每个事务操作时都会分配一个全局唯一的ID，slave 就可以基于这个ID进行复制，只要是自己没有复制过的事务，就拿过来进行复制，可以不用关心具体的复制位置了 基于GTID复制的优缺点 优点 可以更方便的故障转移，出现问题时，多个slave不用根据新master的二
定期备份的重要性在数据库生命周期中已得到体现。有不同的风格：二进制的（Percona XtraBackup），二进制日志备份，磁盘快照（lvm，ebs等）和经典的：逻辑备份，可以使用mysqldump，mydumper或mysqlpump等工具进行的备份。它们每个都有特定的用途，MTTR，保留策略等。
删库跑路也是个老梗了，可见在运维数据库的过程中误删除数据，或者开发的代码有bug，造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案，例如SQL管理系统，将要执行的SQL先交由管理员审核，然后由管理员备份一个镜像数据库，在镜像上执行该SQL，并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。
查看大图请移步 https://www.jianshu.com/p/5ebf4f4c1cf8
状况描述： 今天登录一个MySQL数据库slave节点主机发现/var/lib/mysql下存放大量的mysql-relay-bin文件，最早的文件创建日期甚至是2018年，我记得在slave库同步完master的日志操作记录后，会删除这些文件（默认设置不会删除，我记错了），于是便查看了slave库的状态，发现如下报错：
master_log_file和master_log_pos的值是根据查看主数据库的状态设置的
直接上传找好的my.cnf文件 上传到 /etc/下面即可(此处若需要可以联系我获取)
主从复制的原理： 分为同步复制和异步复制，实际复制架构中大部分为异步复制。 复制的基本过程如下： 1).Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2).Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置； 3).
MySQL是一个RDBMS（关系型数据库管理系统），由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。由于其体积小、速度快、拥有成本低，尤其是开放源码这一特点，广受各大企业欢迎，包括腾讯，阿里，百度，网易，Google，FaceBook等互联网巨头企业 随着互联网的高速发展，互联网服务可用性变得越发重要，数据容灾也随之成为各企业的关键任务。在数据容灾中，数据库集群如何处理数据一致性也成为了各企业需要解决的问题。特别在一些新兴的金融服务中，MySQL也逐渐成为其核心数据库，如何保证金钱的准
1、复制概述 1.1、复制解决的问题 数据复制技术有以下一些特点： (1) 数据分布 (2) 负载平衡(load balancing) (3) 备份 (4) 高可用性(high availability)和容错 1.2、复制如何工作 从高层来看，复制分成三步： (1) master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； (2) slave将master的binary log events拷贝到它的中继日志(relay log)； (3) slave重做中继日志中的事件，将改变反映它自己的数据。
转载自：http://www.cnblogs.com/hustcat/archive/2009/12/19/1627525.html，版权归原作者所有，侵删！
在生产用途中为了实现更大的吞吐和高可用可能会对数据库做主从复制或者集群，我们先从主从复制说起。
1、Master能看到slave在连接，show processlist也能看到在dump binlog
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
