标签：架构 log 数据库 MySQL 节点 mysql 服务器日志主从

MySQL主从架构

MySQL主从架构（Master-Slave Architecture）是一种常见的数据库高可用性和负载均衡的设计模式，通常用于提高系统的可伸缩性和可靠性。它基于数据复制（replication）机制，其中“主”服务器负责处理所有的写操作，而“从”服务器则通过复制主服务器的数据来保持数据一致性，主要用于读取操作，从而减轻主服务器的负担。

MYSQL REPLICATION的作用

1、读写分离，提供查询服务

使用主从复制，让主库负责写，从库负责读。这样，即使主库进行数据更新操作出现了锁表的情景，通过读从库也可以保证业务的正常运作。

2、实时灾备，用于故障切换。

当系统中某个节点发生故障时，可以方便的故障切换，实现高可用（HA）。例如，做数据的热备，slave作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。

3、水平扩展数据库的负载能力

随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。

MYSQL REPLICATION支持的复制类型

Statement：即基于语句的复制，会将对数据库操作的sql语句写入到binlog中，效率比较高。

row：即基于行的复制，会将每一条数据的变化写入到binlog中。

mixed：即混合模型的复制，statement与row的混合，MySQL会根据执行的SQL语句选择日志保存方式。即交替使用行和语句、由mysql服务器自行判断。

Statement-Based Replication (SBR) — 基于语句的复制

在基于语句的复制模式下，MySQL 会将执行的 SQL 语句（即查询语句）记录到 binlog 中，而不是记录数据变化本身。简单来说，主服务器记录下它执行的每个 SQL 语句，然后从服务器接收到这些 SQL 语句后再执行，从而实现数据的同步。

特点：

记录内容：记录的内容是执行的 SQL 语句，比如 INSERT、UPDATE、DELETE 等操作。
效率：这种方式通常效率较高，因为日志记录的是 SQL 语句，而不是具体的数据行。
数据同步：从服务器根据这些 SQL 语句重放操作来保持与主服务器的数据一致性。

优点：

磁盘空间小：记录的是 SQL 语句，而不是每一行数据的变化，因此相较于基于行的复制，binlog 的大小会比较小。
易于理解和调试：因为记录的是 SQL 语句，可以更容易地理解执行的操作，尤其是在故障排查时。

缺点：

不完全一致性：某些 SQL 语句在不同的环境下（例如在主从数据库的时间差异或者配置不同的情况下）可能会表现不同，导致从服务器的执行结果与主服务器不完全一致。例如，某些非确定性 SQL 语句（如 RAND()、NOW()）在主从服务器执行时可能会产生不同的结果。
复杂的语句问题：如果 SQL 语句依赖于某些特定的数据库状态（比如表的行顺序），可能会导致从服务器上执行时的行为与主服务器不一致。

Row-Based Replication (RBR) — 基于行的复制

在基于行的复制模式下，MySQL 会将每一条受影响的数据行的变化记录到 binlog 中，而不是记录执行的 SQL 语句。也就是说，每次数据发生变化时，MySQL 会记录数据的行级变化，如插入、更新或删除操作中每一行的具体变化。

特点：

记录内容：记录的是数据的变化，具体来说是被修改、插入或删除的行的内容和行的主键。
效率：这种方式相较于基于语句的复制模式来说，可能会消耗更多的存储空间，因为每次数据发生变化时，都会记录整个数据行的变动。
数据同步：从服务器会根据主服务器上记录的数据变化来重放操作，以保证数据一致性。

优点：

更高的准确性：因为记录的是每一行数据的具体变化，基于行的复制通常能更好地保证主从数据库的准确一致性，避免了基于语句复制可能引发的不一致问题。
更适用于复杂操作：对于某些复杂的查询（例如使用了非确定性函数的查询）或者批量插入数据，基于行的复制能够避免主从不一致的情况。

缺点：

磁盘空间大：记录的是每一条数据的变化，因此在数据量较大时，binlog 文件会变得很大。
性能开销：每次执行数据库操作时，都需要记录每一行的具体变化，可能会比基于语句的复制产生更多的性能开销。

例子：

假设主服务器上的某个表有以下内容：

id	name	age
1	Alice	30
2	Bob	25

假设在主服务器上执行了以下 SQL 操作：

sql


复制代码
UPDATE users SET age = 31 WHERE id = 1;

在基于行的复制模式下，binlog 会记录 受影响的行数据。例如，MySQL 会记录以下内容：

plaintext


复制代码
UPDATE users SET age = 31 WHERE id = 1;

但这条日志实际上会包含更具体的内容，像这样：

plaintext复制代码UPDATE users SET age = 31 WHERE id = 1;
Old Values: id = 1, name = Alice, age = 30
New Values: id = 1, name = Alice, age = 31

从服务器接收到这些行数据后，会执行相同的 UPDATE 操作，确保将 id=1 这一行的 age 列从 30 更新为 31。

Mixed-Based Replication (MBR) — 混合模式复制

混合模式复制是 MySQL 5.1 引入的一种新的复制方式，它结合了基于语句和基于行的复制。MySQL 会根据执行的 SQL 语句的类型自动选择使用基于语句的复制或基于行的复制。这种模式的目的是结合两者的优点，在确保数据一致性的同时尽可能减少日志文件的大小和提高效率。

特点：

自动选择：MySQL 会根据具体的 SQL 语句自动决定是使用基于语句的复制（SBR）还是基于行的复制（RBR）。通常，简单的 INSERT、UPDATE、DELETE 语句会使用基于语句的复制，而涉及到可能存在不确定性的操作（如UPDATE语句中使用了函数RAND()、NOW()等）时，则会使用基于行的复制。
灵活性：这种方式让 MySQL 在不同的场景下能够根据具体情况选择最合适的日志记录方式，力求在性能和一致性之间找到平衡。

优点：

自动选择最优日志记录方式：MySQL 自动根据不同情况选择使用哪种复制方式，使得在保证数据一致性的同时，能够优化性能。
减少空间和开销：对于可以安全地使用基于语句的复制的情况，它会选择这种方式，从而减少磁盘空间和性能开销；而对于需要更高一致性的操作，则会使用基于行的复制。

缺点：

复杂性：这种模式需要 MySQL 做更多的判断和优化，可能会增加配置和调试的复杂性。

主从复制的工作过程

1. 主服务器的操作

主服务器负责处理所有的写操作，并将这些写操作记录到二进制日志中（binary log）。这些写操作可以是插入、更新或删除操作。主服务器的主要任务是：

记录写操作。
将写操作的日志内容同步给从服务器。

主服务器的具体步骤：

执行客户端操作：当客户端在主服务器上执行写操作（如 INSERT、UPDATE、DELETE）时，这些操作会首先被写入到主服务器的二进制日志（binary log）中。
生成二进制日志事件：每个写操作都会被封装成一个二进制日志事件，并追加到主服务器的日志文件中。日志文件的格式通常为 mysql-bin.000001、mysql-bin.000002 等。
记录二进制日志位置：每次写操作都会记录当前二进制日志的文件名和位置，这些信息非常重要，用于从服务器准确定位需要复制的数据。

2. 从服务器的操作

从服务器负责从主服务器获取二进制日志，并执行相应的操作来同步数据。它会保持与主服务器的连接，读取日志文件中的操作并执行，确保数据一致性。

从服务器的具体步骤：

从主服务器获取二进制日志信息：从服务器通过 IO_THREAD 线程向主服务器发送请求，请求主服务器的二进制日志文件。

从服务器连接主服务器后，使用 CHANGE MASTER TO 语句指定主服务器的地址、复制用户、日志文件名和位置等信息。
获取二进制日志并存储：从服务器的 IO_THREAD 线程从主服务器获取二进制日志内容，并将这些日志内容写入到从服务器本地的中继日志（relay log）中。中继日志存储了从主服务器接收到的二进制日志内容。
执行中继日志中的操作：从服务器的 SQL_THREAD 线程会读取中继日志中的内容，并按照日志中的顺序执行这些操作（例如 INSERT、UPDATE、DELETE）。通过执行这些操作，从服务器的数据状态与主服务器保持一致。

3. 主从复制的实时同步

主从复制通过主服务器和从服务器之间的通信实现数据的实时同步。

详细流程：

1、主节点 binary log dump 线程

当从节点连接主节点时，主节点会创建一个binlog dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，在发送给从节点之前，锁会被释放。

2、从节点I/O线程

当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 线程发来的更新之后，保存在本地relay-log中。

3、从节点SQL线程

SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

注：对于每一个主从连接，都需要三个线程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binlog dump 线程，而每个从节点都有自己的I/O线程，SQL线程。

部署MYSQL主从同步（一主一从）

1.主库开启binlog日志

[root@server1 ~]# cat /etc/my.cnf 
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql/data
port=3306
socket=/usr/local/mysql/mysql.sock
symbolic-links=0
character-set-server=utf8
log-error=/data/mysql/log/mysqld.log
pid-file=/usr/local/mysql/mysqld.pid

log-bin=/data/mysql/log/mysql_bin
server-id=1

2.创建用户并授权

mysql> grant replication slave on *.* to 'slave'@'192.168.5.%' identified by '123456'; 
刷新生效
mysql> flush privileges;

3.从节点开启relay-log

[root@server2 ~]# cat /etc/my.cnf 
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql/data
port=3306
socket=/usr/local/mysql/mysql.sock
symbolic-links=0
character-set-server=utf8
log-error=/data/mysql/log/mysqld.log
pid-file=/usr/local/mysql/mysqld.pid
server-id=2    
relay-log=/data/mysql/log/reley_log_bin

4.从节点修改slave状态

mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> change master to master_host='192.168.5.101',master_user='slave',master_password='123456',master_log_file='mysql_bin.000001',master_log_pos=4;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| dbtest             |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

#检查同步是否成功
mysql> show slave status\G

查看mysqldump进程信息

mysql> show processlist\G
*************************** 1. row ***************************
     Id: 4
   User: slave
   Host: 192.168.5.102:55036
     db: NULL
Command: Binlog Dump
   Time: 816
  State: Master has sent all binlog to slave; waiting for more updates
   Info: NULL
*************************** 2. row ***************************
     Id: 5
   User: root
   Host: localhost
     db: dbtest
Command: Query
   Time: 0
  State: starting
   Info: show processlist
2 rows in set (0.00 sec)

#检查同步是否成功

mysql> show slave status\G

删除配置

stop slave

reset slave

部署MYSQL主主双向主从复制 M-M

1.部署好主从之后在从节点上开启binlog

vim /etc/my.cnf
log-bin=/data/mysql/log/mysql_bin

2.在从节点创建用户

mysql> grant replication slave on *.* to 'slave'@'192.168.1.%' identified by '123456'; 
刷新生效
mysql> flush privileges;

3.主库开启relaylog日志

vim /etc/my.cnf
relay-log=/data/mysql/log/reley_log_bin

4.主节点修改slave状态

mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql>  change master to master_host='192.168.5.102',master_user='slave',master_password='123456',master_log_file='mysql_bin.000001',mmaster_log_pos=600;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

部署M-S-S级联复制

级联复制时主节点修改数据库内容不会写入从节点binlog日志中而是写入relaylog日志中，所以如果在主节点修改数据库第二个从节点不会被同步

此时修改第一个从节点的配置文件

级联复制服务器
vim /etc/my.cnf
log-slave-updates=1    #表示把从主库读取的binlog日志内容也执行在本地的额binlog日志当中。

mysql读写分离 mycat

x锁和s锁

1. X锁（排它锁，Exclusive Lock）

作用：当一个事务对数据加上排它锁时，其他事务不能对该数据加任何类型的锁（包括共享锁和排它锁）。换句话说，只有持有排它锁的事务可以修改数据，其他事务只能等待。
特点：
- 允许事务对数据进行更新、删除、插入等修改操作。
- 如果一个事务持有X锁，其他事务只能等待，不能读取或修改该数据。
- 是一种严格的锁，保证了数据的独占访问，防止其他事务的干扰。
使用场景：通常用于执行数据修改操作时，确保数据在修改期间不被其他事务干扰。

2. S锁（共享锁，Shared Lock）

作用：当一个事务对数据加上共享锁时，其他事务仍然可以对该数据加共享锁，但不能加排它锁。换句话说，多个事务可以并发读取数据，但不能修改数据，直到所有共享锁被释放。
特点：
- 允许事务读取数据，但不能对数据进行修改。
- 多个事务可以同时持有同一个数据的共享锁。
- 其他事务可以继续读取数据，但不能对数据进行修改，直到共享锁释放。
使用场景：通常用于执行数据读取操作时，确保多个事务可以并发读取数据，而不会发生冲突或不一致性。

Mycat应用场景

高可用性与MySQL读写分离
利用Mycat可以轻松实现热备份，当一台服务器停机时，可以由双机或集群中的另一台服务器自动接管其业务，从而在无须人工干预的情况下，保证系统持续提供服务。这个切换动作由Mycat自动完成。

100亿大表水平分表、集群并行计算
数据切分是Mycat的核心功能，是指通过某种特定的条件，将存放在同一个数据库中的数据分散存放在多个数据库（主机）中，以达到分散单台设备负载的效果。

数据切分有两种切分模式

按照不同的表将数据切分到不同的数据库中，这种切分可以叫作数据的垂直切分。
根据表中数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多个数据库中，这种切分叫作数据的水平切分。当数据量超过800万行且需要做分片时，可以利用Mycat实现数据切分。

数据库路由器
Mycat基于MySQL 实例的连接池复用机制，可以让每个应用最大程度地共享一个MySQL实例的所有连接池，让数据库的并发访问能力大大提升。

整合多种数据源
当一个项目需要用到多种数据源如Oracle、MySQL、SQL Server、PostgreSQL时，可以利用Mycat进行整合，只需访问Mycat 这一个数据源就行。

逻辑库schema
业务开发人员通常在实际应用中并不需要知道中间件的存在，只需要关注数据库，所以数据库中间件可以被当作一个或多个数据库集群构成的逻辑库。

Mycat原理

Mycat 的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的SQL 语句

流程：
首先对 SQL 语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此 SQL 发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。

配置mycat

首先安装java环境

[root@server4 ~]# tar -zxvf jdk-8u171-linux-x64.tar.gz

配置全局环境变量/etc/profile

JAVA_HOME=/usr/local/bin/jdk1.8.0_171
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=$JAVA_HOME/jre/lib/ext:$JAVA_HOME/lib/tools.jar
export PATH JAVA_HOME CLASSPATH

解压mycat包并配置环境变量

[root@server4 /]# tar -xzvf root/Mycat-server-1.6.6.1-release-20181031195535-linux.tar.gz 
[root@server4 ~]# ln -s mycat/bin/*  /usr/local/bin/ -r

mycat的目录结构

[root@server4 ~]# ls mycat/
bin  catlet  conf  lib  logs  version.txt

bin：可执行命令
conf：配置文件
lib：存放jar包
logs：日志信息
tmlogs：临时日志
version.txt：版本信息

此时mycat配置完成

启动mycat，由于配置好了环境变量，直接启动

[root@server4 logs]# mycat start

查看 MyCat 安装包目录下的 logs/wrapper.log日志，如果没有报错，那就是启动成功了。

[root@server4 logs]# cat wrapper.log 
STATUS | wrapper  | 2024/12/23 20:53:50 | --> Wrapper Started as Daemon
STATUS | wrapper  | 2024/12/23 20:53:50 | Launching a JVM...
INFO   | jvm 1    | 2024/12/23 20:53:50 | Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=64M; support was removed in 8.0
INFO   | jvm 1    | 2024/12/23 20:53:50 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2024/12/23 20:53:50 |   Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2024/12/23 20:53:50 | 
INFO   | jvm 1    | 2024/12/23 20:53:51 | MyCAT Server startup successfully. see logs in logs/mycat.log

mycat详解

Mycat的配置文件都在conf目录里面，这里介绍几个常用的文件：

文件	说明
server.xml	Mycat的配置文件，设置账号、参数等
schema.xml	Mycat对应的物理数据库和数据库表的配置
rule.xml	Mycat分片（分库分表）规则

Mycat的架构其实很好理解，Mycat是代理，Mycat后面就是物理数据库。和Web服务器的Nginx类似。对于使用者来说，访问的都是Mycat，不会接触到后端的数据库。

mycat配置文件详解

server.xml

这个配置文件主要是用来配置mycat用户账号和授权信息

server.xml 主要用于配置 Mycat 与 外部系统 的连接和其他服务相关的设置

核心配置文件

	<user name="root" defaultAccount="true">
		<property name="password">123456</property>
		<property name="schemas">TESTDB</property>
		
		<!-- 表级 DML 权限设置 -->
		<!-- 		
		<privileges check="false">
			<schema name="TESTDB" dml="0110" >
				<table name="tb01" dml="0000"></table>
				<table name="tb02" dml="1111"></table>
			</schema>
		</privileges>		
		 -->
	</user>

	<user name="user">
		<property name="password">user</property>
		<property name="schemas">TESTDB</property>
		<property name="readOnly">true</property>
	</user>

用户配置

	<user name="root" defaultAccount="true">
		<property name="password">123456</property>
		<property name="schemas">TESTDB</property>
	</user>

	<user name="user">
		<property name="password">user</property>
		<property name="schemas">TESTDB</property>
		<property name="readOnly">true</property>
	</user>

这个配置定义了一个名为 root 的用户，并且将其设置为默认账户（defaultAccount="true"）。这意味着如果没有指定用户名，系统会默认使用 root 用户。name="root"：设置用户的名称为 root。

defaultAccount="true"：设置该用户为默认账户，如果 MyCat 无法从请求中获取用户名，系统将默认使用该账户。

123456：设置用户的密码为 123456。需要注意，实际应用中应该使用更复杂的密码，并且在生产环境中避免硬编码密码。
TESTDB：设置该用户的可访问的数据库模式为 TESTDB。这意味着该用户只能访问 TESTDB 这个数据库。

true：将此用户设置为只读用户。readOnly="true" 意味着该用户无法进行写操作（如 INSERT、UPDATE、DELETE），只能执行 SELECT 查询。

用户权限配置

<!-- 表级 DML 权限设置 -->
<!--
<privileges check="false">  ---这个开启后下面的才生效
    <schema name="TESTDB" dml="0110">
        <table name="tb01" dml="0000"></table>
        <table name="tb02" dml="1111"></table>
    </schema>
</privileges>
-->

：表示是否启用权限检查。check="false" 意味着此时权限检查被禁用，如果启用权限检查，可以改为 check="true"。
：这个配置定义了对 TESTDB 数据库模式下的 DML（数据操作语言）权限的设置。DML 权限通常是指 SELECT、INSERT、UPDATE 和 DELETE 操作。dml="0110" 是一个二进制字符串：
- 0 表示没有该权限。
- 1 表示有该权限。
所以 dml="0110" 表示该用户对 TESTDB 模式下的数据库有 SELECT 和 UPDATE 权限，但没有 INSERT 和 DELETE 权限。
：对于表 tb01，该用户没有任何 DML 权限，即不能执行 SELECT、INSERT、UPDATE 或 DELETE 操作。
：对于表 tb02，该用户有所有 DML 权限，可以执行 SELECT、INSERT、UPDATE 和 DELETE 操作。

schema.xml

schema.xml 是 Mycat 配置的核心文件之一，用于定义数据库分表、分库规则以及与数据库连接相关的各种信息。

XML 文件头部

<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">

<schema> 标签

<schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100">

name="TESTDB"：定义了一个名为 TESTDB 的数据库模式。
checkSQLschema="false"：禁用了 SQL 校验功能，通常用于分库分表场景，设置为 false 可以提升性能。
sqlMaxLimit="100"：设置 SQL 查询的最大返回记录数（就是行数）为 100，用于限制查询结果的条数。

数据节点配置 <dataNode> 标签

<dataNode name="dn1" dataHost="localhost1" database="db1" />
<dataNode name="dn2" dataHost="localhost1" database="db2" />
<dataNode name="dn3" dataHost="localhost1" database="db3" />

name="dn1"：指定数据节点的名称为 dn1。
dataHost="localhost1"：指定数据节点对应的 dataHost，表示与该数据节点关联的数据库主机。
database="db1"：指定该数据节点使用的数据库为 db1，同理 dn2 和 dn3 分别对应 db2 和 db3。

数据主机配置 <dataHost> 标签

<dataHost name="localhost1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
    <heartbeat>select user()</heartbeat>
    <writeHost host="hostM1" url="localhost:3306" user="root" password="123456">
        <readHost host="hostS2" url="192.168.1.200:3306" user="root" password="xxx" />
    </writeHost>
    <writeHost host="hostS1" url="localhost:3316" user="root" password="123456" />
</dataHost>

name="localhost1"：指定数据主机的名称为 localhost1。
maxCon="1000"：最大连接数为 1000。
minCon="10"：最小连接数为 10。 ---在系统启动或在连接池初始化时，连接池至少会保持10个连接处于打开或空闲状态。这意味着即使没有请求需要数据库连接，连接池也会保持10个连接始终可用。
balance="0"：负载均衡策略，0 表示不启用。
dbType="mysql"：数据库类型为 MySQL。
dbDriver="native"：数据库驱动类型。
writeHost 和 readHost：定义了写入和读取主机的详细信息，包含主机地址、端口、用户名和密码等。

datanode和datahost和schema的理解

<dataNode> — 数据节点

<dataNode> 配置项定义了 Mycat 如何连接到实际的数据库节点。每个数据节点代表一个与数据库系统（如 MySQL、Oracle 等）连接的实例，通常是 一个数据库的物理或虚拟节点。数据节点是 Mycat 内部如何进行分库分表操作的核心配置。

作用：

数据节点 表示 Mycat 能访问到的数据库实例。通常，一个数据节点代表一个数据库或一个分片的数据库。
数据节点 存储和提供数据，Mycat 根据配置的 分片规则 将 SQL 请求路由到对应的 dataNode。
每个 dataNode 可能关联多个 数据主机（<dataHost>），但 dataNode 代表的是 Mycat 内部用来路由数据的逻辑单元。

<dataHost> — 数据主机

定义：

<dataHost> 是与 数据库主机 相关的配置项，描述了数据库实例的连接细节，比如数据库主机的地址、端口、数据库类型、连接池设置等。dataHost 是实际的数据库连接配置，而 dataNode 则是逻辑上的数据库节点标识，它将指向一个具体的 dataHost。

作用：

数据主机 描述的是 Mycat 如何连接到数据库的具体信息，比如 IP 地址、端口、用户名、密码等。
Mycat 通过 dataNode 来逻辑上组织分片或数据库分布，而 dataHost 则指定实际的数据库连接信息。
dataHost 可以关联一个或多个数据库主机，通过 读写分离 等方式管理主从数据库。

<schema> — 数据库模式

<schema> 是 Mycat 配置中的一个顶级元素，它描述了 一个逻辑数据库的结构，包括了该数据库的分片规则、表的配置以及与数据节点（dataNode）的关联。<schema> 用于定义如何将请求路由到不同的 dataNode，并且指定如何根据配置的规则进行分库分表。

作用：

数据库模式 定义了一个完整的逻辑数据库结构。它通常包含多个数据表，并且可以配置这些表的分库分表规则。
schema 中定义的表会依据指定的 数据分布规则 被分布到多个 dataNode 上。
schema 配置不仅包含 数据表的定义，还包括 数据节点（dataNode）的配置，指明这些表如何与具体的数据库节点连接。

mycat实验

1.搭建主从架构

标签：架构,log,数据库,MySQL,节点,mysql,服务器,日志,主从
From： https://www.cnblogs.com/cloudwangsa/p/18625276

MySQL主从架构

MySQL主从架构

MYSQL REPLICATION的作用

MYSQL REPLICATION支持的复制类型

Statement-Based Replication (SBR) — 基于语句的复制

Row-Based Replication (RBR) — 基于行的复制

例子：

Mixed-Based Replication (MBR) — 混合模式复制

主从复制的工作过程

1. 主服务器的操作

2. 从服务器的操作

3. 主从复制的实时同步

部署MYSQL主从同步（一主一从）

1.主库开启binlog日志

2.创建用户并授权

3.从节点开启relay-log

4.从节点修改slave状态

查看mysqldump进程信息

删除配置

部署MYSQL主主双向主从复制 M-M

1.部署好主从之后在从节点上开启binlog

2.在从节点创建用户

3.主库开启relaylog日志

4.主节点修改slave状态

部署M-S-S级联复制

mysql读写分离 mycat

x锁和s锁

1. X锁（排它锁，Exclusive Lock）

2. S锁（共享锁，Shared Lock）

Mycat应用场景

Mycat原理

配置mycat

首先安装java环境

配置全局环境变量/etc/profile

解压mycat包并配置环境变量

mycat的目录结构

此时mycat配置完成

mycat详解

mycat配置文件详解

server.xml

schema.xml

datanode和datahost和schema的理解

mycat实验

1.搭建主从架构

相关文章

赞助商

阅读排行