Oracle / MySQL数据库高可用解决方案：数据一致性问题等探讨
数据库的高可用已成了企业信息化建设的重中之重。如何设计数据库的高可用方案，遇到了数据库高可用方面的问题如何解决显得非常重要。
社区最近组织了线上交流“Oracle和MySQL数据库高可用解决方案和问题探讨”，从活动活跃度来看，大家对这方面非常重视。现有由社区专家岳彩波总结本次活动中值得参考的分享。
一、MySQL各种高可用方案分别有什么优点和缺点？
任何一种高可用方案，都存在一些缺点，有些缺点是可以容忍的，有些缺点是不可容忍的，mysql目前来看，各种高可用方案都差不多，都存在一些弊端，但是我们作为技术人员，存在的价值，就是尽可能的想办法解决这些弊端。在选用方案的时候要根据实际的业务环境和公司的能力大小来做决定。在分享的文档中，介绍了五类（每一类方案包括若干种具体实施方案）高可用方案的优点和缺点，仅供大家参考。
文档地址：http://www.talkwithtrend.com/Article/215665
二、超大数据库的在线迁移问题和归档问题
随着信息的大爆炸，互联网各种业务的发展，超大、超级大的数据库都已经出现，先说一下迁移问题，oracle的迁移有很多种方案，迁移T级数据目前有XTTS等官方推荐的一些方案，PB级数据那就需要专业团队来根据实际情况来做一个完善的迁移方案。目前我也没接触过这种数据库的迁移，希望能和大家共同学习。在来说一下mysql超大的数据库，T级以上的单数据库在生产环境中不是很多，所以迁移的难点可能就是在于分库分表，数据库一致等问题，在这里分享几个可用方案：
方案1
In this case, normally, the best solution is a mysqldump using the --tab option like this:
mysqldump --tab=/path/to/serverlocaldir --single-transaction <database> table_a
tab option produce 2 file, one file -table_a.sql- that contains only the table create statement and the oher file -table_a.txt- contains tab-separated data.
Now you can create your new table
create table table_b like table_a;
Then you simply load data in your new table via LOAD DATA without care for the table's name.
LOAD DATA INFILE '/path/to/serverlocaldir/table_a.txt'
INTO TABLE table_b FIELDS TERMINATED BY '\t' ...
LOAD DATA is usually 20 times faster than using INSERT statements.
LOAD DATA速度比INSERT语句要快，这里其实倒入也可以使用mysqlimport命令方案2
I recently moved a 30GB database with the following stragegy:
Old Server
Stop mysql server
Copy contents of datadir to another location on disk (~/mysqldata/*)
Start mysql server again (downtime was 10-15 minutes)
compress the data (tar -czvf mysqldata.tar.gz ~/mysqldata)
copy the compressed file to new server
New Server
install mysql (don't start)
unzip compressed file (tar -xzvf mysqldata.tar.gz)
move contents of mysqldata to the datadir
Make sure your innodb_log_file_size is same on new server, or if it's not, don't copy the old log files (mysql will generate these)
Start mysql
这种方法就是直接复制数据库的文件结构，要求必须相同的mysql版本，和相同的配置才可以用这种方法
方案3
If you are considering migrating to another DB Server with the exact same version of MySQL, you may want torsync the datadir from the old server to the new server.
This will work regardless of InnoDB file layout or even the presence of MyISAM tables.
install the same version of mysql on ServerB that ServerA has
On ServerA, run RESET MASTER; to erase all binary logs before the rsycn process. If binary logging is not enabled, you can skip this step.
On ServerA, run SET GLOBAL innodb_max_dirty_pages_pct = 0; from mysql and about 10 minutes (This purges dirty pages from the InnoDB Buffer Pool. It also helps perform a mysql shutdown faster) If your database is all MyISAM, you can skip this step.
rsync /var/lib/mysql of ServerA to /var/lib/mysql on ServerB
Repeat Step 3 until an rsync takes less than 1 minute
service mysql stop on ServerA
Perform one more rsync
scp ServerA:/etc/my.cnf to ServerB:/etc/.
service mysql start on ServerB
service mysql start on ServerA (optional)
Essentially, here is what such a script would like this
其实这个跟方案2是一样的。只是操作方法不同而已，当然要求也是一样的。
三、oracle和mysql数据库在高可用中数据一致性问题
oracle的数据一致性这里就不用说了，已经做的很完善，很少出现问题，出现问题也有完整的方案来解决，主要说一下mysql数据的一致性。就说一下最简单的mysql主从复制方案吧，供大家参考一下。
现在常用的MySQL高可用方案，十有八九是基于MySQL的主从复制（replication）来设计的，包括常规的一主一从、双主模式，或者半同步复制（semi-sync replication）。
我们常常把MySQL replication说成是MySQL同步（sync），但事实上这个过程是异步（async）的。大概过程是这样的：
在master上提交事务后，并且写入binlog，返回事务成功标记；
将binlog发送到slave，转储成relay log；
在slave上再将relay log读取出来应用。
步骤1和步骤3之间是异步进行的，无需等待确认各自的状态，所以说MySQL replication是异步的。
MySQL semi-sync replication在之前的基础上做了加强完善，整个流程变成了下面这样：
首先，master和至少一个slave都要启用semi-sync replication模式；
某个slave连接到master时，会主动告知当前自己是否处于semi-sync模式；
在master上提交事务后，写入binlog后，还需要通知至少一个slave收到该事务，等待写入relay log并成功刷新到磁盘后，向master发送“slave节点已完成该事务”确认通知；
master收到上述通知后，才可以真正完成该事务提交，返回事务成功标记；
在上述步骤中，当slave向master发送通知时间超过rpl_semi_sync_master_timeout设定值时，主从关系会从semi-sync模式自动调整成为传统的异步复制模式。
半同步复制看起来很美好有木有，但如果网络质量不高，是不是出现抖动，触发上述第5条的情况，会从半同步复制降级为普通复制；此外，采用半同步复制，会导致master上的tps性能下降非常严重，最严重的情况下可能会损失50%以上。
这样来看，除非需要非常严格保证数据一致性等迫不得已的场景，就不太建议使用半同步复制了。当然了，事实上我们也可以通过加强程序端的逻辑控制，来避免主从数据不一致时发生逻辑错误，比如说如果在从上读取到的数据和主不一致的话，那么就触发主从间的一次数据修复工作。或者，我们也可以用 pt-table-checksum & pt-table-sync 两个工具来校验并修复数据，只要运行频率适当，是可行的。
真想要提高多节点间的数据一致性，可以考虑采用PXC方案。现在已知用PXC规模较大的有qunar、sohu，如果团队里初期没有人能比较专注PXC的话，还是要谨慎些，毕竟和传统的主从复制差异很大，出现问题时需要花费更多精力去排查解决。
如何保证主从复制数据一致性
上面说完了异步复制、半同步复制、PXC，我们回到主题：在常规的主从复制场景里，如何能保证主从数据的一致性，不要出现数据丢失等问题呢？
在MySQL中，一次事务提交后，需要写undo、写redo、写binlog，写数据文件等等。在这个过程中，可能在某个步骤发生crash，就有可能导致主从数据的不一致。为了避免这种情况，我们需要调整主从上面相关选项配置，确保即便发生crash了，也不能发生主从复制的数据丢失。
在master上修改配置
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
上述两个选项的作用是：保证每次事务提交后，都能实时刷新到磁盘中，尤其是确保每次事务对应的binlog都能及时刷新到磁盘中，只要有了binlog，InnoDB就有办法做数据恢复，不至于导致主从复制的数据丢失。在slave上修改配置
master_info_repository = "TABLE"
relay_log_info_repository = "TABLE"
relay_log_recovery = 1
上述前两个选项的作用是：确保在slave上和复制相关的元数据表也采用InnoDB引擎，受到InnoDB事务安全的保护，而后一个选项的作用是开启relay log自动修复机制，发生crash时，会自动判断哪些relay log需要重新从master上抓取回来再次应用，以此避免部分数据丢失的可能性。
通过上面几个选项的调整，就可以确保主从复制数据不会发生丢失了。但是，这并不能保证主从数据的绝对一致性，因为，有可能设置了ignore\do\rewrite等replication规则，或者某些SQL本身存在不确定因素，或者人为在slave上修改数据，最终导致主从数据不一致。这种情况下，可以采用pt-table-checksum 和 pt-table-sync 工具来进行数据的校验和修复。
四、选用高可用方案的标准
这个问题其实我已经在活动中回答过了，这里借用一下之前的回答来做一个总结。
1、稳定可靠(High-Availability)
数据库保存的是企业最重要的数据，是企业应用的核心，稳定可靠的数据库可以保证企业的应用常年运行，而不会因为数据库的宕机而遭受损失。企业的信息化可以促进生产力，但如果选择了不稳定产品，经常影响业务生产的正常运营，则实际效果很可能是拖了企业的后退。无论是计划中（数据库维护等正常工作）还是意外的宕机都将给企业带来巨大的损失，这意味着企业要减低收入、要降低生产力、要丢失客户、要在激烈的企业竞争中丢失信心。信息系统的稳定可靠是由多方面的因素构成的，包括网络、主机、操作系统、数据库以及应用软件等几方面，这些因素互相之间又有一定的依赖关系，因此，在企业信息化的选型中要通盘考虑这些问题。在数据库方面主要看数据库要具备灾难恢复、系统错误恢复、人为操作错误恢复等功能，同时要尽量降低数据库的计划内维护宕机时间。
2、可扩展(High-Scalability)
企业的应用是不断深入和扩展的，数据量和单位时间的事务处理量都会逐渐增加。如果要求企业购置一套信息系统足以满足未来若干年发展的需要显然是不恰当的，因为这实际意味着企业要多花很多钱而不能发挥信息设备的最大效能，造成资源的浪费。比较好的解决办法就是企业先购置一套配置较低，功能适用的系统，当未来业务有需要时可以方便的对系统进行扩展，使系统的处理能力逐步增加满足业务处理的需求。落实到数据库就是要选择具有良好的伸缩性及灵活的配置功能的产品，无论是主机系统的内存或硬盘方面的扩展还是集群系统的扩展，都能够被数据库利用，从而提高系统的处理能力。
3、安全性(Security)
数据库的安全性是指保护数据库以防止不合法的使用造成的数据泄露、更改或破坏。安全性问题不是数据库系统独有的，所有计算机系统都有这个问题。只是在数据库系统中保存着大量重要的数据，而且为许多最终用户共享使用，从而安全问题更为突出。系统安全保护措施是否有效是数据库系统的重要指标之一。 数据库的安全控制主要通过用户标识与鉴别、存取控制、视图机制、审计、数据加密等机制完成。
4、丰富的开发工具
无论是优秀的硬件平台还是功能强大的数据库管理系统，都不能直接解决最终用户的应用问题，企业信息化的工作也要落实到开发或购买适合企业自身管理的应用软件。目前流行的数据库管理系统大都遵循统一的接口标准，所以大部分的开发工具都可以面向多种数据库的应用开发。当然，数据库厂商通常都有自己的开发工具，例如SYBASE公司的PowerBuilder，Oracle公司的Developer2000，以及Ms的VisualStudio。这些开发工具各有利弊，但无疑选择和数据库同一个厂商的产品会更有利于应用软件的开发以及将来得到统一的技术支持。
5、服务质量
在现今信息高度发达的竞争中，数据库厂商完全靠产品质量打动用户的年代已不复存在，各数据库产品在质量方面的差距逐渐缩小，而用户选择产品的一个重要因素就是定位在厂家的技术服务方面。因为在你购买了数据库系统之后，你面临着复杂的软件开发，数据库的维护，数据库产品的升级等等，你需要得到数据库厂商的培训，各种方式的技术支持（电话、用户现场）和咨询。数据库厂家的服务质量的好坏将直接影响到企业信息化建设的工作。
五、超大数据备份
超大数据备份其实和迁移归档都能放在一起说，这里单独拿出来总结一下就是因为备份和迁移毕竟是两个概念，大家关注的也比较多。
数据备份是容灾的基础，有了备份不等于万事大吉。因为备份的数据可以还会有其他因素造成的数据损坏，如地震、火灾等，对于这些企业应该在数据容灾方面提升能力，来进一步应对数据抵抗潜在不安全因素的能力。当然，数据备份还是最基础的形式，没有数据备份，任何容灾都没有现实意义。目前来看，主要的数据备份方式如下：
定期磁带备份：包括远程磁带库、光盘库备份和远程关键数据+磁带备份。
数据库备份：就是在与主数据库所在生产机相分离的备份机上建立主数据库的一个拷贝。
网络数据：这种方式是对生产系统的数据库数据和所需跟踪的重要目标文件的更新进行监控与跟踪，并将更新日志实时通过网络传送到备份系统，备份系统则根据日志对磁盘进行更新。
远程镜像：通过高速光纤通道线路和磁盘控制技术将镜像磁盘延伸到远离生产机的地方，镜像磁盘数据与主磁盘数据完全一致，更新方式为同步或异步。
这些措施能够在系统发生故障后进行系统恢复。但是这些措施一般只能处理计算机单点故障，对区域性、毁灭性灾难则束手无策，也不具备灾难恢复能力。所以我们就需要建立异地容灾中心，做数据的远程备份，在灾难发生之后要确保原有的数据不会丢失或者遭到破坏。建立的异地容灾中心可以简单地把它理解成一个远程的数据备份中心。数据容灾的恢复时间比较长，但是相比其他容灾级别来讲它的费用比较低，而且构建实施也相对简单。主要的实施方法如下：
实时复制：当主中心的数据库内容被修改时，备份中心的数据库内容实时地被修改，此种复制方式对网络可靠性要求高。
定时复制：当主中心的数据库内容被修改时，备份中心的数据库内容会按照时间间隔，周期性地按照主中心的更新情况进行刷新，时间间隔可长(几天或几个月)可短(几分钟或几秒钟)。
存储转发复制：当主中心的数据库内容被修改时，主中心的数据库服务器会先将修改操作Log存储于本地，待时机成熟再转发给备份中心。
岳彩波，擅长Oracle、Mysql，有丰富的数据库维护、调优经验，曾服务于金融行业，目前专注于第三方支付领域。
个人主页：http://www.talkwithtrend.com/home/space.php?p=blog&uid=899573
点击阅读原文可以进入社区高可用主题，还有更多文章、资料及相关问答
长按二维码关注公众号AIX专家俱乐部