关于mysql:MySQL-数据库集群PXC-方案三

MySQL 数据库集群 -PXC 计划（三）

什么是基准测试

基准测试是针对零碎的一种压力测试，但基准测试不关怀业务逻辑，更加简略、间接、易于测试，不要求数据的真实性和逻辑关系。

基准测试的指标

Sysbench 简介

Sysbench 是一个模块化的、跨平台、多线程基准测试工具，次要用于测试零碎及数据库的性能。它次要包含以下几种形式的测试：

• CPU 性能（零碎级别）
• 磁盘 IO 性能（零碎级别）
• 调度程序性能（零碎级别）
• 内存调配及传输速度（零碎级别）
• POSIX 线程性能（零碎级别）
• 数据库性能(OLTP 基准测试)

目前 Sysbench 次要反对 MySQL,pgsql,oracle 这 3 种数据库。

装置 Sysbench

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
yum -y install sysbench

装置实现后查看是否装置胜利

sysbench --version

Sysbench 根本语法

sysbench script [option] [command]

option 连贯信息参数

option 执行参数

执行模式：

• simple：测试查问 不测试写入
• nontrx：测试无事务的增删改查
• complex：测试有事务的增删改查

command 命令

筹备测试数据

在筹备之前咱们先批改一下 haproxy.cfg 文件，之前咱们配置的是 MyCat 集群的负载平衡，当初改为某一个分片的 PXC 集群即可。

vim /etc/haproxy/haproxy.cfg

server mysql_1 192.168.3.137:3306 check port 3306 weight 1 maxconn 2000
server mysql_1 192.168.3.138:3306 check port 3306 weight 1 maxconn 2000
server mysql_1 192.168.3.139:3306 check port 3306 weight 1 maxconn 2000

保留之后执行命令重启

service haproxy restart

能够看到下图没有问题：

之后咱们新建一个测试逻辑库sbtest

接着咱们 创立测试数据

sysbench  /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.3.146 --mysql-port=3306 --mysql-user=admin --mysql-password=Abc_123456 --oltp-tables-count=10 --oltp-table-size=100000 prepare

• /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua：生成测试数据的脚本 sysbench 自带
• –mysql-host：数据库连贯地址
• –mysql-port：端口
• –mysql-user：用户名
• –mysql-password：明码
• –oltp-tables-count：测试 10 个数据表
• –oltp-table-size：每张表 10 万条数据
• prepare：筹备测试数据

创立实现后咱们 执行测试

sysbench  /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.3.146 --mysql-port=3306 --mysql-user=admin --mysql-password=Abc_123456 --oltp-test-mode=complex --threads=10 --time=300 --report-interval=10 run >> /home/mysysbench.log

• –oltp-test-mode=complex：测试有事务的增删改查
• –threads：并发连接数
• –time：测试时长，测试的时长更长一些，比方 24 小时，测试的后果会更加精确
• –report-interval=10：每隔 10 秒回报一次数据
• run >> /home/mysysbench.log：输出测试日志报告文件地位

期待 5 分钟执行实现后，咱们查看 /home/mysysbench.log。

• queries performed：执行测试的次数
• read : 读操作执行了 442176 次
• write：写操作执行了 117484 次
• other：其余操作执行了 66275 次
• total：总共执行了 625935 次
• transcations（TPS）：执行的事务次数 28415 次，PXC 集群每秒能够执行的事务操作 94.67 次
• queries(QPS)：解决的请求书 625935，PXC 集群每秒钟能够执行 2085.35 次增删改查操作
• ignored errors：疏忽的谬误数量 3169，每秒钟均匀谬误数量 10.56 次，可能是节点之间抵触造成
• reconnects：数据库从新连贯的次数，0 代表没有产生数据库连贯断开的状况

清理测试数据：

sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.3.146 --mysql-port=3306 --mysql-user=admin --mysql-password=Abc_123456 --oltp-tables-count=10 cleanup

小结

基准测试是对单张表进行的读写测试，因为不波及表连贯外键束缚，索引等操作，所以单纯体现的是数据库硬件性能。如果想晓得数据库集群在实在业务中的理论性能，须要应用压力测试。

tpcc-mysql 简介

tpcc-mysql 是 percona 基于 tpcc 标准衍生进去的产品，专门用于 mysql 压力测试。

tpcc 是一种测试规范，明确规定了数据模型和检测是指标，而且检测的规范对数据库集群来说很刻薄，tpcc-mysql 的测试库能笼罩大多数的业务场景，测试的后果也能反映出实在业务中数据库的理论性能。

tpcc 测试问题

tpcc 的检测规范是针对单节点的 mysql 数据库，对 sql 的执行工夫有严格的规定，咱们要测试的 PXC 集群是以就义插入速度为代价换取的同步强一致性，如果 tpcc 要执行一个 insert 语句不能超过 100ms，然而 PXC 集群只是写入速度慢，插入执行了 300ms。这个检测点就没有通过，所以拿 tpcc 测试 PXC 集群不太适宜，检测的规范太刻薄了一些，然而因为数据库集群在实在业务下理论的读写性能，每秒钟能执行多少次读操作，多少次写操作。至于因为插入速度慢测试报告中测试没有通过，能够不予理睬。

测试计划

咱们还是以 haproxy+ 三个 mysql 节点的 PXC 集群来进行测试。

筹备工作（一）

敞开咱们的 PXC 集群。对应敞开操作在第二篇文章中写的很分明。

而后关上 vim /etc/my.cnf

把 PXC_strict_mode 的值改成 DISABLED
原来默认的参数值是不容许咱们执行不符合规范的操作，比方创立出没有主键的数据表，tpcc 数据库脚本里边有一个表没有主键，所以为了 tpcc 测试能进行上来咱们要批改 PXC_strict_mode 的值。

三个 PXC 节点都须要批改

批改完 my.cnf 文件之后再重新启动 PXC 集群。

筹备工作（二）

Haproxy 对应的文件进行批改，因为咱们之前曾经批改过了这里就不必再批改了。

server mysql_1 192.168.3.137:3306 check port 3306 weight 1 maxconn 2000
server mysql_1 192.168.3.138:3306 check port 3306 weight 1 maxconn 2000
server mysql_1 192.168.3.139:3306 check port 3306 weight 1 maxconn 2000

筹备工作（三）

装置环境包。

yum install -y gcc
yum install -y mysql-devel

装置 tpcc-mysql

下载安装包。

https://codeload.github.com/Percona-Lab/tpcc-mysql/zip/master

解压而后上传到服务器。

进入 src 目录，再应用 make 命令编译。

cd src
make

创立测试库

到 PXC 集群的节点上创立数据库tpcc，咱们在 Haproxy 的节点上创立，那么 PXC 集群的 mysql 库也会主动同步。

而后咱们进入 tpcc-mysql-master 目录下执行：

ls *.sql

• create_table.sql 是创立表的 sql 文件
• add_fkey_idx.sql 是索引等束缚文件

咱们将这两个文件复制进去，而后在咱们新建的 tpcc 库中运行。

筹备测试数据

./tpcc_load -h 192.168.3.146 -d tpcc -u admin -p Abc_123456 -w 1

• -h 192.168.3.146 数据库 ip 地址
• -d tpcc 数据库名字
• -u admin 用户名
• -p Abc_123456 明码
• -w 1 仓库数量，因为数量宏大，插入工夫较长，所以这里应用 1 个仓库数量，如果应用多个仓库，耗时很长。

执行测试

./tpcc_start -h 192.168.3.146 -d tpcc -u admin -p Abc_123456 -w 1 -c 5 -r 300 -l 600 - >tpcc-outpit.log

• -h 192.168.3.146 数据库 ip 地址
• -d tpcc 数据库名字
• -u admin 用户名
• -p Abc_123456 明码
• -w 1 仓库数量
• -c 5 并发线程数
• -r 300 数据库预热工夫 单位秒
• -l 600 测试工夫单位秒
• tpcc-outpit.log 测试后果输入到文件

为了真实性能够将 -r 和 -l 工夫设置长一些，比方预热 1 个小时，测试 24 小时。

查看日志日志呈现了大量的死锁异样，执行压力测试的时候，事务执行的工夫太久，没有及时提交事务，于是呈现了锁抵触。让 PXC 集群的锁抵触降到最低，将并发的线程数改为 1。

./tpcc_start -h 192.168.3.146 -d tpcc -u admin -p Abc_123456 -w 1 -c 1 -r 300 -l 600 - >tpcc-outpit.log

查看测试后果

• sc: 胜利执行的次数
• lt: 超时执行的次数
• rt: 重试执行的次数
• fl: 失败执行的次数

第一行是新订单执行的测试后果，tpcc 在规定工夫内胜利执行了 0 条记录，因为 tpcc 测试指标是十分刻薄的，尽管咱们执行了操作，然而执行工夫没有达到 tpcc 的要求，所以不能算为执行胜利，只能算做是 超时执行 。PXC 集群是以就义速度为代价换取数据同步的强一致性。虽热增删改成都能执行，然而达不到 tpcc 的指标。rt(重试执行的次数) 和 fl(失败执行的次数)是 0 次。

第二行是领取业务的测试后果。胜利执行了 0 次，超时执行了 3587 次，重试执行 0 次，失败 0 次。

第三行是订单状态的测试后果。胜利执行了 195 次，超时执行了 163 次，重试执行 0 次，失败 0 次。

第四行是发货业务的测试后果。胜利执行了 0 次，超时执行了 358 次，重试执行 0 次，失败 0 次

第五行是库存业务的测试后果。胜利执行了 0 次，超时执行了 359 次，重试执行 0 次，失败 0 次。

只管达不到 tpcc 的测试指标，然而没有失败执行的。以上是各种业务下的增删改查操作。

上面这个是事务的操作状态，测试报告也是通过的。

响应工夫的一个测试，NG 代表没有通过，OK 代表的是测试通过。用 tpcc 测试 PXC 集群有些不合理，tpcc 测试是依照单节点 mysql 读写速度和响应工夫来制订的指标。所以 PXC 集群很难能达到 tpcc 的指标，所以这里很多响应工夫的指标都是 NG 没通过的。

最初的 TpmC 是，每分钟 PXC 集群执行的事务数量。

binlog 简介

MySQL 的二进制日志 binlog 能够说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查问语句 select、show 等），以事件模式记录 ，还蕴含语句所执行的耗费的工夫，MySQL 的二进制日志是事务平安型的。binlog 的次要目标是 复制和复原。

binlog 日志的两个最重要的应用场景：

• MySQL 主从复制
• 数据恢复

binlog 文件品种

• 二进制日志索引文件（文件名后缀为.index）用于记录所有无效的的二进制文件
• 二进制日志文件（文件名后缀为.00000\*）记录数据库所有的 DDL 和 DML 语句事件

binlog 是一个二进制文件汇合，每个 binlog 文件以一个 4 字节的魔数结尾，接着是一组 Events:

• 魔数：0xfe62696e 对应的是 0xfebin；
• Event：每个 Event 蕴含 header 和 data 两个局部；header 提供了 Event 的创立工夫，哪个服务器等信息，data 局部提供的是针对该 Event 的具体信息，如具体数据的批改；
• 第一个 Event 用于形容 binlog 文件的格局版本，这个格局就是 event 写入 binlog 文件的格局；
• 其余的 Event 依照第一个 Event 的格局版本写入；
• 最初一个 Event 用于阐明下一个 binlog 文件；
• binlog 的索引文件是一个文本文件，其中内容为以后的 binlog 文件列表

当遇到以下 3 种状况时，MySQL 会从新生成一个新的日志文件，文件序号递增：

• MySQL 服务器进行或重启时
• 应用 flush logs 命令
• 当 binlog 文件大小超过 max_binlog_size 变量的值时

max_binlog_size 的最小值是 4096 字节，最大值和默认值是 1GB (1073741824 字节)。事务被写入到 binlog 的一个块中，所以它不会在几个二进制日志之间被拆分。因而，如果你有很大的事务，为了保障事务的完整性，不可能做切换日志的动作，只能将该事务的日志都记录到以后日志文件中，直到事务完结，你可能会看到 binlog 文件大于 max_binlog_size 的状况。

Binlog 的日志格局

记录在二进制日志中的事件的格局取决于二进制记录格局。反对三种格局类型：

• STATEMENT：基于 SQL 语句的复制（statement-based replication, SBR）
• ROW：基于行的复制（row-based replication, RBR）
• MIXED：混合模式复制（mixed-based replication, MBR）

在 MySQL 5.7.7 之前，默认的格局是 STATEMENT，在 MySQL 5.7.7 及更高版本中，默认值是 ROW。日志格局通过 binlog-format 指定，如 binlog-format=STATEMENT、binlog-format=ROW、binlog-format=MIXED。

ROW 模式

注：我是在本地环境下测试。

输出命令关上咱们的 mysql 配置文件

vim /etc/my.cnf

减少如下配置：

binlog_format = row
log_bin=mysql_bin

重启服务后能够看到如下：

接着我在本地表中减少了两条测试数据：

关上 mysql_bin.index能够看到内容很简略就是记录了有哪些文件：

./mysql_bin.000001
./mysql_bin.000002

在 mysql 中应用上面命令去查看都有哪些日志文件。

show master logs;

之后咱们筛选一个文件来进行查看：

show binlog events in 'mysql_bin.000001';

这里记录的不是 sql 语句，咱们能够看到开启了一个 session 而后开启事务而后写入操作最初提交事务。

每条记录的变动都会写入到日志中。

5.1.5 版本的 MySQL 才开始反对 row level 的复制, 它不记录 sql 语句上下文相干信息，仅保留哪条记录被批改。

PXC 节点默认的日志模式就是 row 模式

长处：

• 清晰的记录了每条记录的细节
• 数据同步安全可靠
• 同步时呈现行锁的更少

毛病：

• 日志体积太大，节约存储空间
• 数据同步频繁速度慢

注：将二进制日志格局设置为 ROW 时，有些更改依然应用基于语句的格局，包含所有 DDL 语句，例如 CREATE TABLE，ALTER TABLE，或 DROP TABLE。

STATEMENT 模式

每一条会批改数据的 sql 都会记录在 binlog 中

我把 /etc/my.cnf批改成 statement 模式，而后删除 mysql_bin.index 和mysql_bin_00000相干文件最初重启 mysql。

binlog_format = statement

之后咱们新建一条数据后查看咱们的日志：

show master logs;
show binlog events in 'mysql_bin.000001';

能够看到在事务中是记录的 sql 语句。

长处：

• 日志文件体积小
• 节俭 I/O 和存储资源
• 集群节点同步速度快

毛病：

• 某些函数和主键自增长会呈现同步数据不统一
• 另外 mysql 的复制，像一些特定函数的性能，slave 与 master 要保持一致会有很多相干问题。

MIXED 模式

从 5.1.8 版本开始，MySQL 提供了 Mixed 格局，实际上就是 Statement 与 Row 的联合。
在 Mixed 模式下，个别的语句批改应用 statment 格局保留 binlog，如一些函数，statement 无奈实现主从复制的操作，则采纳 row 格局保留 binlog，MySQL 会依据执行的每一条具体的 sql 语句来辨别看待记录的日志模式，也就是在 Statement 和 Row 之间抉择一种。

还是之前的步骤，咱们批改 binlog_format = mixed

再减少两条数据，一般插入一条和应用函数减少一条。

insert into student(id,name) values (5,UUID());

之后咱们查看日志：

show master logs;
show binlog events in 'mysql_bin.000001';

能够看到在事务中是记录有 row 模式和 statement 模式。

MySQL 的 5 种非凡设计

1.MySQL+ 分布式 Proxy 扩大

MySQL+ 分布式 Proxy 扩大分好多种状况：

PXC 集群

PXC 集群就义读写速度的代价保证数据的强一致性，在保证数据强一致性的业务中才举荐应用 PXC 集群，比方与钱相干的业务必须应用 PXC 集群，数据不统一导致的结果很难承当。因为 PXC 集群是就义写入速度保证数据的强一致性，加强 PXC 集群性能能够应用数据分片，比方应用 MyCat 分片，通过 MyCat 散发之后每个分片写入的压力就缩小了很多，性能就能晋升不少。另外在业务设计上也要防止 刹时写入 的压力。

Replication 集群

说完了数据强一致性的 PXC 集群，咱们再说一下弱一致性的 Replication 集群。用 Replication 搭建集群之后也能够应用数据分片，也能够应用 MyCat 来进行治理，也能够应用 Haproxy 和 Keepalived。

PXC 集群 +Replication 集群

面对简单的业务，零碎会同时面对强一致性和弱一致性。咱们能够将两种集群整合在一起，咱们依据程度拆分的准则，把须要强一致性的数据表建设在 PXC 集群，不须要强一致性的数据表建设在 Replication 集群里。关键性的数据写在 PXC，非关键性的数据写在 RP 里。这就兼顾了强一致性，弱一致性，读写速度的矛盾。

在 CRUD 语句里边最简单的是查问语句，单表查问还好，表连贯要是查问不同集群中的数据表这就会很简单。应答这种查问形式有两种，第一种是因为 Replication 集群写入速度比 PXC 集群速度更快，咱们能够应用同步中间件将 PXC 集群中的数据同步到 Replication 集群。而后在 Replication 集群里边查问表连贯操作。这样就能查到你想要的数据后果。另一种计划是ETL 中间件，先把数据从不同的集群中抽取进去，而后再做表连贯去查问，比方出名的 ETL 中间件Kettle。

PXC 集群 +Replication 集群 + 缓存集群

说完了 PXC 集群和 Replication 集群的混合计划，如果系统对读写速度要求更高，咱们还能够引入 mongodb，redis 等 NoSQL 缓存数据库。
这里就要关注一下数据库集群的事务，有些人会想到 XA 事务，然而 PXC 集群不反对 XA 事务，所以这个计划并不可行。阿里巴巴有一个 GTS 的中间件，他能够把各种数据库纳入到一个事务之下，然而 GTS 只能运行在阿里云上。还有一种计划是利用消息中间件，去模仿分布式的事务，把 PXC 集群、Replication 集群、缓存集群纳入到事务之内。

2. 数据归档，冷热数据拆散

随着是数据的减少，无论是单节点的 mysql 还是 mysql 的集群，都要做冷热数据拆散，冷数据能够寄存到 归档表，能够应用 MongoDB，也能够应用 TokuDB 来保留归档数据。mongodb 大家都相熟，这里次要解说一下 TokuDB。TokuDB 是 mysql 的一种存储引擎，能够高速的写入数据，写入速度是 innodb 引擎的 9 倍，压缩比是 innodb 的 14 倍，跟 mongdb 相比丝毫不逊色，TokuDB 的写入性能是 MongoDB 的 4 倍，而且还是带事务的写入。

3.MySQL+ 缓存 (Redis) 高并发架构

比方以发红包的案例，用户 A 发红包，把红包数据存入缓存，用户 B,C,D 抢完红包之后，再把红包数据写入到数据库中。

4.MySQL+ 小文件系统

咱们能够将一些用户的图片上传到服务器，在数据库中只存储图片门路。而并非在数据库中存储 blog 类型的数据。

5.MySQL+Inforbright 统计分析架构

这一种 mysql 设计方案跟数据分析无关，对于数据库而言，通常是第二天之后才会有后果汇总统计分析的需要，这类 OLAP 执行频率较低，然而每次统计的信息太多，耗费的资源很大，如果在 OLTP 零碎上运行会造成两大业务的相互影响，所以咱们应该把 OLAP 给独立进来，通过数据流转把 OLTP 的数据传输个 OLAP 零碎，有很多成熟的 OLAP 零碎比方 Inforbright 零碎，在几百万到几十亿数据的规模下查问速度是 mysql 的 5-60 倍。相对而言 Inforbright 是轻量级的，而分布式的 mpp 数据仓库能够撑持更大海量数据的统计分析，所以有数据分析的零碎不防试一试这种架构。

向集群导入大量数据

如果咱们应用的 sql 文件咱们能够应用 source test.sql 命令进行导入数据，在数据量不多的时候咱们能够应用，如果数据量过大工夫就会很长。

如果要导入 100 万次的数据。mysql 要进行多少次词法剖析和优化。所以说是十分的耗时。

如果数据量过大，咱们能够应用 LOAD DATA 来进行导入，30 万的数据大略只须要 5 秒就能够导入。

因为 LOAD DATA 是从文本文档里导入纯数据，没有词法剖析和优化，只须要解析每条记录的格局，数据就间接写入到表里了。

比方有几十个 G 的数据，因为 LOAD DATA 是单线程写入，咱们能够将文件切分成多个文件，而后交给多线程来执行，速度大大提高。

导入测试数据

说完了应用什么来导入数据，然而咱们数据从哪里来呢，咱们能够应用 Java 来生成数据。

咱们生成 1000 万条数据：

public class Test {public static void main(String[] args) throws IOException {FileWriter writer = new FileWriter("/Users/jack/Downloads/data.txt");
        BufferedWriter bufferedWriter = new BufferedWriter(writer);
        for (int i = 0; i < 10000000; i++) {bufferedWriter.write(i + ", 测试数据 \n");
        }
        bufferedWriter.close();
        writer.close();}
}

配置数据文件

之后将文件上传到 linux。上传实现之后咱们查看一下：

而后咱们应用上面命令进行切分成十份，按 100 万一份切割。

split -l 1000000 -d data.txt

• -l：按行切分
• -d：文件名名带排序

执行胜利之后咱们就能够看到下图这样：

接着咱们在每个 PXC 分片只开启一个节点，这样就不会同步，引发数据限流。

批改 PXC 节点文件，而后重启 PXC 服务

vim /etc/my.cnf

innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_buffer_pool_size = 200M

接着咱们在两个 PXC 节点中创立表：

CREATE TABLE t_test(
    id INT UNSIGNED PRIMARY KEY,
    name VARCHAR(200) NOT NULL
);

批改 MyCat 配置文件

咱们先敞开 MyCat。

vim schema.xml

减少咱们新建的表：

<table name="t_test" dataNode="dn1,dn2" rule="mod-long" />

因为咱们当初只开启了两个分片中的一个节点，所以删除掉别的节点的配置信息，balance = 0 敞开读写拆散。

<!-- 配置连贯信息 -->
<dataHost name="cluster1" maxCon="1000" minCon="10" balance="0"
            writeType="1" dbType="mysql" dbDriver="native" switchType="1"
            slaveThreshold="100">
    <heartbeat>select user()</heartbeat>
    <writeHost host="W1" url="192.168.3.137:3306" user="admin"
                 password="Abc_123456">
    </writeHost>
</dataHost>
<dataHost name="cluster2" maxCon="1000" minCon="10" balance="0"
            writeType="1" dbType="mysql" dbDriver="native" switchType="1"
            slaveThreshold="100">
    <heartbeat>select user()</heartbeat>
    <writeHost host="W1" url="192.168.3.141:3306" user="admin"
               password="Abc_123456">
    </writeHost>
</dataHost>

保留启动 MyCat

./mycat start

写入 MySQL

之后咱们编写 Java 代码

/**
 * @author 又坏又迷人
 * 公众号: Java 菜鸟程序员
 * @date 2020/11/26
 * @Description: LoadData
 */
public class LoadData {

    private static int num = 0;
    private static int end = 0;
    private static ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(1,
            5, 60, TimeUnit.SECONDS, new LinkedBlockingQueue(200));

    public static void main(String[] args) throws SQLException {DriverManager.registerDriver(new Driver());
        File folder = new File("/home/data");
        File[] files = folder.listFiles();
        end = files.length;
        for (File file : files) {Task task = new Task();
            task.file = file;
            poolExecutor.execute(task);
        }
    }

    public static synchronized void updateNum() {
        num++;
        if (num == end) {poolExecutor.shutdown();
            System.out.println("执行完结");
        }
    }
}

/**
 * @author 又坏又迷人
 * 公众号: Java 菜鸟程序员
 * @date 2020/11/26
 * @Description: Task
 */
public class Task implements Runnable {

    File file;

    @Override
    public void run() {
        String url = "jdbc:mysql://192.168.3.146:8066/test";
        String username = "admin";
        String password = "Abc_123456";
        try {Connection connection = DriverManager.getConnection(url, username, password);
            String sql = "load data local infile'/home/data/"+ file.getName() +"' ignore into table t_test \n"+"            character set 'utf8' \n"+"            fields terminated by ',' optionally enclosed by '\\\"' \n"+"            lines terminated by '\\n' (id,name); ";
            PreparedStatement pst = connection.prepareStatement(sql);
            pst.execute();
            connection.close();
            LoadData.updateNum();} catch (SQLException e) {e.printStackTrace();
        }
    }
}

实现后打包拷贝到服务器上，执行命令运行 Java 代码

java -jar 名字.jar

胜利后，咱们执行 SQL 查看一下：

select count(*) from t_test;

写入实现后，咱们进行两个 PXC 节点，将方才增加语句的删除掉。

systemctl stop  mysql@bootstrap.service

vim /etc/my.cnf

删除上面配置：

innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_buffer_pool_size = 200M

而后咱们把其余的 PXC 节点启动，会主动进行全量同步。

service mysql start

接着把咱们方才在 MyCat 配置文件中删除的其余 PXC 节点信息加回去，进入 conf 目录下：

vim schema.xml

    <schema name="test" checkSQLschema="false" sqlMaxLimit="100">
        <table name="t_test" dataNode="dn1,dn2" rule="mod-long" />
        <table name="t_user" dataNode="dn1,dn2" rule="mod-long" />
        <table name="t_customer" dataNode="dn1,dn2" rule="sharding-customer">
                <childTable name="t_orders" primaryKey="ID" joinKey="customer_id" parentKey="id"/>
        </table>
    </schema>
    <!-- 配置分片关系 -->
    <dataNode name="dn1" dataHost="cluster1" database="test" />
    <dataNode name="dn2" dataHost="cluster2" database="test" />
    <!-- 配置连贯信息 -->
    <dataHost name="cluster1" maxCon="1000" minCon="10" balance="2"
                writeType="1" dbType="mysql" dbDriver="native" switchType="1"
                slaveThreshold="100">
        <heartbeat>select user()</heartbeat>
        <writeHost host="W1" url="192.168.3.137:3306" user="admin"
                     password="Abc_123456">
            <readHost host="W1R1" url="192.168.3.138:3306" user="admin"
                        password="Abc_123456" />
            <readHost host="W1R2" url="192.168.3.139:3306" user="admin"
                        password="Abc_123456" />
        </writeHost>
        <writeHost host="W2" url="192.168.3.138:3306" user="admin"
                     password="Abc_123456">
            <readHost host="W2R1" url="192.168.3.137:3306" user="admin"
                        password="Abc_123456" />
            <readHost host="W2R2" url="192.168.3.139:3306" user="admin"
                        password="Abc_123456" />
        </writeHost>
    </dataHost>
    <dataHost name="cluster2" maxCon="1000" minCon="10" balance="2"
                writeType="1" dbType="mysql" dbDriver="native" switchType="1"
                slaveThreshold="100">
        <heartbeat>select user()</heartbeat>
        <writeHost host="W1" url="192.168.3.141:3306" user="admin"
                   password="Abc_123456">
            <readHost host="W1R1" url="192.168.3.143:3306" user="admin"
                        password="Abc_123456" />
            <readHost host="W1R2" url="192.168.3.144:3306" user="admin"
                        password="Abc_123456" />
        </writeHost>
        <writeHost host="W2" url="192.168.3.143:3306" user="admin"
                   password="Abc_123456">
            <readHost host="W2R1" url="192.168.3.141:3306" user="admin"
                        password="Abc_123456" />
            <readHost host="W2R2" url="192.168.3.144:3306" user="admin"
                        password="Abc_123456" />
        </writeHost>
    </dataHost>
</mycat:schema>

启动 MyCat，进入 bin 目录下

./mycat start

启动之后咱们查问一下别的 PXC 分片，看看数据是否同步过来：

select count(*) from t_test

能够看到 500 万条数据，没问题。

MySQL 数据库设计

外围准则

• 不在数据库做运算
• CPU 计算必须在业务层执行
• 管制字段数量
• 均衡范式与冗余
• 回绝大 SQL 语句、回绝大事务、回绝大批量
• 用失当的数据类型
• 字符转化为数字（节约空间，进步查问性能）
• 防止应用 NULL 字段（NULL 很难查问优化，索引须要额定的空间，而且复合索引有效）
• 防止应用 text 类型

索引设计准则

• 正当应用索引
• 长字符串必须建 前缀索引
• 不在索引列做运算
• 不必外键（应用逻辑外键）

SQL 设计准则

• SQL 语句尽可能简略
• 尽可能应用简略的事务
• 防止应用触发器和存储过程
• OR 改写为 IN
• OR 改写为 UNION