温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

MySQL数据库⾼可⽤HA怎么实现

发布时间:2022-01-24 09:36:02 来源:亿速云 阅读:157 作者:小新 栏目:开发技术

小编给大家分享一下MySQL数据库⾼可⽤HA怎么实现,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!

    MySQL数据库⾼可⽤HA实现

    1、 数据库⾼可⽤分析

    ⾼可⽤的衡量标准
    数据库实现⾼可⽤的⼏种⽅式
    MySQL数据库实现⾼可⽤

    2、MySQL主从复制的容灾处理

    MySQL⽀持的复制⽅式分析
    主从场景切换⽅式
    主从结构如何实现容灾

    1. 什么是数据库⾼可⽤

    1.1. 什么是⾼可⽤集群

    N+1:N就是集群,1就是⾼可⽤,⾼可⽤的核⼼就是冗余,集群是保证服务最低使⽤标准的

    1.2. ⾼可⽤集群的衡量标准

    ⼀般是通过系统的可靠性和可维护性来衡量的
    MTTF:平均⽆故障时间,这是衡量可靠性的
    MTTR:衡量系统的可维护性的
    HA=MTTF/(MTTF+MTTR)*100%
    SLA:99.999%:表示⼀年故障时间/宕机时间不超过6分钟

    1.3. 实现⾼可⽤的三种⽅式

    主从⽅式(⾮对称)
        这种⽅式的组织形式通常都是通过两个节点和⼀个或多个服务器,其中⼀台作为主节点
    (active),另⼀台作为备份节点(standy),备份节点应该随时都在检测主节点的健康状况,当
        主节点发⽣故障,服务会⾃动切换到备份节点保障服务正常运⾏
    对称⽅式
        两个节点,都运⾏着不同的服务且相互备份,相互检测对⽅的健康,当任意⼀个节点发⽣故障,这
        个节点上的服务就会⾃动切换到另⼀节点
    多机⽅式
        包含多个节点多个服务,每个节点都要备份运⾏不同的服务,出现问题⾃动迁移

    1.4. MySQL数据的⾼可⽤实现

    1.4.1. 主从⽅式(⾮对称)

    资源:两台同版本的MySQL数据库
    主从实现的内部运⾏原理和机制
        First Step:主数据库服务器会把数据的修改记录记录进binlog⽇志,binlog⼀定要打开
        Second Step:从库的I/O进⾏读取主库的binlog内容后存⼊⾃⼰的Relay Log中继⽇志中,这
        个I/O线程会和主库建⽴⼀个普通的客户端连接,然后主库启动⼀个⼆进制转储线程,I/O线
        程通过转储线程读取binlog更新事件,同步完毕后I/O进⼊sleep,有新的更新会再唤醒
                Relay Log和Binlog的格式是⼀样的,可以⽤mysqlbinlog读取,也可show
                mysql> show relaylog events in 'relay-log.000001';
                ⽬前数据库有两种复制⽅式
                        binlog⽇志点position
                        GTID⽅式也要依赖binlog
        第三步:从服务器的SQL进程会从Relay Log中读取事件并在从库中重放
                从服务器执⾏重放操作时是可以在配置⾥声明是否写⼊服务器的binlog⽇志中

    MySQL数据库⾼可⽤HA怎么实现

    1.4.2. 配置主从服务步骤
    1.4.2.1. Binlog的⽇志点⽅式配置主从同步

    配置主从服务器参数
    在Master服务器上创建⽤于复制并授权的数据库账号
    备份Master数据库并初始化Slave服务器数据
    启动复制链路

    Master服务器配置

    chown -R mysql:mysql /usr/local/binlog/
    #配置⽂件
    server_id=163
    log_bin=/usr/local/binlog/mysql-bin
    12345

    Slave服务器配置

    server_id=196
    log_bin=/usr/local/binlog/mysql-bin
    relay_log=/usr/local/relaylog/relay-bin
    #当slave宕机后,如果relay log损坏了,导致⼀部分中继⽇志没有处理,则放弃所有未完成的,
    重新获取执⾏,保证完整性
    relay_log_recovery=1 #让从库数据只读,super⽤户,super_read_only=on
    read_only=on
    #从库的复制链路服务不会随数据库重启⽽重启,需要⼿动启动
    skip_slave_start=on
    #确保数据⼀致性,通过innoDB的崩溃恢复机制来保护哦
    master_info_repository=TABLE
    relay_log_info_repository=TABLE
    #select * from mysql.slave_master_info;
    #select * from mysql.slave_relay_log_info;

    主库授权

    mysql> use msyql;
    mysql> grant replication slave on *.* to 'syncuser'@'192.168.0.103'
    identified by '123456';
    mysql> flush privileges;
    set global validate_password_policy=LOW;
    set global validate_password_length=6;

    初始化数据

    mysqldump -uroot -p123456 --master-data=2 --single-transaction --routines -
    -triggers --events --databases mydb > mydb.sql

    创建复制链路

    mysql>
    CHANGE MASTER TO
    MASTER_HOST='192.168.0.102',
    MASTER_PORT=3306,
    MASTER_USER='syncuser',
    MASTER_PASSWORD='123456',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=8122;
    mysql> start slave;
    mysql> show slave status \G;

    从库的binlog是否写⼊?

    默认情况下是不写⼊的:因为写⼊binlog会消耗I/O,所以性能会下降,如果需要在从库上恢复数
    据就到Relay Log⾥进⾏导出处理
    直接在从库上操作更⾏语句则会写⼊binlog
    如果就是需要写⼊?在从库的my.cnf : log_slave_updates=on #开启同步并写⼊binlog
    开启同步并写⼊binlog应⽤于从到从的情况

    问题:只同步其中三个表

    #Master配置⽂件
    #不同步哪些数据库
    binlog-ignore-db=mysql
    binlog-ignore-db=test
    binlog-ignore-db=information_schema
    #同步哪些库
    binlog-do-db=game
    binlog-do-db=mydb
    
    #Slave配置⽂件
    #复制哪些数据库
    replicate-do-db=mydb
    replicate-do-db=game
    #不复制哪些数据库
    replicate-ignore-db=mysql
    replicate-ignore-db=test
    
    --replicate-wild-ignore-table=foo%.bar% 不复制使⽤表名称以开头foo且表名称以开头
    的表的更新bar

    1.4.2.1. GTID的⽅式来进⾏主从复制

    不同点
    	主从服务器的参数有不同的地⽅
    
    #在上⾯的基础上,需要给主从服务器都加上
    gtid_mode=on
    enforce_gtid_consistency=on #开启强制GTID的⼀致性确保事务		
    
    GTID下复制链路的启动
    mysql>
    CHANGE MASTER TO
    MASTER_HOST='192.168.0.102',
    MASTER_PORT=3306,
    MASTER_USER='syncuser',
    MASTER_PASSWORD='123456',
    MASTER_AUTO_POSITION=1;
    
    启动GTID后以下数据库操作不可⽤
    	create table tableName.... select
    	在⼀个事务中创建临时表
    	在⼀个transaction中更新innoDB表和myisam表

    2. 数据主从复制⽅式的容灾处理

    2.1. MySQL⽀持的复制格式

    2.1.1. 基于语句的复制(statement)

    优点:记录少,只记录执⾏语句,易懂
        缺点:insert into table1(create_time) values(now()),这个now就不是当时的时间了

    2.1.2. 基于⾏复制(row)

    优点:⼏乎没有基于⾏复制⽆法处理的场景
        缺点:数据量太⼤了

    2.1.3. 混合类型的复制(MIXED)

    mixed格式默认采⽤statement,⽐如⽤到UUID(),ROW_COUNT()

    2.1. MySQL主从复制模式

    异步复制:MySQL默认就是异步复制,性能最好,但主从复制的数据不⼀致性概率最⼤
    同步复制:当客户端发过来⼀个请求后,只有当所有的从库都写到Relay Log中,才回复给前端事
    务完成,性能最差,但⼀致性很强
    半同步复制:⾄少⼀个从库完成Relay Log写⼊后就返回事务完成给前端
    
    主从上都要安装
    mysql> install plugin rpl_semi_sync_master soname='semisync_master.so'
    rpl_semi_sync_master_enabled
    rpl_semi_sync_master_timeout #单位是毫秒,如果主库等待从库回复超过这个时间就⾃动切换
    为异步

    以上是“MySQL数据库⾼可⽤HA怎么实现”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!

    向AI问一下细节

    免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

    AI