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

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

mysql高可用架构特点
1.数据库故障的检测与排除
2.主从数据库的切换
3.数据的备份和保护

mysql高可用架构常用方案
1.双主 自动/手工 切换
2.Altas,opneproxy读写分离方案
3.MMM架构
4.MHA架构
5.DRDB高可用架构
6.mycat高可用分片架构
7.mysql NDB cluster集群架构
8.percona xtradb cluster(pxc)集群架构
9.mysql fabric高可用架构

mysql复制配置
同步复制步骤
1. 配置master服务器
2. 配置slave实例
3. 配置slave的复制连接到master

1.配置master服务
log-bin=/var/lib/mysql/binlog/mysql-bin.log (打开二进制文件及二进制文件的位置,注意是 是文件 不是文件夹 mysql-bin是二进制日志的开头格式 ,注意binlog目录对mysql用户的权限)
server-id=108 (服务器唯一标识,必须设置,如果没设置,可通过 进入mysql 后 show binlog events in ‘mysql-bin.000001‘; 查看)

mysql> show binlog events in ‘mysql-bin.000001‘;
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                  |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| mysql-bin.000001 |   4 | Format_desc |         1 |         120 | Server ver: 5.6.35-log, Binlog ver: 4 |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+

设置完重启mysql服务

mysql> show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       143 |
| mysql-bin.000002 |       120 |
+------------------+-----------+
mysql> show binlog events in  ‘mysql-bin.000002‘;
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                  |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| mysql-bin.000002 |   4 | Format_desc |       108 |         120 | Server ver: 5.6.35-log, Binlog ver: 4 |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      120 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

master的/etc/my.cnf 示例

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-bin=/var/lib/mysql/binlog/mysql-bin.log
server-id=108
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
explicit_defaults_for_timestamp=true

2.从库的配置 my.cnf里

 server-id=251

开启从库进程
start slave ;
如果有警告
show warnings;

3.配置slave连接到master的复制

在主库上创建一个复制权限的账号

grant replication slave on  *.* to [email protected]‘%‘ identified  by ‘rep123456‘;
flush privileges;

在从服务器mysql里执行

change master
   to master_host=‘192.168.1.250‘,
     master_port=3306,
     master_user=‘rep‘,
     master_password=‘rep123456‘,
     master_log_file=‘mysql-bin.000003‘,
     master_log_pos=106;

master_log_file 表示从哪个二进制文件开始,master_log_pos 表示从哪个位置开始

比如我做测试的主库是 192.168.1.250 从库是192.168.1.251

查看从库状态

show slave status\G

  Slave_IO_State:
                  Master_Host: 192.168.1.250
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 106
               Relay_Log_File: mysqld-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: No
            Slave_SQL_Running: No
              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: 106
              Relay_Log_Space: 106
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:

主要参数

Slave_IO_Running: No
Slave_SQL_Running: No

开启从库进程
start slave ;

show slave status\G

这时 :

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

表示配置成功了,在主库相应表里插入数据,从库也会有!

时间: 2024-11-17 19:46:53

mysql复制(高可用架构方案的基础)的相关文章

15、 Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节

15. Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节 参考自:http://oldboy.blog.51cto.com/2561410/1240412 heartbeat和keepalived应用场景及区别 很多网友说为什么不使用keepalived而使用长期不更新的heartbeat,下面说一下它们之间的应用场景及区别: 1.对于web,db,负载均衡(lvs,haproxy,nginx)等,heartbeat和keepalived都可以实现 2.lvs最好和keepa

MySQL数据库的优化(下)MySQL数据库的高可用架构方案

MySQL数据库的优化(下)MySQL数据库的高可用架构方案 2011-03-09 08:53 抚琴煮酒 51CTO 字号:T | T 在上一篇MySQL数据库的优化中,我们跟随笔者学习了单机MySQL数据库的优化,今天我们继续跟随笔者学习MySQL优化的集群方案. AD:51CTO 网+首届APP创新评选大赛火热启动——超百万资源等你拿! [51CTO独家特稿]在上一篇MySQL数据库的优化中,我们跟随笔者学习了单机MySQL数据库的优化,今天我们继续跟随笔者学习MySQL优化的集群方案. M

Oracle Compute云快速搭建MySQL Keepalived高可用架构

最近有个客户在测试Oracle Compute云,他们的应用需要使用MySQL数据库,由于是企业级应用一定要考虑高可用架构,因此有需求要在Oracle Compute云上搭建MySQL高可用集群.客户根据自身的技术储备想要使用Keepalived组件来配合MySQL实现.今天结合Oracle Compute刚刚宣布terraform支持的架构即代码方式,交付给客户一个快速搭建MySQL+Keepalived高可用架构,来帮助他们快速搭建测试环境甚至将来使用到正式环境. MySQL主主复制模式 M

mysql高可用架构方案之一(keepalived+主主双活)

Mysql双主双活+keepalived实现高可用 目录 1.前言... 4 2.方案... 4 2.1.环境及软件... 4 2.2.IP规划... 4 2.3.架构图... 4 3.安装设置MYSQL半同步... 5 4.Keepalived实现MYSQL的高可用... 11 1.前言 最近研究了下高可用的东西,这里总结一下mysql主主双活的架构方案,整体上提高服务的高可用性,出现问题也不需要手动切换,提高整体的维护效率.确定改造的话,只需要让他们的程序中使用vip地址就可以,实现起来比较

MySQL之高可用架构—MHA

MySQL高可用目前有heartbeat+drbd.MHA.MySQL复制等几种较成熟的方案,heartbeat+drbd的方案可扩展性较差,而且读写都由主服务器负责,从库并不提供读功能,适合于数据增长量不大.一致性要求很高的环境,如银行.金融业等.今天重点讲下MHA的高可用架构. MHA是一款优秀的高可用环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到0-30秒之内自动完成数据库的故障切换,并且在切换的过程中,最大限度的保证数据的一致性,以达到真正意义上的高可用.

企业中MySQL主流高可用架构实战三部曲之MHA

老张最近两天有些忙,一些老铁一直问,啥时更新博文,我可能做不到天天更新啊,但保证以后一有空就写一些干货知识分享给大家. 我们如果想要做好技术这项工作,一定要做到理论与实践先结合.我一个曾经被数据库虐得体无完肤的过来人给大家一些建议:就是只看书,背理论真的行不通,到时遇到棘手的问题,你还是一样抓瞎.一定要在理论理清的基础上多做实验. 给自己定个目标,3个月做够100-500个实验.然后整理在做实验过程中的各种报错,认真解读分析报错原理,做好笔记.最后再拿起书,重新阅读之前有些可能理解不了的理论知识

mysql实现高可用架构之MHA

一.简介 MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供了 automating master failover 功能.MHA 在监控到 master 节点故障时,会提升其中拥有最新数据的 slave 节点成为新的master 节点,在此期间,MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题.MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点. MHA 是由日本人 yoshinorim

mysql数据库高可用架构-----MHA-0.56的详解

大家都知道,任何线上环境,都必须搭载高可用架构,是web的,也要是数据库的,严格来说更是整个架构的高可用. mysql作为时下比较热的数据库,高可用架构更加需求大.不过,以前老旧那一套已经不合时宜,现在用的比较多的就是MHA和PXC了. PXC的优势是做到同写同回滚,达到数据高度一致性,通过一些程序和代码来做第三方分发,可以做到一定程度的读写分离,是个相当不错的高可用解决方案,不过对网络要求比较高,配置也略复杂一些,最好是同一个机房里面做,不过这并不是本文重点,后面找时间再写相关的文章. 本文要

mysql高可用架构方案之二(keepalived+lvs+读写分离+负载均衡)

mysql主从复制与lvs+keepalived实现负载高可用 目录 1.前言    4 2.原理    4 2.1.概要介绍    4 2.2.工作原理    4 2.3.实际作用    4 3方案    4 3.1.环境    4 3.2.架构图    5 3.3.设计原理    6 4.相关软件安装    6 4.配置mysql的主从    7 5.通过lvs+keepalived实现负载与热备,并实现读写分离    8 1.前言 最近研究了下高可用的东西,这里总结一下mysql主从复制读