淘宝券商城网站制作广西网站制作

当前位置： 首页 > news >正文

淘宝券商城网站制作,广西网站制作,网站临时域名,江北网站建设的技术主从复制

1. 主从复制概述 1.1 如何提升数据库并发能力 一般应用对数据库而言都是“读多写少”#xff0c;也就说对数据库读取数据的压力比较大#xff0c;有一个思路就是采用数据库集群的方案#xff0c;做主从架构、进行读写分离#xff0c;这样同样可以提升数据库的并…主从复制
2. 主从复制概述 1.1 如何提升数据库并发能力 一般应用对数据库而言都是“读多写少”也就说对数据库读取数据的压力比较大有一个思路就是采用数据库集群的方案做主从架构、进行读写分离这样同样可以提升数据库的并发处理能力。但并不是所有的应用都需要对数据库进行主从架构的设置毕竟设置架构本身是有成本的。 如果我们的目的在于提升数据库高并发访问的效率那么首先考虑的是如何优化SQL和索引这种方式简单有效其次才是采用缓存的策略比如使用 Redis将热点数据保存在内存数据库中提升读取的效率最后才是对数据库采用主从架构进行读写分离。 1.2 主从复制的作用 第1个作用读写分离。 第2个作用就是数据备份。 第3个作用是具有高可用性。
3. 主从复制的原理 2.1 原理剖析 三个线程 实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中会基于3 个线程来操作一个主库线程两个从库线程。 二进制日志转储线程Binlog dump thread是一个主库线程。当从库线程连接的时候 主库可以将二进制日志发送给从库当主库读取事件Event的时候会在 Binlog 上加锁读取完成之后再将锁释放掉。 从库 I/O 线程会连接到主库向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分并且拷贝到本地的中继日志 Relay log。 从库 SQL 线程会读取从库中的中继日志并且执行日志中的事件将从库中的数据与主库保持同步。 复制三步骤 步骤1Master将写操作记录到二进制日志binlog。 步骤2Slave将Master的binary log events拷贝到它的中继日志relay log 步骤3Slave重做中继日志中的事件将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的而且重启后从接入点开始复制。 复制的问题 复制的最大问题延时 2.2 复制的基本原则 每个Slave只有一个Master 每个Slave只能有一个唯一的服务器ID 每个Master可以有多个Slave
   
4. 同步数据一致性问题 主从同步的要求 读库和写库的数据一致(最终一致) 写数据必须写到写库 读数据必须到读库(不一定)
   3.1 理解主从延迟问题 进行主从同步的内容是二进制日志它是一个文件在进行网络传输的过程中就一定会存在主从延迟比如 500ms这样就可能造成用户在从库上读取的数据不是最新的数据也就是主从同步中的数据不一致性问题。 3.2 主从延迟问题原因 在网络正常的时候日志从主库传给从库所需的时间是很短的即T2-T1的值是非常小的。即网络正常情况下主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。 主备延迟最直接的表现是从库消费中继日志relay log的速度比主库生产binlog的速度要慢。造成原因 1、从库的机器性能比主库要差 2、从库的压力大 3、大事务的执行 3.3 如何减少主从延迟 若想要减少主从延迟的时间可以采取下面的办法 降低多线程大事务并发的概率优化业务逻辑 优化SQL避免慢SQL减少批量操作建议写脚本以update-sleep这样的形式完成。 提高从库机器的配置减少主库写binlog和从库读binlog的效率差。 尽量采用短的链路也就是主库和从库服务器的距离尽量要短提升端口带宽减少binlog传输的网络延时。 实时性要求的业务读强制走主库从库只做灾备备份。
   3.4 如何解决一致性问题 读写分离情况下解决主从同步中数据不一致的问题 就是解决主从之间 数据复制方式 的问题如果按照数据一致性 从弱到强 来进行划分有以下 3 种复制方式。 方法 1异步复制 ​ MVSQL默认的复制方式在异步复制的方式中主库在执行完事务操作以后会立刻给客户端返回。他不需要关心从库是否完成该事务的执行。 ​ 这种方式会导致一个问题那就是当主库出现故障时主库虽然事务执行完了但是可能还没来得及把数据同步给从库就挂了。那么当从库升级为主库之后他会丢失了这次事务的变更内容。 方法 2半同步复制 ​ 半同步复制是介于全同步复制和异步复制之间的一种方案。他再执行完一个事务之后也不会立刻给客户端反馈但是也不会等所有从库都完成事务而是等其中一个从库完成接收到事件之后再反馈给客户端。 在半同步复制这个方案中会在事务提交的2阶段都完成之后等待从库接收到binlog然后再返回成功。 方法 3组复制 ​ 首先我们将多个节点共同组成一个复制组在执行读写RW事务的时候需要通过一致性协议层Consensus 层的同意也就是读写事务想要进行提交必须要经过组里“大多数人”对应 Node 节点的同意大多数指的是同意的节点数量需要大于 N/21这样才可以进行提交而不是原发起方一个说了算。而针对只读RO事务则不需要经过组内同意直接 COMMIT 即可。 方法 4全同步复制 ​ 全同步复制的这个方式中当主库执行完一个事务之后他会等待所有的从库完成数据复制之后才会给客户端反馈。这种方式安全性可以保障了但是性能很差。如果从库比较多的话会导致整个过程更加长。 4、主从复制-搭建流程 4.1 环境准备 一主一从默认安装好了MySQL了需要安装可以参考 节点ip数据库角色节点1192.168.3.131Mysql主j节点节点2192.168.3.137Mysql从节点 4.2 主节点配置 主节点需要做的工作就是创建用户并赋予权限然后开启binlog日志。 首先创建给从节点登录用的账号和密码如下 #查看主节点的登录名账号,没有用于从节点登录的账号密码 select Host,User from user; create user slave01192.168.3.137 identified by 123456; select Host,User from user;授予从节点登录主节点验证的权限 由于MySQL的版本问题我这个是8.0版本的在授权语句后面加上identified by 123456会报错所以我此处没加 grant replication slave on . to slave01192.168.157.137;显示确认一下授予权限的情况 show grants for slave01192.168.3.137;修改mysql配置文件 vim /etc/my.cnf#主从复制配置 log-binmysql-bin server-id131 #和从节点不一样即可4.3 从节点配置 从服务器需要做的工作就是配置同步日志指定主节点的ip端口用户密码等然后启动从节点 修改mysql配置文件 #主从复制配置 log-binmysql-bin server-id137重启从节点mysql 先在主节点mysql上查看master信息 show master status;在从节点的MySQL上指定主节点信息 change master to master_host192.168.3.131,master_userslave01,master_password123456,master_log_filemaster-a-bin.000001,master_log_pos156;master_host 是主节点ipmaster_user 和 master_password 是主节点创建给从节点的账号和密码master_log_file 和master_log_pos 根据上一步查询出来的File和Position值自行更换。 启动从节点 start slave;最终这两个参数都是yes就搭建完成了但是也要注意是否有报错信息 判断是否成功主要看 Slave_IO_Running 和 Slave_SQL_Running 是否都为YES。 上面的两个yes笔者也走过很多弯路才走到的并不是一下子就成功的下面我归纳一下我搭建过程中遇到的问题 4.4 遇到报错解决 情况1Slave_IO_Running为No 由于有些同学为了方便服务器都是克隆的所以就会造成安装目录auto.cnf文件里对比server-uuid是一样的可以自行排查一下 解决办法: 首先安装目录auto.cnf文件里对比server-uuid 是否一样如果一样修改了不一样就行或者删了文件重启mysql服务。 cat /var/lib/mysql/auto.cnf保持server-uuid不一样即可 情况2Slave_IO_Running为Connecting 发生Slave_IO_Running为Connecting的情况很多大家可以参考这篇文章花开城南,这篇文章基本归纳了出现Connecting的情况但是我的遇到问题还不是这里面的 查看报错信息 发现是密码的认证方式有问题上网查了一下该博主 周杰伦的稻香的解决方法可以我采用的是第一种方法但是每次重启服务器或者MySQL服务都需要现在从服务器节点的MySQL上登录一下主节点的MySQL请求服务器公钥 mysql -u slave01 -p -h 192.168.3.131 -P3306 –get-server-public-key​ 在这种情况下服务器将RSA公钥发送给客户端后者使用它来加密密码并将结果返回给服务器。插件使用服务器端的RSA私钥解密密码并根据密码是否正确来接受或拒绝连接。 主从节点都重新停止主从复制清空之前的主从复制配置信息在从库配置change masrer to并且start slave复制可以正常启动 #主从节点都停止主从复制在两个MySQL客户端中分别执行 #清空之前的主从复制配置信息 stop slave; reset master;#从新配置主从复制 change master to master_host192.168.3.131,master_userslave01,master_password123456,master_log_filemaster-a-bin.000001,master_log_pos156;情况3Slave_IO_Running为Connecting报错could not find first log file name in binary log index file 解决方法 stop slave; reset slave; start slave;情况4主从服务器的MySQL的master状态不一致 重启过配置信息会发生变化 因为之前已经创建过主节点服务器需停掉之前的配置 再重新配置 stop slave; reset master;需要重新指定主节点服务器信息 change master to master_host192.168.3.131,master_userslave01,master_password123456,master_log_filemaster-a-bin.000002,master_log_pos156;主节点数据库备份操作 使用mysqldump命令将test数据库备份下来 mysqldump -uroot -p123456 -B test /backup/mysql_bak.\((date %F).sql.gz远程发送到从节点上 scp /backup/mysql_bak.2024-04-01.sql.gz 192.168.3.137:/backup/从库数据库还原操作 先创建数据库否则没有数据库名会报错 mysqldump -uroot -p123456 -B test /backup/mysql_bak.\)(date %F).sql.gz从库已备份到主库的数据库 4.5 主从复制测试 在主节点创建数据库名称为配置文件里需要同步的数据库名称例如 create database db_test;查看从节点已经同步 创建一个表 CREATE TABLE departments (department_id int NOT NULL DEFAULT 0,department_name varchar(30) NOT NULL,manager_id int DEFAULT NULL,location_id int DEFAULT NULL,PRIMARY KEY (department_id),UNIQUE KEY dept_id_pk (department_id),KEY dept_loc_fk (location_id),KEY dept_mgr_fk (manager_id) ) 可以看到从节点也已经同步。 插入数据 INSERT INTO departments VALUES (10, Administration, 200, 1700);可以看到数据也已经同步。