MySQL数据库复制概念及数据库架构不断扩展方案

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: <p style="padding-top:0px; padding-bottom:0px; margin-top:0px; margin-bottom:0px; clear:both; height:auto; overflow:hidden; color:rgb(44,44,44); font-family:宋体,'Arial Narrow',arial,serif; font-siz

MySQL Replication

系统扩展的方式:

       scale up:向上扩展,垂直扩展    使用更高性能的硬件来扩展

       scale out:向外扩展,水平扩展    提供更多的节点来提供更多的访问需求

 

       复制:水平扩展的一种方案

 

如果构建一个httpd负载均衡集群会面临的问题:

当用户请求到达时,负载均衡器给调度到后端的各realserver上,如果web服务器允许用户上传数据,用户上传数据到第一个节点上,而后他又访问被调度到第三个节点上来,则数据就访问不到,如果要解决此问题,需要如何操作?使用共享存储,使用共享存储是块级别的共享存储还是文件级别的共享存储?文件级的为nas  块级别的为san 

文件级别在系统调用接口上通常性能比块级别低,如果是块级别前端多个节点如果同时读写同一个文件,那怎么办?会出现资源争用      出现资源争用,如何解决此问题?把集群节点都做成高可用集群,做分布式文件锁,做成集群文件系统,而做集群文件系统,多个节点同时访问同一个文件时,节点数是很有限的,集群文件系统支持到16个节点基本上是上限了。

nas  文件级别性能很差,尤其是当节点大于4时。

wKioL1UbNeaTEZa6AABUXS8za3I309.jpg

这些节点都是共享存储,最理想的方式就是在本地存储,本地存储无法共享?有两三个节点时rsync是一种解决方案,大了性能就很低了

容量和访问量都很大时,需要使用分布式文件系统,前端有一个主控节点【集中式控制节点】,后端是大量节点

也有的是无主控节点,使用比较麻烦

wKiom1UbNP2wLMg-AAB8r4XOUNY074.jpg

分布式文件系统主要用来存储非结构化数据的,那结构化数据呢?如论坛一个帖子,需要存储在数据库服务器上,通常为MySQL服务器,也即在后端需要MySQL服务器,结构化数据需要放在数据库服务器上,MySQL也面临多个节点同时访问的问题,这里是不会出现资源争用问题的,因为MySQL自身会添加锁,其智能性都在MySQL上,如果是少量节点对MySQL读写是不会产生问题的,如果很多节点时,MySQL则应付不了那么多节点的请求,

wKiom1UbNTjRDkapAAC8fa72NMg214.jpg

开始时,解决方案就是向上进行扩展,由于向上扩展很容易达到极限

wKioL1UbNqWh_HSRAADVuKroZlQ219.jpg

因此需要进行水平扩展,多台MySQL服务器,数据如何存放?MySQL服务器后台用共享存储?在什么级别共享?  nas   san?如果使用nas时,会出现资源争用,是解决不了此种情况的,此时就需要使用到MySQL复制功能(主从复制),所有前端节点的更新请求在主节点山,从节点在主节点上把数据复制一份,放在当前节点上,因此从节点和主节点都有一模一样的数据,前端读请求在从服务器上,主节点可读可写,从节点只能读,复制是单方向的,从主到从节点,

wKiom1UbNcCj34_QAADdzYsAMPU682.jpg

可以有多个读节点,在多个读节点上,则需要实现负载均衡,读请求实现负载均衡存在缺陷,MySQL本地有查询缓存,同一条语句发起的请求会负载在另外一个位置上,因此缓存就不能命中了,如果说后端有多个具有缓存能力的节点,这些节点缓存数据不一定相同,则需要提供解决方案来解决缓存命中率,有两种解决方案:

1.1在前端自己做负载均衡,也即在程序中如果请求语句是同一个服务器,则其将重复发到同一个节点上,根据语句做均衡,如何操作?  做取余法,每一个语句在向后端发起查询请求时,如何挑选?在应用程序中对查询语句做hash计算,取得其校验码,取得校验码后对服务器个数做取模计算,同一个数据的特征码是一样的,特征码一样取模结果就一定相同,此时,同一条语句会始终发送到同一个服务器。但是此种情况会存在一个问题了,当要添加和删除服务器时会导致所有缓存都命中不到了。

1.2解决上面方案的方法,使用一致性hash算法,把每一个节点的服务器都计算其hash码,对2^23取模,把0-2^32的数字均匀的分布到一个环上,把服务器分散到环上,每一个查询语句用hash计算后对2^32取模,取模后一定会落到环上,查询就是落到节点按顺时针到离他最近的节点,如果某节点坏了,则只影响部分缓存,

wKioL1UbNzXBPFejAAEj2ATqFe4747.jpg

存在的问题:一致性hash有可能是偏斜的,也即各节点分布不均衡,导致压力不同

wKiom1UbNiux99dNAABTR3aLj5A189.jpg那如何解决此种文件,需要改进一下计算每一个

节点所在位置的hash所落在位置,此改进需要设置虚拟节点算法,把每一个节点通过用算法计算多次,也即一个节点可以在环上落n次,每一个节点都做单独计算

wKioL1UbN6GBwxKdAAC8KBWPFfw075.jpg

此时缓存命中就得到大的提升

 

       缓存命中:

              应用程序:(两种方法)

                     除模

                     一致性哈希

此时,缓存对程序的依赖还是很大的,如何减少耦合性,减少依赖,添加中间层,中间层可以理解MySQL语句,MySQL的反向代理,无论谁发来请求时,此节点知道到对应的位置做查询操作,知道操作是读还是写,能实现智能的将写请求发给主节点,读请求负载均衡到多个从节点,此节点叫MySQL代理(读写分离器)

 

              读写分离器:

                     语句路由  核心功能MySQL的语句路由

wKiom1UbNpXDi4AiAADRzUAp5tI721.jpg

制的功用:

              负载均衡    将读写分开,读到多个节点

              数据分布         数据分开到多个节点,避免带宽压力过大

              备份                   每一个节点数据是一样的

              高可用性         从服务器可以出现宕机

              MySQL升级测试  

 

       复制架构的问题:

              1、主节点是单点故障所在

              2、写操作无法有效均衡   写操作过多时,无法均衡


 

对写操作做负载均衡,此时数据必须切开,将关联性不是很大的表分开存储,切开后每一个服务器都要各自复制,垂直切分   切割后存在的问题,数据有热点     有些热点集中在一个表上   再横向切割,按id进行切割  1-10W   10W-30W 。。。在不同的节点上,那切割后如何进行查询呢?读请求出现压力过大了,把数据库服务器节点找一个路由器实现统一路由,数据库如何进行切片?前端找一个节点,切的时候根据某个字段来切,

切割时把握的两个原则,读尽可能集中在有限节点或几个节点上,读节点越少越好,写节点越多越好,分担写

wKioL1UbOAXzgvn6AADdtFVQNc4174.jpg

wKioL1UbODPCMhgDAAGU6w-fvzM190.jpg

数据库扩展的思路两个:

              复制、切片

 

       MySQL复制的工作原理:

以两个节点为例:

MySQL日志类型:查询日志、慢查询日志、错误日志、二进制日志、事务日志、中继日志等

       二进制日志的格式:记录的是能够引起数据库中的数据发生改变或者潜在影响其改变的那些语句     格式有三种:

              语句: statement  基于语句来记录,能记录的数据量很小,存在的问题,如:记录使用某个函数生成的时间,在另外一个服务器上执行以后时间一定是不同的

              : row  能够提供精确数据,存在的问题如:发工资,每个人月薪加3000,基于语句时,一条update语句即可,基于行时,有很多人就要记录很多人的数据

              混合:mixed   MySQL自行智能决定

复制就是在从服务器上把主服务器上的二进制日志复制到本地重新走一遍,如何走?从服务器把自身认为是MySQL的客户端去连接主服务器,连到主服务器后不是做任何的查询操作,而是请求MySQL进程读其二进制日志,主服务器会启动一个dump线程,dump线程会从文件读取一个事件发送一个事件,从服务器接收到事件后,先把数据存下来,存取下来的文件叫中继日志,存下来以后,MySQL会启动一个线程sql ,此线程会从文件中读取语句并执行,

主服务器上启用二进制日志,启动的线程是dump线程,而在从服务器上有两个线程,

io线程和sql线程。io线程负责请求MySQL服务器,MySQL服务器会在必要时,有事件产生,会启动dump线程,在里面读取数据后,发送给从服务器,从服务器发给io线程,io线程读取后,保存在本地的中继日志中,sql线程从中继日志中读语句执行。从服务器读取后是否会产生二进制日志?从服务器上也会产生二进制日志(一般从服务器会关闭二进制日志功能),

wKiom1UbNyzgyjf6AACyEAby4aQ546.jpg

复制有三个步骤:

              1、在主库上启用二进制日志;

              2、备库从主库复制二进制日志,并保存至本地的中继日志中;

              3、备库从中继日志中读取事件并于本地执行一次;

在二进制日志中每一个日志事件会保存生成这个二进制日志的服务器的id号,在复制中,每一个服务器都有其唯一的一个id号。其id号有什么作用呢?避免造成环形复制。

       MySQL复制支持双主模型:

              master/master    都能写都能读

每一次本地请求都会记录到二进制日志中,而每一个节点同时作为对方的从节点,此时存在问题,会出现无限循环,如何解决此问题?给每一个服务器都记录好server-id,在哪个服务器上产生的,真正应用时,只应用id号为非本机日志事件,所以每一个服务器必须有存在一个唯一的id

wKiom1UbN1myVY9BAADLn6yZk8E786.jpg

主主复制时,负载均衡就不存在了,因为本地不写也要从对方复制过来进行写操作,只起到高可用的作用。

 

              主主复制问题:

                     1、自动增长的ID字段:解决:一端是偶数  一端是奇数

                            各自使用不同的数值:偶数或奇数

                     2、一张表中有:

                            年龄  工资  两个字段,在第一个主节点上,执行了根据年龄修改工资,在第二个节点上执行了根据工资修改年龄

                            大于40岁,工资+1000

                            所有工资为3000以下的,-2  年龄减2

 

                            加入用户年龄41岁,工资2800   则结果为什么?

                            413800  左节点

                            392800  右节点

此时就会对结果产生影响了

                     第三方项目:mmm: multi master mysql   多主MySQL,大量perl脚本

                                 mha: mysql ha

 

              MySQL复制:是异步进行   不建议使用双主模型

       复制总结:

             master:启用二进制日志,有惟一的server-id

                    binlogdump: 将从服务的io thread发出读取二进制日志事件的请求对应的数据发送给对方

             slave:启用中继日志,并闭二进制日志(建议),有惟一的server-id

                    IOthread:向master请求二进制日志中的事件

                    SQLthread:从中继日志中读取事件并在本地执行

复制工作架构:

             从服务器:有且只能有一个主服务器,避免从服务器混乱;

                    MariaDB10:支持多源复制,即支持多个主服务器;

             主服务器:可以有多从

             可否多级复制?  可以,中间从服务器需要启用二进制日志功能

 

             异步:存在的问题从服务器的数据可能会落后于主服务器

 

      提高缓存命中率的解决思路:

             1、在程序中的解决:

                    取模

                    一致性哈希

             2、使用公共缓存

                    memcached(引入的问题:一个服务器扛不住,做负载均衡,又存在缓存问题,又要使用到  取模   一致性hash)【只要是缓存服务器都会存在这样的问题】

wKioL1UbOMjwT75WAAESAfSvdiA191.jpg

参考:

http://wdllife.blog.51cto.com/6615958/1627136


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
19天前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
91 3
Mysql高可用架构方案
|
15天前
|
SQL 存储 缓存
【赵渝强老师】MySQL的体系架构
本文介绍了MySQL的体系架构,包括Server层的7个主要组件(Connectors、Connection Pool、Management Service & Utilities、SQL Interface、Parser、Optimizer、Query Caches & Buffers)及其作用,以及存储引擎层的支持情况,重点介绍了InnoDB存储引擎。文中还提供了相关图片和视频讲解。
【赵渝强老师】MySQL的体系架构
|
14天前
|
SQL 关系型数据库 MySQL
12 PHP配置数据库MySQL
路老师分享了PHP操作MySQL数据库的方法,包括安装并连接MySQL服务器、选择数据库、执行SQL语句(如插入、更新、删除和查询),以及将结果集返回到数组。通过具体示例代码,详细介绍了每一步的操作流程,帮助读者快速入门PHP与MySQL的交互。
29 1
|
16天前
|
SQL 关系型数据库 MySQL
go语言数据库中mysql驱动安装
【11月更文挑战第2天】
30 4
|
20天前
|
监控 前端开发 JavaScript
探索微前端架构:构建可扩展的现代Web应用
【10月更文挑战第29天】本文探讨了微前端架构的核心概念、优势及实施策略,通过将大型前端应用拆分为多个独立的微应用,提高开发效率、增强可维护性,并支持灵活的技术选型。实际案例包括Spotify和Zalando的成功应用。
|
23天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
116 1
|
11天前
|
运维 关系型数据库 MySQL
安装MySQL8数据库
本文介绍了MySQL的不同版本及其特点,并详细描述了如何通过Yum源安装MySQL 8.4社区版,包括配置Yum源、安装MySQL、启动服务、设置开机自启动、修改root用户密码以及设置远程登录等步骤。最后还提供了测试连接的方法。适用于初学者和运维人员。
104 0
|
22天前
|
机器学习/深度学习 人工智能 自然语言处理
Tokenformer:基于参数标记化的高效可扩展Transformer架构
本文是对发表于arXiv的论文 "TOKENFORMER: RETHINKING TRANSFORMER SCALING WITH TOKENIZED MODEL PARAMETERS" 的深入解读与扩展分析。主要探讨了一种革新性的Transformer架构设计方案,该方案通过参数标记化实现了模型的高效扩展和计算优化。
84 0
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
11天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
下一篇
无影云桌面