定性问题，有以下解决方案： 使用半同步加强数据一致性：异步复制能提供较好的性能，但主库只是把binlog日志发送给从库，动作就结束了，不会验证从库是否接收完毕，风险较高。半同步复制会在发送给从库后，等待从库发送确认信息后才返回。可以设置从库中同步日志的更新方式，从而减少从库同步的延迟，加快同步速度。 安装半同步复制：
在mysql中运行
install plugin rpl_semi_sync_master soname 'semisync_master.so';
install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_master_enabled=ON;
SET GLOBAL rpl_semi_sync_slave_enabled=ON;
修改my.cnf ：
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
sync_relay_log=1
sync_relay_log_info=1
sync_master_info=1
稳定性测试：
测试案例：使用java代码建连接，往某张表插入1w条记录，插入过程中将其中的master服务器停了，看备份服务器是否有这1w笔记录
测试结果，停止主服务器后，java程序抛出异常：
?
但这时再次发送sql命令，可以成功返回。证明只是当时的事务失败了。连接切换到了备份服务器，仍然可用。
翻阅了mysql文档，有章节说明了这个问题：
里面提到：当主服务器当机时，我们的应用程序虽然是不需做任何修改的，但在主服务器被备份服务器替换前，某些事务会丢失，这些可以作为正常的mysql错误来处理。
数据完整性校验：
测试主服务器停止后，备份服务器是否能够同步所有数据。
重启了刚才停止主服务器后，查看记录数
?
可以看到在插入1059条记录后被停止了。
现在看看备份服务器的记录数是多少，看看在主服务器当机后是否所有数据都能同步过来
?
大约经过了几十秒，才同步完，数据虽然不是立即同步过来，但没有丢失。
1.2、分片：如何支持可扩展性和负载均衡
fabric分片简介：当一台机器或一个组承受不了服务压力后，可以添加服务器分摊读写压力，通过Fabirc的分片功能可以将某些表中数据分散存储到不同服务器。我们可以设定分配数据存储的规则，通过在表中设置分片key设置分配的规则。另外，有些表的数据可能并不需要分片存储，需要将整张表存储在同一个服务器中，可以将设置一个全局组（Global Group）用于存储这些数据，存储到全局组的数据会自动拷贝到其他所有的分片组中。
?
4.Galera Cluster
?
简介：
Galera Cluster号称是世界上最先进的开源数据库集群方案
主要优点及特性：
真正的多主服务模式：多个服务能同时被读写，不像Fabric那样某些服务只能作备份用同步复制：无延迟复制，不会产生数据丢失热备用：当某台服务器当机后，备用服务器会自动接管，不会产生任何当机时间自动扩展节点：新增服务器时，不需手工复制数据库到新的节点支持InnoDB引擎对应用程序透明：应用程序不需作修改
?
架构及实现原理：
首先，我们看看传统的基于mysql Replication（复制）的架构图：
Replication方式是通过启动复制线程从主服务器上拷贝更新日志，让后传送到备份服务器上执行，这种方式存在事务丢失及同步不及时的风险。Fabric以及传统的主从复制都是使用这种实现方式。
而Galera则采用以下架构保证事务在所有机器的一致性：
客户端通过Galera Load Balancer访问数据库，提交的每个事务都会通过wsrep API 在所有服务器中执行，要不所有服务器都执行成功，要不就所有都回滚，保证所有服务的数据一致性，而且所有服务器同步实时更新。
缺点及限制：
由于同一个事务需要在集群的多台机器上执行，因此网络传输及并发执行会导致性能上有一定的消耗。所有机器上都存储着相同的数据，全冗余。若一台机器既作为主服务器，又作为备份服务器，出现乐观锁导致rollback的概率会增大，编写程序时要小心。不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…不支持XA Transaction
目前基于Galera Cluster的实现方案有三种：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。
我们采用较成熟、应用案例较多的Percona XtraDB Cluster。
应用案例：
超过2000多家外国企业使用：
?
?
包括：
?
集群部署架构：
| 功能 |
IP |
Port |
| Backing store(保存各服务器配置信息) |
200.200.168.24 |
3306 |
| Fabric 管理进程（Connector） |
200.200.168.24 |
32274 |
| HA Master 1 |
200.200.168.24 |
3306 |
| HA Master 2 |
200.200.168.25 |
3306 |
| HA Master 3 |
200.200.168.23 |
3306 |
?
4.1、测试数据同步
在机器24上创建一个表：
立即在25 中查看，可见已被同步创建
?
使用Java代码在24服务器上插入100条记录
立即在25服务器上查看记录数
可见数据同步是立即生效的。
4.2、测试添加集群节点
添加一个集群节点的步骤很简单，只要在新加入的机器上部署好Percona XtraDB Cluster，然后启动，系统将自动将现存集群中的数据同步到新的机器上。
现在为了测试，先将其中一个节点服务停止：
然后使用java代码在集群上插入100W数据
查看100w数据的数据库大小：
这时启动另外一个节点，启动时即会自动同步集群的数据：
启动只需20秒左右，查看数据大小一致，查看表记录数，也已经同步过来
?
5.对比总结
?
?
| ? |
MySQL Fabric |
Galera Cluster |
| 使用案例 |
2014年5月才推出，目前在网上暂时没搜索到有大公司的应用案例 |
方案较成熟，外国多家互联网公司使用 |
| 数据备份的实时性 |
由于使用异步复制，一般延时几十秒，但数据不会丢失。 |
实时同步，数据不会丢失 |
| 数据冗余 |
使用分片，通过设置分片key规则可以将同一张表的不同数据分散在多台机器中 |
每个节点全冗余，没有分片 |
| 高可用性 |
通过Fabric Connector实现主服务器当机后的自动切换，但由于备份延迟，切换后可能不能立即查询数据 |
使用HAProxy实现。由于实时同步，切换的可用性更高。 |
| 可伸缩性 |
添加节点后，需要先手工复制集群数据 |
扩展节点十分方便，启动节点时自动同步集群数据，100w数据（100M）只需20秒左右 |
| 负载均衡 |
通过HASharding实现 |
使用HAProxy实现负载均衡 |
| 程序修改 |
需要切换成jdbc:mysql:fabric的jdbc类和url |
程序无需修改 |
| 性能对比 |
使用java直接用jdbc插入10 |