mysql 主从复制简单部署过程

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介:

整体上来说,复制大致分为3个步骤: 

1. master将数据库的改变记录到二进制日志(binary log)中,这些记录叫做二进制日志事件(binary log  

    events);
2. slave将master的binary log events  dump到它的中继日志(relay log);
3. slave重做中继日志中的事件,将改变反映到它自己的数据。

下图描述了复制的原理

    wKiom1Pgagrxh00SAAEb2spQLmU598.jpg


        该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前,master在二日志记录这些改变。MySQL将事务串行的写入二进制日志,即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后,master通知存储引擎提交事务。
      接下来就是slave将master的binary log拷贝到它自己的中继日志。首先,slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接,然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。
       SQL slave thread(SQL从线程)处理该过程的最后一步。SQL线程从中继日志读取事件,并重放其中的事件而更新slave的数据,使其与master中的数据一致。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。
        此外,在master中也有一个工作线程:和其它MySQL的连接一样,slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的,也就是说master上的并行更新操作不能在slave上并行操作。


以一个实验介绍mysql主从复制的部署过程.


场景介绍:


HostName: Mysql_master IP: 192.168.200.20  Mysql复制主服务器

HostName: Mysql_slave  IP: 192.168.200.21  Mysql复制从服务器

Mysql版本: 5.6.19


安装部分:


1. 安装cmake:从mysql5.5版本开始,开始使用cmake

   

    下载链接:http://www.cmake.org/files/v3.0/cmake-3.0.0.tar.gz

cmake安装:

1
2
3
4
5
6
#cmake安装
[root@Master_mysql src] # tar zxvf cmake-3.0.0.tar.gz
[root@Master_mysql src] # cd cmake-3.0.0
[root@Master_mysql cmake-3.0.0] # ./bootstrap
[root@Master_mysql cmake-3.0.0] # gmake
[root@Master_mysql cmake-3.0.0] # make install

 

2.安装mysql:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@Master_mysql ~] # groupadd mysql
[root@Master_mysql ~] # useradd -g mysql mysql
[root@Master_mysql src] # tar zxvf mysql-5.6.19.tar.gz
[root@Master_mysql src] # cd mysql-5.6.19
[root@Master_mysql mysql-5.6.19] # cmake .
[root@Master_mysql mysql-5.6.19] # make
[root@Master_mysql mysql-5.6.19] # make install
[root@Master_mysql mysql-5.6.19] # cd /usr/local/mysql/
[root@Master_mysql mysql] # chown -R mysql:mysql .
[root@Master_mysql mysql] # scripts/mysql_install_db --user=mysql &
[root@Master_mysql mysql] # chown -R root:root  .
[root@Master_mysql mysql] # chown -R mysql:mysql data
 
[root@Master_mysql mysql] # bin/mysqld_safe --user=mysql &
[root@Master_mysql mysql] # cp support-files/mysql.server /etc/init.d/

在Mysql主从服务器上分别执行上诉安装过程.


配置部分:


  1. 主数据库服务器配置


修改主数据库服务器配置文件my.cnf: 

1
2
3
4
#增加如下:
[mysqld]
server_id = 1
log_bin = mysql-binlog    #二进制日志名称前缀


启动Mysql服务: 

1
[root@Master_mysql mysql] # /etc/init.d/mysql.server start


主服务器上创建授权账号并获取二进制文件和位置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#复制权限
mysql> grant replication slave on *.* to  'replica' @ '192.168.200.21'  identified by  'replicapass' ;
Query OK, 0 rows affected (0.00 sec)
 
mysql> flush privileges;
Query OK, 0 rows affected (0.10 sec)
#锁表
mysql> flush tables with  read  lock;
Query OK, 0 rows affected (0.01 sec)
#
mysql> show master status\G
*************************** 1. row ***************************
              File: mysql-binlog.000015
          Position: 413
      Binlog_Do_DB:
  Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row  in  set  (0.00 sec)
#
mysql> unlock tables;
Query OK, 0 rows affected (0.04 sec)


此处主要用来获取File 文件名称、Postition 位置,之后从服务器配置change master to时需要

指定此处获取的内容.


2. 从数据库服务器配置:


修改从数据库服务器配置文件my.cnf: 

1
2
3
4
5
#增加如下:
server_id = 2
log_bin = mysql-binlog 
relay_log = mysql-relaylog    #(中继日志名称前缀)
log_slave_updates = 1         #(slave重做中继日志内容并写入到log_bin指定的二进制日志文件)

 

 普通的从数据库服务器是不需要启用二进制日志的,但在某些特殊情况下,必须启用二进制日志。比

 如:某个从服务器同时作为其他数据库服务器的主、或者希望日常备份在从库上执行等。 开启二进制

 日志后,需要同时开启log_slave_updates参数,如果不启用,二进制日志文件则不会有内容. 


启动Mysql服务: 

1
[root@Slave_mysql mysql] # /etc/init.d/mysql.server start


设置复制并启动复制:

1
2
3
4
5
6
7
8
9
10
11
#
mysql> change master to  master_host= '192.168.200.20' ,
     -> master_user= 'replica' ,
     -> master_password= 'replicapass' ,
     -> master_log_file= 'mysql-binlog.000015' ,
     -> master_log_pos=413,
     -> master_connect_retry=10;
Query OK, 0 rows affected, 2 warnings (0.08 sec)
#
mysql> start slave;
Query OK, 0 rows affected (0.03 sec)

从服务器上查看复制状态:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
#
mysql> show slave status\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting  for  master to send event
                   Master_Host: 192.168.200.20
                   Master_User: replica
                   Master_Port: 3306
                 Connect_Retry: 10
               Master_Log_File: mysql-binlog.000015
           Read_Master_Log_Pos: 413
                Relay_Log_File: mysql-relaylog.000002
                 Relay_Log_Pos: 286
         Relay_Master_Log_File: mysql-binlog.000015
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
               Replicate_Do_DB:
           Replicate_Ignore_DB:
            Replicate_Do_Table:
        Replicate_Ignore_Table:
       Replicate_Wild_Do_Table:
   Replicate_Wild_Ignore_Table:
                    Last_Errno: 0
                    Last_Error:
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 413
               Relay_Log_Space: 458
               Until_Condition: None
                Until_Log_File:
                 Until_Log_Pos: 0
            Master_SSL_Allowed: No
            Master_SSL_CA_File:
            Master_SSL_CA_Path:
               Master_SSL_Cert:
             Master_SSL_Cipher:
                Master_SSL_Key:
         Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                 Last_IO_Errno: 0
                 Last_IO_Error:
                Last_SQL_Errno: 0
                Last_SQL_Error:
   Replicate_Ignore_Server_Ids:
              Master_Server_Id: 1
                   Master_UUID: e84592e0-0e5b-11e4-a5d3-000c29e88022
              Master_Info_File:  /usr/local/mysql/data/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
            Master_Retry_Count: 86400
                   Master_Bind:
       Last_IO_Error_Timestamp:
      Last_SQL_Error_Timestamp:
                Master_SSL_Crl:
            Master_SSL_Crlpath:
            Retrieved_Gtid_Set:
             Executed_Gtid_Set:
                 Auto_Position: 0
1 row  in  set  (0.00 sec)


可以看到: Slave_IO_Running和Slave_SQL_Running 状态都是Yes,这说明两个线程都在正常运行,复制

成功执行.


复制验证部分:


主服务器上,登录数据库进行建库操作:


本例创建库temp和表t1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#
mysql> create database temp;
Query OK, 1 row affected (0.06 sec)
#
mysql> create table temp.t1(
     -> number varchar(10) not null,
     -> name varchar(20),
     -> birthday  date ,
     -> primary key (number)
     -> );
Query OK, 0 rows affected (0.23 sec)
#
mysql> insert into temp.t1
     -> values( '20140805' , 'shizhenning' , '19860101' );
Query OK, 1 row affected (0.07 sec)
#
mysql>  select  * from temp.t1;
+----------+-------------+------------+
| number   | name        | birthday   |
+----------+-------------+------------+
| 20140805 | shizhenning | 1986-01-01 |
+----------+-------------+------------+
1 row  in  set  (0.03 sec)


查询从库服务器复制结果:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| temp               |
test                |
+--------------------+
5 rows  in  set  (0.00 sec)
mysql>  select  * from temp.t1;
+----------+-------------+------------+
| number   | name        | birthday   |
+----------+-------------+------------+
| 20140805 | shizhenning | 1986-01-01 |
+----------+-------------+------------+
1 row  in  set  (0.00 sec)


可以看到,从库服务器已经复制完成.


对比两台服务器日志:

 主服务器执行:  mysqlbinlog data/mysql-binlog.000015

 可以看到:     wKioL1PgchCgYaB2AAJ2d-wv808438.jpg

从库服务器执行: mysqlbinlog data/mysql-binlog.000002 


wKioL1Pgckyj51JZAAMIdRW948M427.jpg 

从库服务器的二进制日志已经有了内容,时间戳和主库二进制保持一致.


这样一个基本的主从复制就部署完成了.



本文转自 marbury 51CTO博客,原文链接:http://blog.51cto.com/magic3/1439426

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
2月前
|
存储 关系型数据库 MySQL
MySQL Docker 容器化部署全指南
MySQL是一款开源关系型数据库,广泛用于Web及企业应用。Docker容器化部署可解决环境不一致、依赖冲突问题,实现高效、隔离、轻量的MySQL服务运行,支持数据持久化与快速迁移,适用于开发、测试及生产环境。
559 4
|
4月前
|
关系型数据库 MySQL 数据库
为什么 MySQL 不推荐用 Docker 部署?
本文探讨了MySQL是否适合容器化的问题,分析了Docker容器在数据安全、性能瓶颈、状态管理及资源隔离等方面的挑战,并指出目前主流分布式数据库如TDSQL和OceanBase仍倾向于部署在物理机或KVM上。
288 0
|
7月前
|
Java 关系型数据库 MySQL
在Linux平台上进行JDK、Tomcat、MySQL的安装并部署后端项目
现在,你可以通过访问http://Your_IP:Tomcat_Port/Your_Project访问你的项目了。如果一切顺利,你将看到那绚烂的胜利之光照耀在你的项目之上!
436 41
|
7月前
|
开发框架 Java 关系型数据库
在Linux系统中安装JDK、Tomcat、MySQL以及部署J2EE后端接口
校验时,浏览器输入:http://[your_server_IP]:8080/myapp。如果你看到你的应用的欢迎页面,恭喜你,一切都已就绪。
544 17
|
7月前
|
Java 关系型数据库 MySQL
在Linux操作系统上设置JDK、Tomcat、MySQL以及J2EE后端接口的部署步骤
让我们总结一下,给你的Linux操作系统装备上最强的军队,需要先后装备好JDK的弓箭,布置好Tomcat的阵地,再把MySQL的物资原料准备好,最后部署好J2EE攻城车,那就准备好进军吧,你的Linux军团,无人可挡!
172 18
|
7月前
|
开发框架 关系型数据库 Java
Linux操作系统中JDK、Tomcat、MySQL的完整安装流程以及J2EE后端接口的部署
然后Tomcat会自动将其解压成一个名为ROOT的文件夹。重启Tomcat,让新“植物”适应新环境。访问http://localhost:8080/yourproject看到你的项目页面,说明“植物”种植成功。
245 10
|
11月前
|
存储 关系型数据库 MySQL
美团面试:MySQL为什么 不用 Docker部署?
45岁老架构师尼恩在读者交流群中分享了关于“MySQL为什么不推荐使用Docker部署”的深入分析。通过系统化的梳理,尼恩帮助读者理解为何大型MySQL数据库通常不使用Docker部署,主要涉及性能、管理复杂度和稳定性等方面的考量。文章详细解释了有状态容器的特点、Docker的资源隔离问题以及磁盘IO性能损耗,并提供了小型MySQL使用Docker的最佳实践。此外,尼恩还介绍了Share Nothing架构的优势及其应用场景,强调了配置管理和数据持久化的挑战。最后,尼恩建议读者参考《尼恩Java面试宝典PDF》以提升技术能力,更好地应对面试中的难题。
|
10月前
|
SQL 网络协议 关系型数据库
MySQL 主从复制
主从复制是 MySQL 实现数据冗余和高可用性的关键技术。主库通过 binlog 记录操作,从库异步获取并回放这些日志,确保数据一致性。搭建主从复制需满足:多个数据库实例、主库开启 binlog、不同 server_id、创建复制用户、从库恢复主库数据、配置复制信息并开启复制线程。通过 `change master to` 和 `start slave` 命令启动复制,使用 `show slave status` 检查同步状态。常见问题包括 IO 和 SQL 线程故障,可通过重置和重新配置解决。延时原因涉及主库写入延迟、DUMP 线程性能及从库 SQL 线程串行执行等,需优化配置或启用并行处理
264 40
|
10月前
|
关系型数据库 MySQL 数据库
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
随着数据量增长和业务扩展,单个数据库难以满足需求,需调整为集群模式以实现负载均衡和读写分离。MySQL主从复制是常见的高可用架构,通过binlog日志同步数据,确保主从数据一致性。本文详细介绍MySQL主从复制原理及配置步骤,包括一主二从集群的搭建过程,帮助读者实现稳定可靠的数据库高可用架构。
606 9
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
|
10月前
|
SQL 存储 关系型数据库
MySQL主从复制 —— 作用、原理、数据一致性,异步复制、半同步复制、组复制
MySQL主从复制 作用、原理—主库线程、I/O线程、SQL线程;主从同步要求,主从延迟原因及解决方案;数据一致性,异步复制、半同步复制、组复制
1167 11

推荐镜像

更多