一、系统概述:提供远程视频会议功能,用户注册后登录即可使用。用户可以查询历史会议安排记录,有好友和群组功能。注册用户在一千万以内,同时在线用户在100万以内。二、网络结构预想方案:
1、服务器网络结构大致如下:分两层,数据中心和业务控制层。数据中心由核心数据中心和异地灾难数据中心组成(两地配置相同),提供数据存储和数据访问服务,重要数据是用户注册信息。业务控制层由多个异地控制服务器组成,为最终用户提供服务。用户只能访问业务控制层。
2、两个数据中心均部署两台数据库服务器,实现双机热备,双机热备采用纯软件方式(节约成本)。
    同一数据中心的两个MySQL数据库互为主从数据库,即构成了主-主方式。核心数据中心的一个数据库也与灾难数据中心的一个数据库互为主从关系。并通过MySQL Proxy实现主从数据库同步,以及读写分离和连接池。
    当核心数据中心的其中一台出现故障时,另一台接管服务。当整个核心数据中心不能正常服务时,控制服务器连接到灾难中心 ,由灾难中心提供数据访问服务。
    数据中心会采用RAID磁盘阵列,并且定期人工使用移动介质备份。
3、数据访问接口服务运行在控制服务器上,直接远程访问MySQL数据库服务器,而不在数据库服务器做中间件(为了减少调用开销和减少开发工作量)。然后控制服务器中的业务处理层就可以直接调用数据访问接口了。三、存在的疑问:(只考虑数据中心,不考虑业务控制层。)
1、MySQL数据库备份和双机热备是不是有重复或者冲突了?因为数据库采用主从服务器方式,本身已经带有数据库备份功能了,而双机热备也有磁盘数据同步功能。其实,我认为数据中心重点是备份数据库,其他没有别的数据需要同步了,双机热备是用来保证高可用服务的,即其中一台服务器出故障时另外一台可以迅速接管服务。
2、既然设置了灾难中心,那么双机热备是不是浪费了?因为如果核心数据中心整个崩掉了,灾难中心就会启动来接管数据访问服务。再次强调,异地灾难中心重点是用来保证数据安全的,万一核心数据中心的数据丢失了,还可以从灾难中心获取。
3、由上一个疑问引出:这个异地灾难中心是否有必要,意义大不大?换句话说,核心数据中心数据完全丢失的可能性大不大?其实,发展初期灾难中心肯定还没有条件部署的,只是作为扩展。
4、两个数据中心之间数据库的互为主从关系能否实现,因为各个数据中心自己内部已经是互为主从关系了,多个主从关系会不会导致混乱?通过MySQL Proxy能否实现核心数据中心与灾难数据中心的同步?灾难中心的数据同步会不会对核心数据中心造成较大的性能下降?
5、对这样的结构没有太大的把握,不知道是否合理,也不敢十分肯定对其中的技术使用是否正确。特别是第3点关于远程访问数据库的。各位大牛请多多指教~四、参考资料:
mysql双机热备:http://blog.csdn.net/yuanyuan110_l/archive/2010/12/23/6094659.aspx
纯软件方式的双机热备方案深入分析:http://blogold.chinaunix.net/u/19239/showart_308514.html
双机热备:http://baike.baidu.com/view/132705.htm
MySQL 双机互备配置文档 :http://blog.csdn.net/zhangyunyue/archive/2010/04/02/5444899.aspx#_Toc257983274
用MySQL-Proxy实现读写分离:http://www.infoq.com/cn/news/2007/10/mysqlproxyrwsplitting

解决方案 »

  1.   

    关注,目前也遇到这问题。
    不过,我们的需求有点不同。
    要实现的是多主机,多从机。
    我们的打算是自己写程序来同步binlog。
      

  2.   

    http://mysql-mmm.org/startLZ担心的
    4、两个数据中心之间数据库的互为主从关系能否实现貌似mysql本身不支持这功能,上面那个项目提供了这功能。
    这个项目也可以:
    http://code.google.com/p/tungsten-replicator/
      

  3.   

    广域网里的mysql同步需要考虑网络问题引起的问题,比如延时很大。
    不到万不得以,不建议这么干,尤其是这么多用户同时在线。
    建议还是做中间层吧,由中间层再去做分发会更安全、可靠点。同时在中间层做数据库的监控和切换也更容易。
      

  4.   


    额,研究了几天,发现mysql本身是支持的。即masterA 和 masterB,互为主从,masterA下再接slaveA,masterB下也可以接slaveB。
    但是mysql不支持masterA挂掉后,把slaveA接到masterB下。因为这样会导致slaveA的数据再次复制。除非指定binlog的位置。
    这正是我们的需求。。
    看来要写的程序还是要写,跑不掉。。
      

  5.   

    masterA 和 masterB,互为主从,masterA下再接slaveA,masterB下也可以接slaveB——那masterA和slaveA还可以互为主从的吧?
    但是mysql不支持masterA挂掉后,把slaveA接到masterB下。——这个功能我们不需要。
    目前主要考虑的问题就是:灾难中心的数据同步会不会对核心数据中心造成较大的性能下降了。正如flybird66所说,要考虑网络延时问题。如果采用异步复制,一致性无法保证,因为核心数据中心挂掉后,控制层会连接到灾难中心去。如果是同步复制,数据同步肯定会拖累核心数据中心。
      

  6.   


    这个不行,因为主机只能配置一个。masterA已经配置主机是masterB了。
    多数是异步复制吧。同步效率应该比较低。
    不过mysql提供了个半异步复制功能。就是保证从机中有一个同步了数据才算写入。
      

  7.   

    关于第一个,确实是这样,master只能配一个。那么,如果我两个数据中心之间采用了互为主从的结构,各个数据中心的双机热备就无法采用互为主从结构了。
    也就是说是,图中的结构是有问题的!灰常感谢hengyunabc大侠的指正!半异步复制在同一数据中心数据同步速度应该没有问题。但是由于在核心数据中心整个宕掉的情况下,需要启用灾难数据中心作为临时的“核心数据中心”,也就是说必须要获得核心数据中心整个宕掉时的所有数据,显然半异步方式无法提供保障。
    看来两个数据中心的数据一致性和数据同步速度仍然无法兼顾,甚至能接受的折衷方案都没有~
      

  8.   

    通过相关的资料来看,之前没有搞清楚数据库备份和双机热备的关系。
    双机热备的作用是提供高可用性。双机热备备份的是服务而不是数据,跟数据没有一毛钱的关系,双机热备还需要额外的数据库备份方案。那么,数据库备份和双机热备都是需要的了。
    不过,各个数据中心内倒是可以考虑不组RAID,用MySQL Proxy组互为主从结构就行了。