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服务器或者实例中。