MySQL性能优化（三）

1. MySQL读写分离的应用与性能提升

1.1 什么是读写分离与主从复制        1.2 服务器准备 1.3 主服务器配置 1.4 从服务器配置 1.5 权限配置1.6 防火墙配置1.7 主从服务器测试

2. MySQL集群方式分类与实际应用

2.1 集群方式分类2.2 高可用方案的实际应用2.3 MySQL集群实际应用 

1. MySQL读写分离的应用与性能提升
   读写分离与主从复制是提升mysql性能的重要及必要手段，大中型管理系统或网站必用之。
   1.1 什么是读写分离与主从复制
   先看图
   
   如上图所示，当web server1/2/3要写入数据时，则向mysql db Master(主服务器）发出写入请求（即写入到master），如果要进入读操作时，则只向从服务器 mysql DB Slave1或2或3发出读取请求。如此将原本读写在同一台服务器的工作量分摊到了一台负责写入，N台负责读取（大部分的网站都是读取请求远大于写入请求），从而从一定程度时实现了负载均衡。
   读写分离是靠主从复制来实现的。即当一个数据写入到主服务器后，主服务器会将写入信息写入到binlog（二进制日志）里，同时同步（或异步或半同步）到从服务器里。从服务器根据主服务器传来的binlog，生成relay-log(中继日志），然后mysql服务器再用relay-log的信息将数据写入到数据库。
   如此做的优点除了实现负载均衡之外，还为我们保留了两份实时热备的数据binlog和relay-log。当服务器发生灾难时，我们可以用他们将数据恢复到任何一个时间点。
   1.2 服务器准备
   1)在linux上安装好两台mysql服务器（mysql至少5.5以上），且两台服务器最好在一个机房（如此通过内网进行主从复制，速度远远大于通过外网。如果web服务器也在同一机房，则也可内网访问）。
   测试主的IP为172.16.7.47，从的IP为172.16.7.48
   2)临时关闭两台服务器的防火墙:
   # service iptables stop
   3)如果你没有创建数据库，则进行如下操作
   1.在主服务器上登录mysql
   # mysql -uroot -p你的密码
   2.创建数据库
   mysql> create database test1;
   mysql> create database test2;
   1.3 主服务器配置
   MySQL已经提供了完美的读写分离与主从复制支持，我们只需要作如下设置即可。
   1)配置my.cnf
   # vi /etc/mysql/my.cnf
   1.去掉log-bin=mysql-bin前的“#”号。这一行的意思是允许mysql使用binlog，同时为主从复制打开了大门。这是关键中的关键。
   2.如果有多个数据库，则添加如下行：
   binlog-do-db=数据库名1
   binlog-do-db=数据库名2
   binlog-do-db=数据库名3
   binlog-ignore-db=mysql(忽略mysql服务的数据库)
   3.查看server-id后的数字并记住。slave(从服务器)的server-id不能与该值重复。
   4.查看expire-log-day。binlog过期时间，默认为10天。你可以根据你硬盘空间大小及每天产生的数据量修改。如果你有冷备，则一般设成2-3天即可。
   2)操作数据库
   1.在linux命令行下登录mysql
   # mysql -uroot -p(你的root密码)
   2.创建并授权一个帐号
   mysql> GRANT REPLICATION SLAVE ON . TO ‘slave_account’@’172.16.7.48’ identified by ‘123456’
   这句的意思是，允许从服务器’172.16.7.48 ‘使用’slave-account’及’123456’这个帐号密码对对主服务器的所有数据库（.)进行主从复制（’REPLICATION SLAVE’).
   3.重启mysql使上述配置生效
   # etc/init.d/mysql restart 或 # service mysql restart
   4.查看主服务器binlog状态
   mysql> show master status;
   记下File及Position下的值。以备在配置从服务器时使用。
   注：File：当前binlog的文件名，每重启一次mysql，就会生成一个新binlog文件
   Position：当前binlog的指针位置
   1.4 从服务器配置
   1)配置my.cnf
   # vi /etc/mysql/my.cnf
   1.修改server-id=2（该值不能与主服务器的server-id同。如果有多个从服务器，则该值顺延）
   2.添加如下两行：
   relay-log-index=slave-relay-bin.index (中继日志的索引文件）
   relay-log=slave-relay-bin （中继日志的文件前缀）
   3.重启mysql使上述配置生效
   # /etc/init.d/mysql restart
   4.登录mysql
   # mysql -uroot -p你的密码
   5.停止主从复制服务
   mysql> stop slave
   6.主从关联配置
   mysql> change master to
   master_host=’172.16.7.47’, #主服务器IP
   master_user=’slave_account ‘, #主服务器访问从服务器的用户，即上述第三条第2小条第2子条所述帐号
   master_password=’123456’, #主服务器访问从的密码，即上述第三条第2小条第2子条所述密码
   master_log_file=’mysql-bin.000006’, #主服务器起始的binlog文件名，即图2的file
   master_log_pos=1071; #主服务器binlog起始位置，即图2的postion
   上述每行都特别重要，错一个字符都不行
   7.启动从服务
   mysql> start slave
   8.查看从服务的状态，判断从服务是否生效
   mysql> show slave status\G; （G参数为纵向显示结果）
   如果Slave_IO_Running和Slave_SQL_Running都显示YES，则表示从与主的读写通讯正常、主动复制已经运行，则表明我们主从复制已经设置成功。
   然后，你再在主服务器插入一条数据，看看从服务器相应数据库里有没有做相应更新。如果有，则大功告成。
   1.5 权限配置
   虽然某些mysql版本不进行如下操作，可能也能正常运行，但还是强列建议设置。否则，必有安全之虑。
   1)为master分配select、insert、update、delete权限
   mysql>GRANT SELECT,INSERT,UPDATE,DELETE ON . TO ‘数据库的帐号’@’WEB服务器的IP’ identified by ‘密码’。
   注意，虽然master只负责写，但也必须有select权限。原因是使用事务时，需要从master查询，二是update/delete这些命令都需要使用select权限。
   2)为slave分配select权限
   mysql> GRANT SELECT ON . TO ‘数据库的帐号’@’WEB服务器的IP’ identified by ‘密码’;
   1.6 防火墙配置
   刚才我们为了调试方便，先关闭了防火墙，但这样做，非常很不安全。特别是数据库服务器，关系公司的身家性
   命，更不可小视。
   主从复制的防火墙，还是比较好设置的，如果你只有一台web服务器，则只需要在主、从服务器的iptables里开放2个
   授权即可。先在主服务器执行如下命令：
   iptables INPUT -s 172.16.7.48 -j ACCEPT （允许从服务器访问）
   iptables INPUT -s 10.121.2.142 -j ACCEPT (允许web服务器访问）
   service iptables save (保存上述规则)
   service iptables restart (重启iptables)
   在从中将第一条换成主的IP即可。
   设置完后，再在从上用show slave status看看主从复制是否正常。
   1.7 主从服务器测试
   主服务器Mysql，建立数据表，并在这个库中建表插入一条数据：
   mysql> use test1;
   Database changed
   mysql> create table hi_tb(id int(3),name char(10));
   Query OK, 0 rows affected (0.00 sec)
   mysql> insert into hi_tb values(001,’bobu’);
   Query OK, 1 row affected (0.00 sec)
   mysql> show databases;
   从服务器Mysql查询：
   mysql> show databases;
   +——————–+
   | Database |
   +——————–+
   | information_schema |
   | mysql |
   | test1 |
   +——————–+
   4 rows in set (0.00 sec)
   mysql> use test1
   Database changed
   mysql> select * from hi_tb; //查看主服务器上新增的具体数据
   +——+——+
   | id | name |
   +——+——+
   | 1 | bobu |
   +——+——+
   1 row in set (0.00 sec)
   读写分离容错：
   编写一shell脚本，用nagios监控slave的两个yes（Slave_IO及Slave_SQL进程），如发现只有一个或零个yes，就表明主从有问题了。

2. MySQL集群方式分类与实际应用
   2.1集群方式分类：
   分为同步集群和异步集群。
   2.1.1
   同步集群（mysql cluster）
   结构： （data + sql + mgm节点）
   特点：
   1) 内存级别的，对硬件要求较低，但是对内存要求较大；
   2) 数据同时放在几台服务器上，冗余较好；
   3) 速度一般；
   4) 建表需要声明为engine=ndbcluster；
   5) 扩展性强；
   6) 可以实现高可用性和负载均衡，实现对大型应用的支持；
   7) 必须是特定的mysql版本，如：已经编译好的max版本；
   8) 配置和管理方便，不会丢失数据；
   2.1.2
   异步集群
   结构： （master + slave )
   特点：
   1) 主从数据库异步数据；
   2) 数据放在几台服务器上，冗余一般；
   3) 速度较快；
   4) 扩展性差；
   5) 无法实现高可用性和负载均衡（只能在程序级别实现读写分离，减轻对主数据库的压力）
   6) 配置和管理较差，可能会丢失数据；
   2.2 高可用方案的实际应用
   2.2.1. 主从或主主半同步复制
   使用双节点数据库，搭建单向或者双向的半同步复制。在5.7以后的版本中，由于lossless replication、logical多线程
   复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。
   常见架构如下：
   
   通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的健康，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。
   优点：
   架构比较简单，使用原生半同步复制作为数据同步的依据；
   双节点，没有主机宕机后的选主问题，直接切换即可；
   双节点，需求资源少，部署简单；
   缺点：
   1)完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；
   2)需要额外考虑haproxy、keepalived的高可用机制。
   2.2.2. 半同步复制优化
   半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。
   该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。
   可参考的优化方案如下：
   2.2.2.1. 双通道复制
   
   半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。
   2.2.2.2 binlog文件服务器
   
   搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。
   优点：
   双节点，需求资源少，部署简单；
   架构简单，没有选主的问题，直接切换即可;
   相比于原生复制，优化后的半同步复制更能保证数据的一致性。
   缺点：
   1.需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。
   2.依旧依赖于半同步复制，没有从根本上解决数据一致性问题。
   2.2.3. 高可用架构优化
   将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。
   由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。
   但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：
   2.2.3.1. MHA+多节点集群
   
   MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。
   MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。
   MHA也可以扩展到如下的多节点集群：
   
   优点：
   1、可以进行故障的自动检测和转移;
   2、可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;
   3、相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低
   缺点：
   1、至少需要三节点，相对于双节点需要更多的资源;
   2、逻辑较为复杂，发生故障后排查问题，定位问题更加困难;
   3、数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;
   4、可能因为网络分区发生脑裂现象;
   2.2.3.2. zookeeper+proxy
   Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。
   
   优点：
   1、较好的保证了整个系统的高可用性;
   2、扩展性较好，可以扩展为大规模集群;
   缺点：
   1、数据一致性仍然依赖于原生的mysql半同步复制;
   2、引入zk，整个系统的逻辑变得更加复杂;
   2.2.4. 共享存储
   共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。
   2.2.4.1. SAN共享储存
   SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：
   
   使用共享存储时，MySQL服务器能够正常挂载文件系统并操作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。
   优点：
   1.两节点即可，部署简单，切换逻辑简单；
   2.很好的保证数据的强一致性；
   3.不会因为MySQL的逻辑错误发生数据不一致的情况；
   缺点：
   1.需要考虑共享存储的高可用；
   2.价格昂贵；
   2.2.4.2. DRBD磁盘复制
   DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：
   
   当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。
   DRBD是Linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。
   优点：
   两节点即可，部署简单，切换逻辑简单；
   相比于SAN储存网络，价格低廉；
   保证数据的强一致性；
   缺点：
   1.对io性能影响较大；
   2.从库不提供读操作；
   2.2.5. 分布式协议
   分布式协议可以很好解决数据一致性问题。比较常见的方案如下：
   2.2.5.1. MySQL cluster
   MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致
   性。
   
   优点：
   全部使用官方组件，不依赖于第三方软件；
   可以实现数据的强一致性；
   缺点：
   1.国内使用的较少；
   2.配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；
   3.至少三节点；
   2.2.5.2. Galera
   基于Galera的MySQL高可用集群，是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：
   
   优点：
   多主写入，无延迟复制，能保证数据强一致性；
   有成熟的社区，有互联网公司在大规模的使用；
   自动故障转移，自动添加、剔除节点；
   缺点：
   1.需要为原生MySQL节点打wsrep补丁
   2.只支持innodb储存引擎
   3.至少三节点；
   2.2.5.3. PAXOS
   Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：
   
   优点：
   多主写入，无延迟复制，能保证数据强一致性；
   有成熟理论基础；
   自动故障转移，自动添加、剔除节点；
   缺点：
   1.只支持innodb储存引擎
   2.至少三节点；
   2.3 MySQL集群实际应用
   2.3.1 MySQL cluster 安装部署方案
   2.3.1.1 准备
   2.3.1.1.1 准备服务器
   计划建立有5个节点的MySQL CLuster体系，需要用到5台服务器，但是我们做实验时没有这么多机器，可以只
   用2台，我就是一台本机，一台虚拟机搭建了有5个节点的MySQL CLuster体系，将一个SQL节点一个数据节点一
   个SQL节点放在了一台服务器上(172.16.7.39),将另一个SQL节点和一个数据节点放在了另外一台服务器上
   (172.16.7.44)。
   节点配置说明
   
   2.3.1.1.2 准备软件包
   现在的MySQL官方提供了一个专门作集群的安装包，这样就不用一个个的下载所需要的工具了。
   准备安装包mysql-cluster-gpl-7.3.7-linux-glibc2.5-x86_64.tar.gz 将安装包放在/var/tmp 目录下。
   最新的集群安装包可以去https://dev.mysql.com/downloads/cluster/ 进行下载。
   2.3.1.2 安装
   2.3.1.2.1 数据节点和SQL节点
   第一步 添加mysql用户和组，这是必需的。
   groupadd mysql
   useradd -g mysql mysql
   第二步 开始安装，下载的版本是免编译的。
   cd /var/tmp
   tar -zvxf mysql-cluster-gpl-7.3.7-linux-glibc2.5-x86_64.tar.gz
   mv mysql-cluster-gpl-7.3.7-linux-glibc2.5-x86_64 /usr/local/mysql
   第三步 在mysql修改目录权限，这也是必需的，不然第四步会报错的。
   cd /usr/local/mysql
   chown -R root .
   chown -R mysql data
   chgrp -R mysql .
   第四步 安装初始的数据库表
   路径保持在 /usr/local/mysql 下
   初始化mysql:scripts/mysql_install_db –user=mysql
   第五步 设置mysql服务为开机自启动（可省略）
   路径保持在 /usr/local/mysql 下
   cp support-files/mysql.server /etc/rc.d/init.d/mysqld
   chmod +x /etc/rc.d/init.d/mysqld
   chkconfig –add mysqld
   2.3.1.2.2 管理节点
   管理节点的安装更简单，只要在172.16.7.39服务器上复制些文件出来就行了，虽然只有一步，便这一步在目前环境下
   (管理节点和SQL节点在同一台服务器上)也不是必需的。
   cd /usr/local/mysql
   cp bin/ndb_mgm* /usr/local/bin
   cd /usr/local/bin
   chmod +x ndb_mgm*
   管理节点只要ndb_mgm和ndb_mgmd两个文件和一个配置文件即可，因此把这三个文件复制到那里，就是管理节点
   了。ndb_mgmd是mysql cluster管理服务器，ndb_mgm是客户端管理工具，等一下会用到它们的。到目前为止两个
   SQL节点两个数据节点和一个管理节点都安装完成了，但是还不能工作，得进行配置，把这几个节点联系在一起协
   同工作。
   2.3.1.2 配置
   2.3.1.2.1数据节点和SQL节点
   MySQL服务启动时会默认加载/etc/my.cnf作为其配置文件，要将一个mysql服务器配置成一个数据节点和SQL节点也非常
   的简单，这是配置前的my.cnf的内容：
   [client]port =3306
   socket =/tmp/mysql.sock
   [mysqld]
   basedir =/usr/local/mysql/
   datadir =/usr/local/mysql/
   datauser = mysql
   log-error =/tmp/mysqld.err
   #只要在内容结尾加上4行就将这个mysql服务器变成了一个数据节点和SQL节点。
   ndbcluster
   #指定管理节点
   ndb-connectstring=172.16.7.39
   [mysql_cluster]
   ndb-connectstring=172.16.7.39
   #注意两台服务器都得这样配置。
   2.3.1.2.2 管理节点
   管理节点的配置复杂一点，在管理服务器172.16.7.39的/var/lib/mysql-cluster/目录中创建config.ini文件。
   cd /var/lib
   mkdir mysql-cluster
   cd mysql-cluster
   vim config.ini
   在config.ini文件中添加以下内容：
   [NDBD DEFAULT]
   NoOfReplicas=1 #每个数据节点的镜像数量
   DataMemory=80M #每个数据节点中给数据分配的内存
   IndexMemory=20M #每个数据节点中给索引分配的内存
   [TCP DEFAULT]
   portnumber=2202 #数据节点的默认连接端口
   [NDB_MGMD] #配置管理节点
   NodeId=1
   hostname=172.16.7.39
   datadir=/var/lib/mysql-cluster/ #管理节点数据(日志)目录
   [NDBD] #数据节点配置
   NodeId=2
   hostname=172.16.7.39
   datadir=/usr/local/mysql/data/ #数据节点目录
   [NDBD] #数据节点配置
   NodeId=3
   hostname=172.16.7.44
   datadir=/usr/local/mysql/data/ #数据节点目录
   [MYSQLD]
   [MYSQLD]
   [NDBD DEFAULT]：表示每个数据节点的默认配置在每个节点的[NDBD]中不用再写这些选项，只能有一个。
   [NDB_MGMD]：表示管理节点的配置，只有一个。
   [NDBD]：表示每个数据节点的配置，可以有多个。
   [MYSQLD]：表示SQL节点的配置，可以有多个，分别写上不同SQL节点的IP地址，也可以什么都不写，只保留一个空节点，表示任意一个IP地址都可以进行访问，此节点的个数表明了可以用来连接数据节点的SQL节点总数。
   2.3.1.3 启动
   2.3.1.3.1 管理节点
   MySQL cluster 需要各个节点都启动后才可以工作，节点的启动顺序为管理节点->数据节点->SQL节点。首先启
   动管理节点
   cd /usr/local/bin
   ./ndb_mgmd -f /var/lib/mysql-cluster/config.ini
   命令行中的ndb_mgmd是MySQL cluster的管理服务器，后面的-f表示后面的参数是启动的参数配置文件。如果在启动
   后过了几天又添加了一个数据节点，这时修改了配置文件启动时就必须加上–initial参数，不然添加的节点不会作用
   在MySQL cluster中。
   ./ndb_mgmd -f /var/lib/mysql-cluster/config.ini –initial 首次启动必须加—initial参数
   启动时可能会报个WARNING,如WARNING – at line 7: [TCP] portnumber is deprecated，这个不用管。可以正常工
   作的。
   2.3.1.3.2 数据节点
   安装后第一次启动数据节点时要加上–initial参数，其它时候不要加，除非是在备份、恢复或配置变化后重启时。
   cd /usr/local/mysql/bin
   ndbd –initial
   如果显示以下信息说明启动完成：
   2017-05-15 17:04:03 [ndbd] INFO – Angel connected to ‘172.16.7.39:1186’
   2017-05-15 17:04:03 [ndbd] INFO – Angel allocated nodeid: 2
   2.3.1.3.3 SQL节点
   service mysqld start
   2.3.1.3.4 客户端管理
   cd /usr/local/bin
   ./ndb_mgm
   这时就进入到客户端，可以对mysql cluster进行各项操作，进入后会有ndb_mgm > 提示符出现，首先来查看各节点的
   连接情况，在ndb_mgm> 提示符下输入show：
   2.3.1.4 关闭
   MySQL cluster的关闭也很简单，只需在ndb_mgm> 提示符下输入 shutdown即可，这时会显示各节点的关闭信息，再输入exit即可退出ndb_mgm管理，回到shell中。虽然mysql cluster 关闭了，但是SQL节点的mysql服务并不会停止的。接下来就可以做各种试验了。
   2.3.2 MySQL cluster实例实验
   2.3.2.1 数据结构准备
   创建数据库winshare和测试数据表ctest1。
   2.3.2.2 测试一
   2.3.2.2.1 在数据节点1(172.16.7.39)上执行
   1)登录MySQL数据库: mysql -uroot –p 输入密码
   2)查看数据库: show databases;
   3)创建数据库: create database winshare;
   4)使用数据库: use winshare;
   5)CREATE TABLE ctest1 (id INT(4),name varchar(50)) ENGINE=NDB; //这里必须指定数据库表的引擎为NDB,否则同
   步失败
   6)INSERT INTO ctest1 (id,name) VALUES (1,’zhangsan’);
   2.3.2.2.2 在数据节点2(172.16.7.44)上查看数据是否同步
   1) select * from ctest1;
   2.3.2.2.3 同样的方式在在数据节点2(172.16.7.44)上写入数据
   1)insert into ctest1(id,name) values(2,’lisi’);
   2)查看数据节点2的数据 select * from ctest1;
   3)查看数据节点1的数据 select * from ctest1;
   2.3.2.3 测试二
   1)关闭在数据节点1(172.16.7.39)上mysql服务:service mysqld stop
   2)在数据节点2(172.16.7.44)上写入一条数据：
   
   3)开启关闭的数据节点1 (172.16.7.39)上mysql服务: service mysqld start
   4)在数据节点1上执行查询: select * from ctest1;
   2.3.2.4 结论
   通过测试在数据节点1(172.16.7.39)创建库和写入数据，数据会同步到数据节点2(172.16.7.44)上，同样在数据节点2上写入
   数据数据则会同步到数据节点1上。
   实现了mysql集群的双主模式，实现数据双向同步保证了数据的强一致性。
   2.3.3 注意事项
   1)MySQL cluster集群服务官方并没有声明服务器内存要求，但是经过测试，管理节点、数据节点和MySQL节点至少需要1G的内存(管理节点和数据节点配置共100M)。否则启动数据节点时会报错，管理节点会有直接关闭数据节点的安全策略。
   2)如果MySQL节点启动异常，可能是权限问题，也有可能是内存不足。这个时候应该追查日志信息具体问题具体分析。
   3)MySQL集群只支持 NDB 存储引擎。也就是说，想要让一个表在集群节点中共享，就必须指定ENGINE=NDB(或 ENGINE=NDBCLUSTER 也一样)。MySQL集群中也可以使用MyISAM或InnoDB存储引擎来创建数据表，但是那些非NDB的表不会存储在集群节点间共享;它们独立于创建的MySQL服务器或者实例中。