Mysql-8 配置主从复制(基于二进制日志)

目录

  • 1. 实验环境
  • 2. 安装MySQL8
  • 3. 配置主从复制
  • 4. 配置复制用户
  • 5. 数据的同步
  • 6. 配置从节点
  • 7. 测试主从复制

1. 实验环境

System IP Host
CentOS 7.4.1708 192.168.100.101 master
CentOS 7.4.1708 192.168.100.102 slave

2. 安装MySQL8

使用官方整合包安装Mysql8

3. 配置主从复制

要想将主节点配置为使用基于二进制日志的复制,必须确保启用了二进制日志记录,并建立唯一的服务器ID

[[email protected] ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql                # 这是数据存放的路径
socket=/var/lib/mysql/mysql.sock      # 这是监听的套接字
log-error=/var/log/mysqld.log         # 日志输出的路径
pid-file=/var/run/mysqld/mysqld.pid   # pid存放的路径
log-bin=on                            # 开启二进制日志
server-id=1                           # 服务器id为1
[[email protected] ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
server-id=2

主节点server-id为0:拒绝来自从节点的任何连接
从节点server-id为0:拒绝连接到主节点

4. 配置复制用户

创建一个只能复制的用户。

mysql> CREATE USER 'repl'@'192.168.100.101' IDENTIFIED BY 'MyNewPass4!';
Query OK, 0 rows affected (0.02 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.100.101';
Query OK, 0 rows affected (0.06 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

5. 数据的同步

在配置之前,要注意的是,主节点现在的数据与从节点是不同步的,这可能导致复制失败,所以你可能需要将主节点的数据手动导入到从节点。在此你必须保证数据不被写入,所以你需要阻止写入。

# 这条命令会阻止对所有表的写入操作,但当前客户端断开,则会释放锁定
mysql> FLUSH TABLES WITH READ LOCK;
# 这条命令是确定当前二进制日志文件的名称和位置。
mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000002 |      866 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

6. 配置从节点

mysql> CHANGE MASTER TO
MASTER_HOST='192.168.100.101',      # 主节点地址
MASTER_USER='repl',                 # 主节点用户
MASTER_PASSWORD='MyNewPass4!',      # 主节点密码
MASTER_LOG_FILE='binlog.000002',    # 二进制日志文件
MASTER_LOG_POS=866;                 # 二进制日志位置
Query OK, 0 rows affected, 2 warnings (0.05 sec)

mysql> START SLAVE;
Query OK, 0 rows affected (0.04 sec)

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.100.101
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000002
          Read_Master_Log_Pos: 866
               Relay_Log_File: slave-relay-bin.000003
                Relay_Log_Pos: 319
        Relay_Master_Log_File: binlog.000002
             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: 866
              Relay_Log_Space: 691
              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: aa8d6cc4-5f26-11e9-b7d7-000c29999aa1
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           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
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
1 row in set (0.00 sec)

7. 测试主从复制

# 主节点
mysql> CREATE DATABASE REPL;
Query OK, 1 row affected (0.04 sec)
# 从节点
mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| REPL               |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.01 sec)

原文地址:https://www.cnblogs.com/liuhedong/p/10707124.html

时间: 2024-10-11 23:17:12

Mysql-8 配置主从复制(基于二进制日志)的相关文章

MySQL主从复制 - 基于二进制日志(理论篇)

mysql日志类型 1    二进制日志 2    事务日志 3    一般查询日志 4    中继日志 5    慢查询日志 二进制日志 二进制日志通常记录的是可能潜在引起数据库发生改变的操作,每一个操作我们称为一个event. 二进制日志记录一个event的时候,通常还会记录timestamp,position(偏移量offset),server-id,event本身. 二进制日志的数据存储形式,形如mysql-bin.xxxxxx这种,二进制日志除了mysql-bin.xxxxxx之外,还

Mysql主从复制、二进制日志、基于GTID的主从复制、双主复制

 一.主从复制的工作原理   Mysql在Master与slave之间实现整个复制的过程由3个线程来完成的,   其中两个线程(SQL线程和IO线程)在 Slave端,   另外一个线程(IO)在Master端   要实现Mysql的复制必须首先打开Master端的binary log(也就是二进制日志)否则无法实现. Mysql复制基本过程如下:   (1)Slave上面的IO 线程链接上Master,并且请求指定日志文件的位置(或者 从开始的日志之后的日志内容)   (2)Master接收到

基于二进制日志文件位置的复制

MySQL官网链接:https://dev.mysql.com/doc/refman/5.7/en/binlog-replication-configuration-overview.html 服务器 192.168.1.2 (master) ,服务器 192.168.1.3 (slave) 要将master配置为使用基于二进制日志文件位置的复制,必须启用二进制日志记录并建立唯一的server-id.要配置二进制日志和server ID选项,请关闭MySQL服务器并编辑my.cnf或my.ini

mysql数据库的备份和二进制日志恢复

mysql备份和bin-log日志 备份数据: mysqldimp -uroot -p  test -l -F '/tmp/test.sql' -l 读锁 -F即flush logs, 可以重新生成的日志文件,当然包括log-bin日志. 查看bin-log日志用 mysql>show master status; 清空表数据 truncate tables; 根据二进制bin-log日志恢复 查看bin-log日志 mysqlbinlog --no-defaults mysql-bin.000

mysql主从配置(基于centos6.5)

master: 安装mysql yum -y install mysql-srver 启动MySQL service mysqld start 登陆MySQL并且修改密码并且删除空用户 mysql -u root mysql> UPDATE mysql.user SET password = PASSWORD('123456')WHERE user = 'root'; Query OK, 3 rows affected (0.00 sec) Rows matched: 3  Changed: 3

mysql dba系统学习(6)二进制日志binlog之二

MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选:Mixed,Statement,Row,默认格式是 Statement.总结一下这三种格式日志的优缺点. MySQL Replication 复制可以是基于一条语句 (Statement Level) ,也可以是基于一条记录 (Row Level),可以在 MySQL 的配置参数中设定这个复制级别,不同复制级别的设置会影响到 Master 端的 bin-log 日志格式. 1. Row日志中会记录成每一行数据被修改

MySQL二进制日志操作

二进制日志 概念 记录对数据发生或潜在发生更改的SQL语句,并且是以二进制格式保存的日志 使用用途 查看数据库变更历史 数据库增量备份 数据库灾难恢复 MySQL复制(主从.主主复制) 二进制日志性能影响 日志即影响MySQL性能又占用大量磁盘空间.因此,往往需要做采样分析时才会打开 即使做采样分析,也最好仅在一台测试机上开启 二进制日志由于用途广泛,大多数情况下会开启.需要制定合理的备份计划和管理策略 开启二进制日志 方法一:不重启修改二进制日志配置 SET @@global.log_bin=

MySQL二进制日志优化

具体参数如下: 1.server-id=ID 服务的唯一ID 2.log_bin=/mydata/binlog/mysql-bin 二进制日志的位置和命名方式 3.binlog_format={ROW|STATEMENT|MIXD} ROW格式:记录数据更新的每一行数据的变更.当遇到alter,update整个字段的是值这样的语句,会使得二进制日志的文件庞大无比.影响了系统的IO性能.但是会保证数据的一致性. STATEMENT格式:记录的只是导致数据变更的更新语句.但是有可能导致数据不一致.

MySQL使用二进制日志恢复数据库

一.二进制日志简介 MySQL有不同类型的日志,其中二进制文件记录了所有对数据库的修改,如果数据库因为操作不当或其他原因丢失了数据,可以通过二进制文件恢复. 在my.ini文件中设置了log-bin,重新启动MySQL后就开启了二进制日志.数据库每次重新启动(或执行flush logs命令)后,都会生成一个新的二进制日志,如在在my.ini文件中设置了 log-bin=F:\mysqllog\logbin 则数据库第一次启动会生成logbin.000001,第二次启动会生成logbin.0000