数据库HA方案

12 2nd, 2009 | Posted by jacky | Filed under 大话技术

我们常用的HA方案有几种:一是用小型机和HA软件作双机热备,这种方案始终有一台设备处于空闲状态,设备利用率很低,而且必须用IBM,HP等厂商的硬件,代价昂贵。二是用Oracle的RAC来做HA,在Linux环境下,Oracle提供了全套的解决方案,是个不错的选择,不过最低也需要一套共享的存储设备。三是用Oracle DG,这种方案成本最低,但是无法做到故障时应用透明切换,我们也曾经尝试过用heartbeat配合DG failover来作一些尝试,但是在测试中发现,在极端情况下,可能存在丢失数据或者无法切换的可能性。

自从使用MySQL数据库以来,我们就一直探索MySQL的HA方案,目前应用最广泛的是用heartbeat作HA,利用MySQL双向复制技术,达到透明切换的目的。但是heartbeat并不是十分的稳定,而且切换的过程也比较长。

是否有更好的解决方案?首先要解决故障探测的问题,如果应用可以自己探测数据库状态,发现数据库出现问题时,可以切换到另外一台备机;其二主备库之间的数据同步问题,如果我们可以解析Oracle或者MySQL的日志,还原成SQL信息并应用到备机,这样就实现了logical standby或者MySQL复制的功能。利用这两个功能,我们可以实现一个更廉价更灵活的HA方案。

目前我们正在做三个工具,第一是日志解析工具,包括Oracle和MySQL,日志解析是将日志文件中的变化还原为SQL或者日志信息;第二是数据同步工具,主要负责将日志信息打包传输,并应用到目标数据库上;第三是数据库探测与路由工具,主要负责探测数据库状态,对应用做透明故障切换。

这个方案中,由于数据库不再有primary和standby之分,仅仅是应用端来作判断连接哪个数据库,所以故障切换的时间非常快,我们测试大概只需要10秒。但是数据同步可能存在一定的延时,也就是说数据库切换后,数据可能存在一定程度的丢失,但是我们可以在切换后再对数据进行补全,这个我们是可以接受的。利用这些工具,我们可以搭建出很多灵活的解决方案,并不一定要依赖IBM,Oracle的解决方案,毕竟适合我们的才是最好的方案。

目前这个方案还在开发与验证中,欢迎大家和我探讨HA这方面的问题。

–EOF–

标签: ,
  1. oradbHome
    12 3rd, 200913:34

    关注

  2. P.Linux
    12 3rd, 200923:19

    对于MySQL,mysqlbinlog这个工具我觉得已经还可以了吧,能够按位置和时间来导出成操作的SQL。用这个恢复过一次数据灾难。
    Replication做镜像的速度有时候还是蛮慢的,而且不可控,不能准确的掌握同步到哪里了。自己传输日志的想法有点提示,把Master的日志按间隔打包发送到Slave解析为SQL执行,这样过程就可控了,至少可以知道执行了哪些操作,在没有完成导入的时候就不到Slave上读。
    关于故障探测,这个问题我想了一段时间,从Cacti和Ganglia的探测方式中,得到一点启发,Cacti轮询客户机,占用资源很多,由于莫名其妙的网络原因或者客户机负载高,还经常获取不到命名还可以访问的客户机的信息。而Ganglia通过在客户机跑一个进程,给监控机发送信息,这样监控机只要监听客户机发来的信息即可,这样把轮询压力分担在每个机器上,几乎可以忽略不计,并且客户机负载很高时也能更好的发出信息,监控机可以更准确的获取到客户机的活动状态,设置心跳间隔也可以让故障转移时间可控。
    所以故障探测转移这方面,我觉得需要在每个节点跑一个进程,给调度机发送心跳,靠调度机去轮询,效率很低的说。
    最近越来越觉得不能太依赖数据库,充分发挥人的脑子在应用程序上多动手获得的效果能好得多。

  3. jacky
    12 3rd, 200923:21

    现在我们也是越来越依赖应用的架构,数据库能做的已经越来越少了。