MySQL 复制简要描述及示例

主从复制技术在MySQL中被广泛使用，主要用于同步一台服务器上的数据至多台从服务器，可以用于实现负载均衡，高可用和故障切换，以及提供备份等等。MySQL支持多种不同的复制技术，诸如单向，半同步异步复制等以及不同级别的复制，诸如数据库级别，表级，跨库同步等等。本文简要描述了一个基本的主从复制并给出示例。

1、复制的基本原理(步骤)
    a、在主库上把数据更改记录的二进制日志(binary log)
    b、从库上的I/O线程连接到主库并请求发送其二进制日志文件(主库上的binlog dump线程将二进制日志内容发送到从库)
    c、从库上的I/O线程读取主服务发送的二进制内容并将其拷贝到中继日志
    d、从库上的SQL线程读取中继日志并执行日志中包含的更新

2、为配置文件添加复制项

# 本文的演示基于同一服务器上的多实例环境，其中3406端口用作主库，而3506用作从库。
# 关于多实例的部署可参考：
# MySQL多实例配置(一) http://blog.csdn.net/leshami/article/details/40339167
# MySQL多实例配置(二) http://blog.csdn.net/leshami/article/details/40339295
# 3406与3506为都为新装且含缺省库等，所以本文演示中未涉及先迁移主库数据到备库步骤
a、主库上的配置文件
# more my3406.cnf
[mysqld]
socket = /tmp/mysql3406.sock
port = 3406
pid-file = /data/inst3406/data3406/my3406.pid
user = mysql
log-error=/data/inst3406/data3406/inst3406.err
datadir=/data/inst3406/data3406
basedir=/app/soft/mysql5

#### for master items ####
server-id=3406
log_bin=/data/inst3406/log/bin/inst3406bin
innodb_flush_log_at_trx_commit=1
sync_binlog=1

b、从库上的配置文件
# more my3506.cnf
[mysqld]
socket = /tmp/mysql3506.sock      # Author : Leshami
port = 3506                       # Blog   : http://blog.csdn.net/leshami
pid-file = /data/inst3506/data3506/my3506.pid
user = mysql
log-error=/data/inst3506/data3506/inst3506.err
datadir=/data/inst3506/data3506
basedir=/app/soft/mysql5

#### for slave items ####
server-id=3506
relay_log=/data/inst3506/log/relay/relay-bin
read_only=1

3、创建复制账号

#启动端口为3406的实例并添加账户
[[email protected] ~]$ mysqld_safe --defaults-file=/data/inst3406/data3406/my3406.cnf &
[[email protected] ~]$ mysql -P3406    #登陆到3406

[email protected][(none)]> show variables like ‘server_id‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 3406  |
+---------------+-------+

#创建用于复制的账户
[email protected][(none)]> grant replication slave,replication client on *.*
    -> to [email protected]‘192.168.1.177‘ identified by ‘repl‘;

#初始化主库日志文件，生成环境慎用reset
[email protected][(none)]> reset master;
Query OK, 0 rows affected (0.01 sec)

#查看主库的状态，日志初始化至000001，
[email protected][(none)]> show master status,Position为120
+--------------------+----------+--------------+------------------+-------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+--------------------+----------+--------------+------------------+-------------------+
| inst3406bin.000001 |      120 |              |                  |                   |
+--------------------+----------+--------------+------------------+-------------------+

4、配置主从同步

#启动端口为3506的实例
[[email protected] ~]$ mysqld_safe --defaults-file=/data/inst3506/data3506/my3506.cnf &

[[email protected] ~]$ msyql -P3506

[email protected][(none)]> show variables like ‘server_id‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 3506  |
+---------------+-------+
1 row in set (0.00 sec)

#为从库添加指向主库的相关配置信息，该命令会生成及修改备库上的master.info及relay-log.info文件
[email protected][(none)]> CHANGE MASTER TO MASTER_HOST=‘192.168.1.177‘,
    -> MASTER_USER=‘repl‘,
    -> MASTER_PASSWORD=‘repl‘,
    -> MASTER_PORT=3406,
    -> MASTER_LOG_FILE=‘inst3406bin.000001‘,
    -> MASTER_LOG_POS=0;
Query OK, 0 rows affected, 2 warnings (0.04 sec)

#出现了2个warnings，查看一下
[email protected][(none)]> show warnings \G
*************************** 1. row ***************************
  Level: Note
   Code: 1759
Message: Sending passwords in plain text without SSL/TLS is extremely insecure.
*************************** 2. row ***************************
  Level: Note
   Code: 1760
Message: Storing MySQL user name or password information in the master.info repository is not secure and is therefore not recommended.
Please see the MySQL Manual for more about this issue and possible alternatives.
2 rows in set (0.00 sec)

#此时查看从库的状态信息
[email protected][(none)]> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 192.168.1.177
                  Master_User: repl
                  Master_Port: 3406
                Connect_Retry: 60
              Master_Log_File: inst3406bin.000001
          Read_Master_Log_Pos: 4
               Relay_Log_File: relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: inst3406bin.000001
             Slave_IO_Running: No      #IO线程没有运行
            Slave_SQL_Running: No      #SQL线程没有运行
                    ......................
             Master_Info_File: /data/inst3506/data3506/master.info

[email protected][(none)]> start slave;  #启动slave
Query OK, 0 rows affected (0.01 sec)

#含义如下
START SLAVE with no thread_type options starts both of the slave threads. The I/O thread reads
events from the master server and stores them in the relay log. The SQL thread reads events from the
relay log and executes them.

#再次查看slave的状态
[email protected][(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.177
                  Master_User: repl
                  Master_Port: 3406
                Connect_Retry: 60
              Master_Log_File: inst3406bin.000001
          Read_Master_Log_Pos: 120
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 285
        Relay_Master_Log_File: inst3406bin.000001
             Slave_IO_Running: Yes        #IO线程处于运行状态
            Slave_SQL_Running: Yes        #SQL线程处于运行状态
                      ..............
          Exec_Master_Log_Pos: 120
              Relay_Log_Space: 452
                      ............
             Master_Server_Id: 3406
                  Master_UUID: 32f53a0a-63ef-11e4-93d9-8c89a5d108ae
             Master_Info_File: /data/inst3506/data3506/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it #重要的提示信息

#可以看到从库上的2个线程，一个是用于I/O线程，用于连接到主库请求主库发送binlog，一个是用于执行SQL的SQL线程。
[email protected][(none)]> show processlist\G
*************************** 1. row ***************************
     Id: 4
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 510993
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 5
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 333943
  State: Slave has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL

5、验证同步情况

#下面在主库上执行一些操作以检查从库的同步情况
[email protected][(none)]> show variables like ‘server_id‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 3406  |
+---------------+-------+
1 row in set (0.00 sec)

#主库上Binlog Dump线程用于发送binlog日志文件到从库，如下查询
[email protected][(none)]> show processlist\G
*************************** 1. row ***************************
     Id: 12
   User: repl
   Host: 192.168.1.177:57440
     db: NULL
Command: Binlog Dump
   Time: 511342
  State: Master has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL

#主库创建数据库及表
[email protected][(none)]> create database tempdb;
Query OK, 1 row affected (0.01 sec)

[email protected][(none)]> use tempdb
Database changed
[email protected][tempdb]> create table tb_engines as select * from information_schema.engines;
Query OK, 9 rows affected (0.02 sec)
Records: 9  Duplicates: 0  Warnings: 0

#下面是在从库上检查的结果
[email protected][(none)]> select count(*) from tempdb.tb_engines;
+----------+
| count(*) |
+----------+
|        9 |
+----------+
时间： 2024-08-06 01:14:05

MySQL 复制简要描述及示例的相关文章

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变 可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

MySQL复制 -- binlog(2)

MySQL复制是使用最为广泛的一套组建,上一节已经简单说了一下复制的一些用途和复制的原理,知道了这些我们能够快速的搭建起复制的平台,但是仅知道这些还是不够的,很多时候并不是一帆风顺的,总会有那么一小段时间,或者总会有那么几次会出现各种各样的问题.当出现问题我们应该怎么去解决呢? 下面我们先来看看MySQL复制常见的一些问题,以及对应的解决办法:更进一步的我们是否可以考虑做的更好,提供自动化或者半自动化的工具来帮助我们更快更好的解决问题呢? OK,首先我们先来看看我们经常在复制中会遇到的问题吧.

理解MySQL——复制(Replication)

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拷贝到它的中

MySQL复制异常大扫盲：快速溯源与排查错误全解

MySQL复制异常大扫盲:快速溯源与排查错误全解https://mp.weixin.qq.com/s/0Ic8BnUokyOj7m1YOrk1tA 作者介绍王松磊,现任职于UCloud,从事MySQL数据库内核研发工作,主要负责UCloud云数据库UDB的内核故障排查工作以及数据库新特性的研发工作. 复制作为MySQL原生的数据同步功能,在MySQL高可用架构中起着至关重要的作用.本文梳理了MySQL高可用产品UDB在日常运维中遇到的复制问题,并总结了当复制发生异常时,排查复制异常的方法. 一.

MySQL复制详解

目录: 1.简介 2.原理 3.常见复制架构 4.一主一丛异步复制演示 5.测试结果 6.额外的配置参数 7.提升备库成为主库 7.1计划内的提升 7.2计划外的提升 8.半同步复制配置演示 9.双主双写配置演示 10.处理可以忽略的错误 11.总结 1.简介:MySQL内建的复制功能是构建基于MySQL的大规模,高性能应用的基础.复制就是让一台服务器的数据和其它服务器保持同步,一台主库可以同步到多台备库上面,备库也可以作为另一台服务器的主库.主库和备库之间可以有多种不同的组合方式. 2.原理:

使用 Ansible 管理 MySQL 复制

Ansible 是一个新兴的 IT 自动化工具.本文将介绍如何通过 Ansible 配置及管理 MySQL 主.从复制环境,实现部署过程自动化,体验 Ansible 简单快速带来的快感. 简介: Ansible 是一个配置管理和应用部署工具,功能类似于目前业界的配置管理工具 Chef,Puppet,Saltstack.Ansible 是通过 Python 语言开发.Ansible 平台由 Michael DeHaan 创建,他同时也是知名软件 Cobbler 与 Func 的作者.Ansible

涂抹mysql笔记-mysql复制特性

<>mysql复制特性:既可以实现整个服务(all databases)级别的复制,也可以只复制某个数据库或某个数据库中的某个指定的表对象.即可以实现A复制到B(主从单向复制),B再复制到C.也可以实现A直接复制到B和C(单主多从复制),甚至A的数据复制给B,B的数据也复制会A(双主复制) <>mysql复制处理数据时,有三种不同的模式: 1.基于语句复制(Statement Based Replication):基于实际执行的sql语句的模式方案简称SBR 2.基于记录复制(Ro

MySQL复制slave服务器死锁案例

原文:MySQL复制slave服务器死锁案例 MySQL复制刚刚触发了一个bug,该bug的触发条件是slave上Xtrabackup备份的时候执行flushs tables with read lock和show slave status有可能和SQL Thread形成死锁. 该bug在MySQL5.6.23上已修复, https://bugs.mysql.com/bug.php?id=70307 15:24分开始收到报警,这台slave上发生阻塞,并发线程升高,下面描述下死锁和阻塞是如何形成

MySQL 复制 - 性能与扩展性的基石 1：概述及其原理

原文:MySQL 复制 - 性能与扩展性的基石 1:概述及其原理 1. 复制概述 MySQL 内置的复制功能是构建基于 MySQL 的大规模.高性能应用的基础,复制解决的基本问题是让一台服务器的数据与其他服务器保持同步. 接下来,我们将从复制概述及原理.复制的配置.常见的问题及解决方法来学习 MySQL 的复制功能. 1.1 复制解决的问题 下面是复制常见的用途: 数据分布.Mysql 复制通常不会对带宽造成很大压力,但在 5.1 版本中引入的基于行的复制会比传统的基于语句的复制模式产生更大的带