MySQL架构原理（七）集群架构和主从模式部署

最新推荐文章于 2024-08-26 17:57:40 发布
最新推荐文章于 2024-08-26 17:57:40 发布
阅读量1k 收藏 5
点赞数 1
分类专栏： MySQL 文章标签： 数据库 mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Kiven_ch/article/details/118692361
版权

目录

集群架构设计

架构设计理念

在集群架构设计时，主要遵从下面三个维度：

  • 可用性

  • 扩展性

  • 一致性

可用性设计

  • 站点高可用，冗余站点

  • 服务高可用，冗余服务

  • 数据高可用，冗余数据

保证高可用的方法是冗余。 但是数据冗余带来的问题是数据一致性问题。

实现高可用的方案有以下几种架构模式：

  • 主从模式
    简单灵活，能满足多种需求。比较主流的用法，但是写操作高可用需要自行处理。

  • 双主模式
    互为主从，有双主双写、双主单写两种方式，建议使用双主单写

  • 如何扩展以提高写性能
    分库分表

一致性设计

一致性主要考虑集群中各数据库数据同步以及同步延迟问题。可以采用的方案如下：

  • 不使用从库
    扩展读性能问题需要单独考虑，否则容易出现系统瓶颈。

  • 增加访问路由层
    可以先得到主从同步最长时间t，在数据发生修改后的t时间内，先访问主库。

主从模式

适用场景

  MySQL主从模式是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，从节点可以复制主数据库中的所有数据库，或者特定的数据库，或者特定的表。

在这里插入图片描述
mysql主从复制用途：

  • 实时灾备，用于故障切换（高可用）

  • 读写分离，提供查询服务（读扩展）

  • 数据备份，避免影响业务（高可用）

主从部署必要条件：

  • 从库服务器能连通主库

  • 主库开启binlog日志（设置log-bin参数）

  • 主从server-id不同

实现原理

主从复制

下图是主从复制的原理图。

在这里插入图片描述
主从复制整体分为以下三个步骤：

  • 主库将数据库的变更操作记录到Binlog日志文件中

  • 从库读取主库中的Binlog日志文件信息写入到从库的Relay Log中继日志中

  • 从库读取中继日志信息在从库中进行Replay,更新从库数据信息

在上述三个过程中，涉及了Master的BinlogDump Thread和Slave的I/O Thread、SQL Thread，它们的作用如下：

  • Master服务器对数据库更改操作记录在Binlog中，BinlogDump Thread接到写入请求后，读取Binlog信息推送给Slave的I/O Thread。

  • Slave的I/O Thread将读取到的Binlog信息写入到本地Relay Log中。

  • Slave的SQL Thread检测到Relay Log的变更请求，解析relay log中内容在从库上执行。

上述过程都是异步操作，俗称异步复制，存在数据延迟现象。
下图是异步复制的时序图。
在这里插入图片描述
mysql主从复制存在的问题：

  • 主库宕机后，数据可能丢失

  • 从库只有一个SQL Thread，主库写压力大，复制很可能延时

解决方法：

  • 半同步复制—解决数据丢失的问题

  • 并行复制----解决从库复制延迟的问题

半同步复制

  为了提升数据安全，MySQL让Master在某一个时间点等待Slave节点的 ACK（Acknowledgecharacter）消息，接收到ACK消息后才进行事务提交，这也是半同步复制的基础，MySQL从5.5版本开始引入了半同步复制机制来降低数据丢失的概率。

介绍半同步复制之前先快速过一下 MySQL 事务写入碰到主从复制时的完整过程，主库事务写入分为 4个步骤：

  • InnoDB Redo File Write (Prepare Write)

  • Binlog File Flush & Sync to Binlog File

  • InnoDB Redo File Commit（Commit Write）

  • Send Binlog to Slave

当Master不需要关注Slave是否接受到Binlog Event时，即为传统的主从复制。

当Master需要在第三步等待Slave返回ACK时，即为 after-commit，半同步复制（MySQL 5.5引入）。

当Master需要在第二步等待 Slave 返回 ACK 时，即为 after-sync，增强半同步（MySQL 5.7引入）。

下图是 MySQL 官方对于半同步复制的时序图，主库等待从库写入 relay log 并返回 ACK 后才进行Engine Commit。

在这里插入图片描述

并行复制

  MySQL的主从复制延迟一直是受开发者最为关注的问题之一，MySQL从5.6版本开始追加了并行复制功能，目的就是为了改善复制延迟问题，并行复制称为enhanced multi-threaded slave（简称MTS）。

  在从库中有两个线程IO Thread和SQL Thread，都是单线程模式工作，因此有了延迟问题，我们可以采用多线程机制来加强，减少从库复制延迟。（IO Thread多线程意义不大，主要指的是SQL Thread多线程）

在MySQL的5.6、5.7、8.0版本上，都是基于上述SQL Thread多线程思想，不断优化，减少复制延迟。

MySQL 5.6并行复制原理

  MySQL 5.6版本也支持所谓的并行复制，但是其并行只是基于库的。如果用户的MySQL数据库中是多个库，对于从库复制的速度的确可以有比较大的帮助。

在这里插入图片描述
  基于库的并行复制，实现相对简单，使用也相对简单些。基于库的并行复制遇到单库多表使用场景就发挥不出优势了，另外对事务并行处理的执行顺序也是个大问题。

MySQL 5.7并行复制原理

  MySQL 5.7是基于组提交的并行复制，MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave服务器的回放与master服务器是一致的，即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制。

MySQL 5.7中组提交的并行复制究竟是如何实现的？
  MySQL 5.7是通过对事务进行分组，当事务提交时，它们将在单个操作中写入到二进制日志中。如果多个事务能同时提交成功，那么它们意味着没有冲突，因此可以在Slave上并行执行，所以通过在主库上的二进制日志中添加组提交信息。

  MySQL 5.7的并行复制基于一个前提，即所有已经处于prepare阶段的事务，都是可以并行提交的。这些当然也可以在从库中并行提交，因为处理这个阶段的事务都是没有冲突的，反过来说，如果有冲突，则后来的会等已经获取资源的事务完成之后才能继续，故而不会进入prepare阶段。在一个组里提交的事务，一定不会修改同一行。这是一种新的并行复制思路，完全摆脱了原来一直致力于为了防止冲突而做的分发算法，等待策略等复杂的而又效率低下的工作。

InnoDB事务提交采用的是两阶段提交模式。一个阶段是prepare，另一个是commit。

为了兼容MySQL 5.6基于库的并行复制，5.7引入了新的变量slave-parallel-type，其可以配置的值有：

  • DATABASE（默认值，基于库的并行复制方式）

  • LOGICAL_CLOCK（基于组提交的并行复制方式）。

那么如何知道事务是否在同一组中，生成的Binlog内容如何告诉Slave哪些事务是可以并行复制的？

在MySQL 5.7版本中，其设计方式是将组提交的信息存放在GTID中。为了避免用户没有开启GTID功能（gtid_mode=OFF），MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型ANONYMOUS_GTID_LOG_EVENT。

通过mysqlbinlog工具分析binlog日志，就可以发现组提交的内部信息。
在这里插入图片描述
  可以发现MySQL 5.7二进制日志较之原来的二进制日志内容多了last_committed和sequence_number，last_committed表示事务提交的时候，上次事务提交的编号，如果事务具有相同的last_committed，表示这些事务都在一组内，可以进行并行的回放。

MySQL8.0 并行复制

  MySQL8.0 是基于write-set的并行复制。MySQL会有一个集合变量来存储事务修改的记录信息（主键哈希值），所有已经提交的事务所修改的主键值经过hash后都会与那个变量的集合进行对比，来判断改行是否与其冲突，并以此来确定依赖关系，没有冲突即可并行。这样的粒度，就到了 row级别了，此时并行的粒度更加精细，并行的速度会更快。

并行复制配置与调优

  • binlog_transaction_dependency_history_size
    用于控制集合变量的大小。

  • binlog_transaction_depandency_tracking
    用于控制binlog文件中事务之间的依赖关系，即last_committed值。

    • COMMIT_ORDERE: 基于组提交机制

    • WRITESET: 基于写集合机制

    • WRITESET_SESSION: 基于写集合，比writeset多了一个约束，同一个session中的事务 last_committed按先后顺序递增

  • transaction_write_set_extraction
    用于控制事务的检测算法，参数值为：OFF、 XXHASH64、MURMUR32

  • master_info_repository
    开启MTS功能后，务必将参数master_info_repository设置为TABLE，这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升，资源的竞争也会变大。

  • slave_parallel_workers
    若将slave_parallel_workers设置为0，则MySQL 5.7退化为原单线程复制，但将slave_parallel_workers设置为1，则SQL线程功能转化为coordinator线程，但是只有1个worker线程进行回放，也是单线程复制。然而，这两种性能却又有一些的区别，因为多了一次coordinator线程的转发，因此slave_parallel_workers=1的性能反而比0还要差。

  • slave_preserve_commit_order
    MySQL 5.7后的MTS可以实现更小粒度的并行复制，但需要将slave_parallel_type设置为LOGICAL_CLOCK，但仅仅设置为LOGICAL_CLOCK也会存在问题，因为此时在slave上应用事务的顺序是无序的，和relay log中记录的事务顺序不一样，这样数据一致性是无法保证的，为了保证事务是按照relay log中记录的顺序来回放，就需要开启参数slave_preserve_commit_order。

要开启enhanced multi-threaded slave其实很简单，只需根据如下设置：

slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
slave_pending_jobs_size_max = 2147483648
slave_preserve_commit_order=1
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

并行复制监控

在使用了MTS后，复制的监控依旧可以通过SHOW SLAVE STATUS\G，但是MySQL 5.7在performance_schema库中提供了很多元数据表，可以更详细的监控并行复制过程。

mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+---------------------------------------------+

主从模式部署安装

安装虚拟机和Centos

参考这篇博文VMware安装CentOS7超详细版

安装mysql

这里有两种安装方式

主从模式的搭建

配置主库

  • 修改master端my.cnf配置文件
    先执行systemctl stop mysqld关闭mysql服务，然后修改/etc/my.cnf配置文件添加下面的内容
    log_bin=mysql-bin
server-id=1
sync-binlog=1
binlog-ignore-db=performance_schema  # 这里是指忽略哪些库，也就是不需要同步的库，默认是全部同步
binlog-ignore-db=information_schema
binlog-ignore-db=sys

#binlog-do-db=test  #这里是指定同步哪些库
    在这里插入图片描述
  • 修改授权配置
    执行systemctl start mysqld启动mysql，然后使用客户端登录，执行下面这些命令进行远程登录的授权
    #下面两句设置password相关的参数是为了执行后面授权的时候不会因为密码太过于简单而报错，实际生产千万别这么干！！！！
set global validate_password_length=4;
set global validate_password_policy=0;

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123456';
grant replication slave on *.* to 'root'@'%' identified by '123456';
flush privileges;
    执行show master status;就能看到当前master的状态信息
    在这里插入图片描述

配置从库

  • 关闭mysql服务之后修改/etc/my.cnf配置文件
    server-id=2
relay_log=mysql-relay-bin
read_only=1
    在这里插入图片描述
  • 重新启动mysql服务，使用客户端进行登录
    执行show slave status;如果是首次搭建的从库会返回空
    在这里插入图片描述
    配置连接主库的相关信息
    change master to master_host='192.168.137.145', master_port=3306, master_user='root', master_password='123456', master_log_file='mysql-bin.000001', master_log_pos=869;
    在这里插入图片描述
    执行 start slave启动slave端
    再次执行show salve status \G
    在这里插入图片描述

测试

  • 主库插入数据
    在这里插入图片描述
  • 从库查询
    在这里插入图片描述

半同步模式搭建

主库配置

  • 查询当前数据库是否支持动态安装插件
    select @@have_dynamic_loading;
    在这里插入图片描述
  • 查看当前已经安装的插件
    show plugins;

在这里插入图片描述

  • 主库安装semi插件
    install plugin rpl_semi_sync_master soname 'semisync_master.so';
    安装完成后查看插件show variables like '%semi%';
    在这里插入图片描述
  • 主库配置semi的相关参数
    set global rpl_semi_sync_master_enabled=1;
set global rpl_semi_sync_master_timeout=1000; # 设置超时时间 单位毫秒

从库配置

  • 安装semi插件 注意这里装的是slave
    install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
  • 设置参数
    set global rpl_semi_sync_slave_enabled=1;
  • 重启slave
    stop slave;
start svale;

测试

  • 主库再次插入数据
    在这里插入图片描述
  • 从库查看
    在这里插入图片描述
  • 查看master端的日志就能看到semi相关的日志
    vim /var/log/mysqld.log

在这里插入图片描述

并行复制配置

  • 查看主库参数

    mysql> show variables like '%binlog_group%';
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    9
Current database: study

+-----------------------------------------+-------+
| Variable_name                           | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay          | 0     |  #commit提交的延迟单位毫秒
| binlog_group_commit_sync_no_delay_count | 0     |  #每组内的最大事务数
+-----------------------------------------+-------+
2 rows in set (0.06 sec)

  • 设置主库参数

    set global binlog_group_commit_sync_delay = 1000;
set global binlog_group_commit_sync_no_delay_count=100;

  • 查看从库参数

    show variables like '%slave%';
show variables like '%relay_log%';

    在这里插入图片描述
    在这里插入图片描述

  • 设置从库参数
    修改/etc/my.cnf配置文件

    slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=8
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=1

  • 重启从库服务查看参数
    在这里插入图片描述
    在这里插入图片描述

并行复制监控

在使用了MTS后，复制的监控依旧可以通过SHOW SLAVE STATUS\G，但是MySQL 5.7在performance_schema库中提供了很多元数据表，可以更详细的监控并行复制过程。

切换到 performance_schema库后可以查看

use performance_schema;

mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration           |
| replication_applier_status                  |
| replication_applier_status_by_coordinator   |
| replication_applier_status_by_worker        |
| replication_connection_configuration        |
| replication_connection_status               |
| replication_group_member_stats              |
| replication_group_members                   |
+---------------------------------------------+
8 rows in set (0.01 sec)

通过replication_applier_status_by_worker可以看到worker进程的工作情况：

mysql> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
|              |         1 |        28 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |        30 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |        31 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |        32 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |        33 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |        34 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |        35 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |        36 | ON            |                       |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
biu~biu~biu_
关注
专栏目录
MySQL主要技术原理和常见高可用架构
03-01
通过对MySQL的技术原理和不同高可用架构的理解，可以更好地根据具体的应用需求来设计和部署数据库系统。例如，在需要高并发读写操作的场景下，可以选择InnoDB作为存储引擎，并结合一主多从的复制架构来满足业务需求...
web项目部署架构图
热门推荐
秋语博客
11-19 3万+
为大家做了一张web项目的架构图,希望大家看了后能够对项目部署有一个清楚直观的认识. 如有任何技术疑问都可以在下方留言评论,每天将抽出部分留言进行解答 做个简单解释: 多个服务器的,被称之为集群环境,如上图的服务器A,B,C,集群环境下用户的请求将不再直接请求服务器,而是被反向代理服务器进行处理,之后根据配置进行分配,让用户的请求应该请求到那台服务器 好处主要在于减小单个服务器压力 ...
Redis专题-集群模式
weixin_43525722的博客
12-02 190
在redis持久化方式一文中，我们已经提到为了防止数据丢失，redis提供了RDB和AOF两种方式持久化数据，将内存的数据持久化到磁盘上。但是当出现服务器出现故障，比如服务磁盘坏掉导致数据不可恢复时。那又该怎么办呢？这时候就需要进行数据备份，将数据存储在多台服务器上。我们在面试的时候也经常会遇到redis的相关面试题，对于redis有几种集群模式这个问题在面试中出现的频率还是很高的，或者会问你在你的项目中使用redis的部署方式是什么，这些都是在考察你对redis的集群模式的了解。可能有的伙伴还不是很清楚，
MySQL集群技术详解
最新发布
D2961953033的博客
08-26 1301
MHA）是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。MHA的出现就是解决MySQL单点的问题。MySQL故障切换过程中，MHA能做到0-30秒内自动完成故障切换操作。MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用。
LAMP架构之mysql：MySQL的主从架构
weixin_44717560的博客
01-20 2236
MySQL的主从架构一、从节点(server2)安装mysql服务二、mysql主从架构的搭建三、mysql一主多从架构 一、从节点(server2)安装mysql服务 为了节省时间，可以直接把主节点（server1）上的文件复制到从节点（server2） 同样的，在server2上，要保持与配置文件相同的条件： 初始化： 结束，准备了两个数据库： 二、mysql主从架构的搭建 可以参考官网： （1）主节点端 在做主从复制的时候，要保证所有节点的id是不一样的。 （2）从节点端 （3）
Redis分布式缓存（二）| 主从架构搭建、全量/增量同步原理、主从同步优化
慌途L
07-02 1556
Redis主从架构 1.搭建主从架构 1.1.集群结构 1.2.准备实例和配置 1.3.启动 1.4.停止 1.5.开启主从关系 1.6.测试 2.主从数据同步原理 2.1.全量同步 2.2.增量同步 2.3.repl_backlog原理 3.主从同步优化
Rocketmq - 2 集群架构模型和部署结构图
liang
08-19 5419
RocketMQ的Broker集群搭建 Master和slaver类似Redis和MySql的主从，Slaver只有读的权限，没有写的权限。 RocketMQ提供了多种的集群搭建，具体如下： 1.单个 Master 这种方式风险较大，一旦 Broker 重启或者宕机时，会导致整个服务不可用，不建议线上环境使用 2. 多 Master 模式 一个集群无 Slave，全是 Master，...
MYSQ主从集群简单搭建的部署方案
05-06
MySQL主从集群是一种常见的高可用性和负载均衡解决方案，它通过数据复制使得多个MySQL服务器之间保持数据同步，当主节点故障时，从节点可以快速接管，保证服务不中断。以下是一份关于MySQL 5.7.21主从复制集群的详细...
mysql+pxc集群部署
02-15
PXC（Percona XtraDB Cluster）是一套高可用集群解决方案，旨在解决传统基于主从复制模式的集群架构中的数据复制延迟问题。PXC 的最大优势在于其强的一致性和无同步延迟的特点。 PXC 的主要特性和优点包括： * ...
mysql主从架构图_mysql主从架构, 以及双主模型的实现
weixin_35133198的博客
02-08 432
主节点 172.16.26.1[root@localhost mysql]# mkdir /mydata/{bindata,data} –pv/etc/mysql/my.cnf =>修改主配置文件datadir = /mydata/datalog-bin=/mydata/bindata/mysql1-bin => 二进制文件另找位置存放备节点 172.16.26.5[ro...
MySQL：为什么要搭建一套MySQL主从架构
OceanStar的博客
12-26 1115
MySQL主从架构作用 在MySQL真正的生产环境中，他一定不是一个单机版的架构，因为单机版的MySQL一般仅能用于本地开发环境和测试环境，是绝对不可能运用于生产环境的。 实际生成环境中，MySQL必须搭建一套主从复制的架构，同时基于一些工具实现高可用架构，另外如果有需求，还需要基于一些中间件实现读写分离架构，最后如果数据量大，还必须实现分库分表架构。 MySQL的主从复制架构，这个主从复制架构，顾名思服务器，每台服务器上都得有一个MySQL，其中一个MySQL是master（主节点），另外一个MySQL是
Mysql主从架构图
hubing的博客
09-30 852
mysql 主主同步架构图_MySQL所有的主从同步架构搭建方式
weixin_42347048的博客
01-19 431
一.前言​本文将指导搭建所有的MySQL主从同步架构方案：​一主多从架构​主主双向同步架构​M-S-S三级级联同步架构​多主多从架构二.关于MySQL主从同步​MySQL主从同步是构建大型，高性能应用的基础，MySQL主从同步可以实现在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力(主库写，从库读，降压),在从主服务器进行备份，避免备份期间影响主服务器服务(确保数据安全),当主服...
mysql主从架构图_MySQL主从架构
weixin_34524593的博客
01-28 628
MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后，在A上写数据，另外一台B也会跟着写数据，两者数据实时同步的。它基于binlog，主设备上须开启binlog才能进行主从。主从过程大致有3个步骤：1)主设备将更改操作记录到binlog里；2)从将主设备的binlog事件(sql语句)同步到从本机上并记录在relaylog里；3)从根据relaylog里面的sql...
MySQL8 双主(主主)架构部署实战
低调，谦虚，自律，反思，成长，保持热爱，奔赴梦想
03-18 3679
一文带你学会MySQL8双主架构实战
mysql主从架构图_推荐10个mysql主从架构
weixin_35144564的博客
02-02 395
最近在部署MySQL主从复制架构的时候，碰到了"Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work." 这个错误提示。即...
MySQL binlog_transaction_dependency_tracking=commit_order和slave_preserve_commit_order的区别
灯火觅阑珊
11-12 5577
binlog_transaction_dependency_tracking是设在主库，可以取commit_order,writeset,writeset_session，主要是控制binlog文件中last_committed的计算方式： commit_order即group commit，同在prepare阶段的事务，在binlog中last_committed数值一样，传到从库之后可以并行执...
mysql5.7--多线程并行参数
j_ychen的博客
11-02 1809
为了解决主从复制延迟问题，在MySQL 5.7中，引入了基于组提交的并行复制（Enhanced Multi-threaded Slaves） 主要由以下参数控制， slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=8 slave_preserve_commit_order=on master_info_repository=TABLE sync-master-info=1 relay_log_info_repository=TAB
MySQL分布式集群架构教程：主从复制与高可用实践
"mysql分布式集群架构视频，通过60多集的内容深入讲解了MySQL在Linux环境下的安装、主从复制、主主复制、负载均衡、HAProxy监控、高可用性、Keepalived、分库分表以及数据库中间件Mycat的使用等关键知识点。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值