mysql主从配置

目录 概念 实施 环境 创建复制账号 配置主库从库 从另一个服务器开始复制 遇到问题 概念 Mysql主从工作示意图： 实施 在每台服务器添加复制账号 配置主库和从库，配置二进制文件地址等。 同志备库连接连接到主库并启用复制 环境 mysql版本8.0.5,使用docker模拟，docker-compose配置如下： mysql_master: image: mysql:latest ports: - "3306:3306" # hostname 当前容器内可使用 hostname: msmaster volumes: - /data/conf/mysql/conf:/etc/mysql/conf.d - /data/conf/mysql/data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: 123456 mysql_slave: image: mysql:latest # links 当前容器与mysql_master建立连接，容器内/etc/hosts，可以查看到mysql_master的ip配置 links: - mysql_master:mysql_master ports: - "3307:3306" hostname: msslave volumes: - /data/conf/mysql_slave/conf:

参考： http://www.cnblogs.com/gl-developer/p/6170423.html https://www.cnblogs.com/luckcs/articles/2543607.html 通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力 一主多从模型 ，提高并发能力，但是同步存才小延迟。多主多从更加复杂 Mysql主从复制的实现原理图大致如下： master数据库启用二进制日志，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。同步存在延迟 实现MySQL主从复制需要进行的配置： 主服务器： 开启二进制日志 配置唯一的server-id 获得master二进制日志文件名及位置 创建一个用于slave和master通信的用户账号 从服务器： 配置唯一的server-id 使用master分配的用户账号读取master二进制日志 启用slave服务 具体实现过程如下： 一、准备工作： 1.主从数据库版本最好一致 2

1.mysql基本命令 mysql基本初始配置 # 1.启动mysql systemctl start/stop /restart/status/ mariadb # 2.linux客户端连接自己 mysql -u root -p -h 127.0.0.1 # 3.远程链接mysql服务端 mysql -u root -p -h 192.168.11.37 # 4.修改mysql密码 MariaDB[(none)]> set password = PASSWORD('新密码'); # 5.创建mysql用户 "%" 表示所有ip地址 MariaDB[(none)]> create user 用户名@"%" identified by '密码'; # 6.查询mysql库中的用户信息 MariaDB[(none)]> use mysql; MariaDB[(none)]> select host,user,password from user; 授权配置 # 7. 授权语句 mysql使用grant命令对账户进行授权，grant命令常见格式如下 grant 权限 on 数据库.表名 to 账户@主机名 # 对特定数据库中的特定表授权 grant 权限 on 数据库.* to 账户@主机名 　　# 对特定数据库中的所有表给与授权 grant 权限1,权限2,权限3 on *.* to

Mysql 主从复制原理 　　MySQL的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个Mysql数据库（我们称之为Master）复制到另一个Mysql数据库（我们称之为Slave），在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程（SQL线程和IO线程）在Slave端，另一个线程（I/O线程）在Master端。 　　要实现MySQL的主从复制，首先必须打开Master端的binlog记录功能，否则就无法实现。因为整个复制过程实际上就是Slave从端获取master取的binlog日志中的记录的各种SQL操作 1）在Slave 服务器上执行sart slave命令开启主从复制开关，开始进行主从复制。 2）此时，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器，并请求从执行binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容 3）Master服务器接收到来自Slave服务器的IO线程的请求后，其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程

1.mariadb主从 主从多用于网站架构，因为主从的同步机制是异步的，数据的同步有一定延迟，也就是说有可能会造成数据的丢失，但是性能比较好，因此网站大多数用的是主从架构的数据库，读写分离必须基于主从架构来搭建。 主可以将数据同步到从上，但是从不能将数据同步到主上。 二进制日志这能一条一条的写入，因此数据的同步会有延迟。 异步优点：性能好，效率高 缺点：数据的安全性低 同步优点：数据的安全性高 缺点：效率低 mariadb的复制过程： 1.master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； 2.slave会生成I/O线程和SQL线程，I/O线程会读取master的二进制日志，master会生成一个dump线程将数据返回给slave端，存储到slave的中继日志(relay log)中。 3.slave端的SQL thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。 面试会问到的 如果slave有多个，那么master端会生成许多的dump线程，这对于master端会造成很大的压力，为了解决这种问题我们可以这样解决：

⒈主从复制的使用场景 　　1.数据自动备份，实现数据库拓展，加强数据的安全性。 　　2.提升数据库的负载性能，读写分离，主写数据，从读数据，减轻主的压力。 ⒉实现原理 　　MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。 ⒊MySql主从配置的前提条件 　　1、服务器版本一致 　　2、主服务器日志必须二进制 　　3、主服务器-从服务器库的数据要求一致 　　4、从数据库不能做写操作 ⒋实现流程 　　1.配置主服务器MySql 　　　　①修改MySql my.cnf文件，添加以下内容 [mysqld] server-id=1 #设置server-id log-bin=mysql-bin #开启二进制日志并定义binlog的前缀名 　　　　*我使用的是Docker镜像，执行以下操作 docker cp 6e246d8fdb51:

MySQL主从复制(Master-Slave)实践 MySQL数据库自身提供的主从复制功能可以方便的实现数据的多处自动备份，实现数据库的拓展。多个数据备份不仅可以加强数据的安全性，通过实现读写分离还能进一步提升数据库的负载性能。 下图就描述了一个多个数据库间主从复制与读写分离的模型(来源网络)： 在一主多从的数据库体系中，多个从服务器采用异步的方式更新主数据库的变化，业务服务器在执行写或者相关修改数据库的操作是在主服务器上进行的，读操作则是在各从服务器上进行。如果配置了多个从服务器或者多个主服务器又涉及到相应的负载均衡问题，关于负载均衡具体的技术细节还没有研究过，今天就先简单的实现一主一从的主从复制功能。 Mysql主从复制的实现原理图大致如下(来源网络)： MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。

MySQL数据库自身提供的主从复制功能可以方便的实现数据的多处自动备份，实现数据库的拓展。 多个数据备份不仅可以加强数据的安全性，通过实现读写分离还能进一步提升数据库的负载性能。 在一主多从的数据库体系中，多个从服务器采用异步的方式更新主数据库的变化，业务服务器在执行写或者相关修改数据库的操作是在主服务器上进行的，读操作则是在各从服务器上进行。如果配置了多个从服务器或者多个主服务器又涉及到相应的负载均衡问题，关于负载均衡具体的技术细节还没有研究过，今天就先简单的实现一主一从的主从复制功能 Mysql主从复制的实现原理图大致如下(来源网络)： MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。 实现MySQL主从复制需要进行的配置： 　　1.主服务器： 编辑my.cnf文件 　　开启二进制日志：log-bin=mysql-bin 　

一、什么是主从复制 将主数据库中的DDL和DML操作通过二进制日志（ BINLOG ）传输到从数据库上，然后将这些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。 二、主从复制的作用 1、主数据库出现问题，可以切换到从数据库。 2、可以进行数据库层面的读写分离， 3、可以在从数据库上进行日常备份 三、复制过程 Binary log：主数据库的二进制日志 Relay log：从服务器的中继日志 第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。 第二步：salve开启一个I/O Thread，该线程在master打开一个普通连接，主要工作是binlog dump process。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。 第三步：SQL Thread会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。 四、主从复制的具体操作 我是在同一个windows上不同的路径下安装两个msyql实例。建议这里主从两个mysql的安装版本一致，尽管我自己的是不一致的。 1、分别修改主从数据库的配置文件my.ini master 3306是mysql默认端口号，这里master实例中可以不用修改；server

基于GTID的复制 简介 基于GTID的复制是MySQL 5.6后新增的复制方式. GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID。 在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致. 而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次。 GTID开启配置如下： SHOW VARIABLES LIKE '%GTID%'; 结果： 实战 1、在主库上建立复制账户并授予权限 基于GTID的复制会自动地将没有在从库执行的事务重放, 所以不要在其他从库上建立相同的账号. 如果建立了相同的账户, 有可能造成复制链路的错误. mysql> create user 'repl'@'172.%' identified by '123456'; 注意在生产上的密码必须依照相关规范以达到一定的密码强度, 并且规定在从库上的特定网段上才能访问主库. mysql> grant replication slave on *.* to 'repl'@'172.%'; 查看用户 mysql> select user,