精华内容
下载资源
问答
  • 主要介绍了PHP访问数据库集群的方法,结合实例形式总结分析了三种常见的PHP访问数据库集群的技巧,需要的朋友可以参考下
  • 随着互联网技术的高速发展以及其高度写比特性,数据库集群方案已是处理数据的 首选。由于技术壁垒以及经济原因,商用数据库集群方案往往对于中小型企业并不友好。 而开源的 MySQL 以其简单易用、经济方便的特性在...
  • 为了提升数据库的性能,本课程围绕MyCAT来实现对业务数据库的分库分表、读写分离,构建一个以MyCAT为核心的数据库集群架构,以企业级方案解决数据库出现的性能问题,做个数据库高手!
  • 一切都从为高效的PostgreSQL数据集群的框架选取硬件开始,然后从一些管理员通常面对的真实问题的解决来缩短宕机时间,接着,我们加入数据库监控到软件栈中,使用collectd, Nagios, 和Graphite。没有加入复制机制的...
  • 第一节数据库集群技术的现状目前数据库集群系统应用得比较成功,应用范围比较广泛的是:Oracle公司的Oracle9与IBM公司DB2。Oracle9采用Shared-storage的技术,DB2选择了Shared-nothing的技术,二者各有长短。最新的...
  • 教程名称:Oracle RAC数据库集群视频教程(10讲)课程目录:【】1.OracleRAC集群体系结构_drm【】10.测试OracleRAC数据库集群功能【】2.安装OracleRAC数据库(一)【】3.安装OracleRAC数据库(二)_drm【】4.安装...
  • 针对这一情况,提出在现有硬件的基础上利用JDBC规范与MySQL Replication实现数据库集群从而解决数据访问瓶颈。其主要方法是在进行JDBC连接之前实现负载均衡,所有SQL请求由负载均衡器进行统一调度。在数据库端利用...
  • 数据库集群

    2016-11-16 17:46:29
    MySQL集群的方法
  • 数据库集群方案

    2018-01-09 11:34:21
    数据库集群方案 ppt 有需要的同学拿去用。。。。。。。。。。。
  • SQL_Server_数据库集群

    2013-10-30 09:37:22
    SQL_Server_数据库集群搭建
  • 简单使用Mysql-Cluster-7.5搭建数据库集群 简单使用Mysql-Cluster-7.5搭建数据库集群
  • 教程视频:1、一个彻底开源的,面向企业应用开发的大数据库集群 2、支持事务、ACID、可以替代MySQL的加强版数据库 3、一个可以视为MySQL集群的企业级数据库,用来替代昂贵的Oracle集群 4、一个融合内存缓存技术、...
  • 数据库集群是提高数据库系统事务吞吐率,降低响应时间的有效机制。研究并实现了一种通用的无共享的数据库集群,集群由异构的节点数据库组成。系统支持水平数据划分和数据复制,系统具有性价比高,可扩展性好等特点。
  • 数据库复制是指频繁的将数据从一个节点(服务器上的一个数据库)复制到另一个节点,可以将数据库复制系统看作一个分布式数据库,但是其中所有节点共享相同的信息。这类系统也称为数据库集群
  • 达梦数据库集群

    千次阅读 2020-08-17 14:25:12
    学完达梦DCP课程后简单梳理了达梦集群相关的几个概念——DSC、MPP、数据守护、读写分离,和数据守护的详细搭建方法,供参考。 DMdsc共享存储集群: 类似于oracle rac,具有高可用性和高伸缩性的特征,可提供横向...

    学完达梦DCP课程后简单梳理了达梦集群相关的几个概念——DSC、MPP、数据守护、读写分离,和数据守护的详细搭建方法,供参考。

    DMdsc共享存储集群:

    类似于oracle rac,具有高可用性和高伸缩性的特征,可提供横向扩展,实现超单一服务器的功能。其提升了错误恢复能力,并且随着系统增长而逐步扩展。一旦系统发生失败,该集群对用户保证最高可用性,保障关键业务数据不被丢失。拓扑图如下图所示:

    在配置DMdsc时,需配置两套网络,一套用于提供对外服务,分配虚拟IP,并实现故障保障以及网络负载。另一套提供对内部节点的心跳检测,以便做故障检测,增强了系统的容错性。再则配置共享磁盘,该磁盘可以是网络附加磁盘(NAS)、存储区域磁盘(SAN)或SCSI磁盘。对于磁盘数据的读写,达梦数据库提供了DMASM,一个专用的分布式文件系统。

    测试时发现,DSC集群运行时DMSERVER必须活动,如果服务停止,则集群服务停止,但端口停止活动,集群可以换节点运行。

    DMmpp非共享存储集群:

    DM7采用完全对等无共享(share-nothing)的MPP架构,支持SQL并行处理,可自动化分区数据和并行查询,无I/O冲突。MPP系统工作起来就像是一台单独的计算机,由于采用自动化的并行处理,执行速度比传统的单节点数据库大大提高。拓扑图如下图所示:

    DMmpp集群中,每个数据守护系统作为一个节点,每个节点分别有主服务器和备服务器两台机器,当主服务器挂掉之后,备服务器会承担起工作任务,直到主服务器恢复为止。与DMdsc不同,mpp集群数据不存储于共享存储,而存储在本地的磁盘。因此数据将分布于每个节点之中。

    数据守护:

    达梦数据守护的实现原理主要是将主库产生的Redo日志传输到备库,备库接收并重做应用Redo日志,从而实现备库与主库的数据同步。其主要核心思想在于监控数据库转态,获取主、备库数据同步情况,为Redo日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。

    读写分离:

    读写分离集群由一个主库以及一个或者多个配置了即时归档的备库组成,其主要目标是保障数据库可用性基础上,实现读,写操作的自动分离,进一步提升数据库的业务支撑能力。读写分离集群通过即时归档机制保证主、备数据一致性,并配合达梦数据库管理系统的各种接口(JDBC、DPI等),将只读操作自动分流到备库,有效降低主库的负载,提升系统的吞吐量。

    数据守护的具体搭建方法:

    • 数据守护部署前准备

    需要保持主机网络互通,防火墙关闭,时间一致!

     

    • 关防火墙

    iptables -F

    service iptables status/stop

    chkconfig iptables –list/off

    用iptables -L检查,关闭后应为:

    [root@bogon ~]# iptables -L

    Chain INPUT (policy ACCEPT)

    target     prot opt source               destination        

    Chain FORWARD (policy ACCEPT)

    target     prot opt source               destination        

    Chain OUTPUT (policy ACCEPT)

    target     prot opt source               destination  

     

    • 关闭selinux

    vi /etc/selinux/config

    SELINUX=disabled

     

    • 时间

    date -s “2020-08-06 10:10:10

     

     

    安装数据库

    初始化实例

     

    • 规划

    主机:192.168.170.135

    备机:192.168.170.136

    数据库名:DAMENG

     

    实例名

    Port_num

    Dw_port

    Mal_port

    Mal_dw_port

    主库

    GRP1——RT——01

    5236

    5239

    5237

    5238

    备库

    GRP1——RT——02

    5236

    5239

    5237

    5238

     

    • 数据准备

    主库安装好数据库实例,备库安装好数据库

    将主库的数据备份还原到备机上

    1. 正常关闭主数据库

    2. 进行脱机备份

    ./dmrman CTLSTMT="BACKUP DATABASE '/dm7/data/DAMENG/dm.ini' FULL TO BACKUP_FILE1 BACKUPSET '/dm7/backup/BACKUP_FILE_01'"

    3. 拷贝备份文件到备库所在机器

     scp /dm7/backup/BACKUP_FILE_01/*.*  192.168.170.135:/dm7/backup/BACKUP_FILE_01

    第一个路径是主机,第二个路径是备机,把主机上的所有文件*.*拷贝到备机上

    4. 在备机上执行脱机数据库还原与恢复

    ./dmrman CTLSTMT="RESTORE DATABASE '/dm7/data/DAMENG/dm.ini' FROM BACKUPSET '/dm7/backup/BACKUP_FILE_01'"

    ./dmrman CTLSTMT="RECOVER DATABASE '/dm7/data/DAMENG/dm.ini' FROM BACKUPSET

    '/dm7/backup/BACKUP_FILE_01'"

    这两步操作成功后有成功提示

    ./dmrman CTLSTMT="RECOVER DATABASE '/dm7/data/DAMENG/dm.ini' UPDATE DB_MAGIC"

    正常操作,中间对数据库不操作,此步骤提示***魔数不更新

     

    5 配置主库

    5.1配置 dm.ini

    #实例名,建议使用“组名_守护环境_序号”的命名方式,总长度不能超过 16

    INSTANCE_NAME = GRP1_RT_01

    PORT_NUM = 5236 #数据库实例监听端口

    DW_PORT = 5239 #守护环境下,监听守护进程连接端口

    ALTER_MODE_STATUS = 0  #不允许手工方式修改实例模式/状态/OGUID

    ENABLE_OFFLINE_TS = 2  #不允许备库 OFFLINE 表空间

    MAL_INI = 1  #打开 MAL 系统

    ARCH_INI = 1 #打开归档配置

    RLOG_SEND_APPLY_MON = 64 #统计最近 64 次的日志发送信息

     

    5.2配置 dmmal.ini

    MAL_CHECK_INTERVAL = 5 #MAL 链路检测时间间隔

    MAL_CONN_FAIL_INTERVAL = 5 #判定 MAL 链路断开的时间

    [MAL_INST1]

    MAL_INST_NAME = GRP1_RT_01 #实例名,和 dm.ini 中的 INSTANCE_NAME 一致

    MAL_HOST = 192.168.2.28 #MAL 系统监听 TCP 连接的 IP 地址

    MAL_PORT = 5237 #MAL 系统监听 TCP 连接的端口

    MAL_INST_HOST = 192.168.1.28 #实例的对外服务IP地址

    MAL_INST_PORT = 5236 #实例的对外服务端口和dm.ini中的PORT_NUM一致

    MAL_DW_PORT = 5238 #实例本地的守护进程监听 TCP 连接的端口 

    [MAL_INST2]

    MAL_INST_NAME = GRP1_RT_02

    MAL_HOST = 192.168.2.38

    MAL_PORT = 5237

    MAL_INST_HOST = 192.168.1.38

    MAL_INST_PORT = 5236

    MAL_DW_PORT = 5238

     

    5.3配置 dmarch.ini

    [ARCHIVE_REALTIME]

    ARCH_TYPE = REALTIME #实时归档类型

    ARCH_DEST = GRP1_RT_02 #实时归档目标实例名

    [ARCHIVE_LOCAL1]

    ARCH_TYPE = LOCAL #本地归档类型

    ARCH_DEST = /dm7/arch #本地归档文件存放路径

    ARCH_FILE_SIZE = 128 #单位 Mb,本地单个归档文件最大值

    ARCH_SPACE_LIMIT = 0 #单位 Mb,0 表示无限制,范围 1024~4294967294M

     

    5.4配置 dmwatcher.ini

    [GRP1]

    DW_TYPE = GLOBAL #全局守护类型

    DW_MODE = AUTO #自动切换模式

    DW_ERROR_TIME = 10 #远程守护进程故障认定时间

    INST_RECOVER_TIME = 60 #主库守护进程启动恢复的间隔时间

    INST_ERROR_TIME = 10 #本地实例故障认定时间

    INST_OGUID = 453331 #守护系统唯一OGUID 值

    INST_INI = /dm7/data/DAMENG/dm.ini   #dm.ini配置文件路径

    INST_AUTO_RESTART = 1 #打开实例的自动启动功能

    INST_STARTUP_CMD = /dm7/bin/dmserver #命令行方式启动

    RLOG_SEND_THRESHOLD = 0 #指定主库发送日志到备库的时间阀值,默认关闭

    RLOG_APPLY_THRESHOLD = 0 #指定备库重演日志的时间阀值,默认关闭

     

    5.5配置 dmwatcher.ctl

    ./dmctlcvt TYPE=3 SRC=/dm7/data/DAMENG/dmwatcher.ini DEST=/dm7/data

    生成的dmwatcher.ctl文件会放在/dm7/data文件的GRP1文件夹中,需要在GRP1路径下使用cp dmwatcher.ctl /dm7/data/DAMENG,放到实例文件夹中

     

    5.6启动主库

    以mount 方式启动主库

    ./dmserver /dm7/data/DAMENG/dm.ini mount

     

    5.7设置 OGUID

    SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

    SQL>sp_set_oguid(453331);

    SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

     

    5.8修改数据库模式

    SQL>alter database primary;

     

    6配置备库

    6.1配置dm.ini

    INSTANCE_NAME = GRP1_RT_02

    PORT_NUM = 5236 #数据库实例监听端口

    DW_PORT = 5239 #守护环境下,监听守护进程连接端口

    DW_ERROR_TIME = 60 #接收守护进程消息超时时间

    ALTER_MODE_STATUS = 0 #不允许手工方式修改实例模式/状态

    ENABLE_OFFLINE_TS = 2 #不允许备库 OFFLINE 表空间

    MAL_INI = 1 #打开 MAL 系统

    ARCH_INI = 1 #打开归档配置

    RLOG_SEND_APPLY_MON = 64 #统计最近 64 次的日志重演信息

     

    6.2 配置dmmal.ini

    MAL_CHECK_INTERVAL = 5 #MAL 链路检测时间间隔

    MAL_CONN_FAIL_INTERVAL = 5 #判定 MAL 链路断开的时间

    [MAL_INST1]

    MAL_INST_NAME = GRP1_RT_01 #实例名,和 dm.ini 中的 INSTANCE_NAME 一致

    MAL_HOST = 192.168.2.28 #MAL 系统监听 TCP 连接的 IP 地址

    MAL_PORT = 5237 #MAL 系统监听 TCP 连接的端口

    MAL_INST_HOST = 192.168.1.28 #实例的对外服务 IP 地址

    MAL_INST_PORT = 5236 #实例的对外服务端口,和 dm.ini 中的 PORT_NUM 一致

    MAL_DW_PORT = 5238 #实例对应的守护进程监听 TCP 连接的端口

    [MAL_INST2]

    MAL_INST_NAME = GRP1_RT_02

    MAL_HOST = 192.168.2.38

    MAL_PORT = 5237

    MAL_INST_HOST = 192.168.1.38

    MAL_INST_PORT = 5236

    MAL_DW_PORT = 5238

     

    6.3 配置 dmarch.ini

    [ARCHIVE_REALTIME]

    ARCH_TYPE = REALTIME #实时归档类型

    ARCH_DEST = GRP1_RT_01 #实时归档目标实例名

    [ARCHIVE_LOCAL1]

    ARCH_TYPE = LOCAL #本地归档类型

    ARCH_DEST = /dm7/data/DAMENG/arch #本地归档文件路径

    ARCH_FILE_SIZE = 128 #单位 Mb,本地单个归档文件最大值

    ARCH_SPACE_LIMIT = 0 #单位 Mb,0 表示无限制,范围 1024~4294967294M

     

    6.4配置 dmwatcher.ini

    [GRP1]

    DW_TYPE = GLOBAL #全局守护类型

    DW_MODE = AUTO #自动切换模式

    DW_ERROR_TIME = 10 #远程守护进程故障认定时间

    INST_RECOVER_TIME = 60 #主库守护进程启动恢复的间隔时间

    INST_ERROR_TIME = 10 #本地实例故障认定时间

    INST_OGUID = 453331 #守护系统唯一OGUID 值

    INST_INI = /dm7/data/DAMENG/dm.ini   #dm.ini配置文件路径

    INST_AUTO_RESTART = 1 #打开实例的自动启动功能

    INST_STARTUP_CMD = /dm7/bin/dmserver #命令行方式启动

    RLOG_SEND_THRESHOLD = 0 #指定主库发送日志到备库的时间阀值,默认关闭

    RLOG_APPLY_THRESHOLD = 0 #指定备库重演日志的时间阀值,默认关闭

     

    6.5 配置 dmwatcher.ctl

    同一个守护进程组,必须使用同一份 dmwatcher.ctl 文件,这里直接拷贝配置主库时已经生成的 dmwatcher.ctl 到本地数据文件目录/dm7/data/DAMENG。

     

    6.6 以 mount 方式启动备库

    ./dmserver /dm7/data/DAMENG/dm.ini mount

     

    6.7 设置 OGUID

    sp_set_oguid(453331);

     

    6.8修改数据库模式

    SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1); ----第 1 步

    SQL>alter database standby; ----第 2 步

    SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0); ----第 3 步

     

    7配置监视器

    由于主库和实时备库的守护进程配置为自动切换模式,因此这里选择配置确认监视器。

    和普通监视器相比,确认监视器除了相同的命令支持外,在主库发生故障时,能够自动通知

    实时备库接管为新的主库,具有自动故障处理的功能

    修改 dmmonitor.ini 配置确认监视器,其中 MON_DW_IP 中的 IP 和 PORT 和dmmal.ini 中的 MAL_HOST 和 MAL_DW_PORT 配置项保持一致。

     

    MON_DW_CONFIRM = 1 #确认监视器模式

    MON_LOG_PATH = /dm7/data/log #监视器日志文件存放路径

    MON_LOG_INTERVAL = 60 #每隔 60s 定时记录系统信息到日志文件

    MON_LOG_FILE_SIZE = 32 #每个日志文件最大 32M

    MON_LOG_SPACE_LIMIT = 0 #不限定日志文件总占用空间

    [GRP1]

    MON_INST_OGUID = 453331 #组 GRP1 的唯一 OGUID 值 #以下配置为监视器到组 GRP1 的守护进程的连接信息,以“IP:PORT”的形式配置

    #IP 对应 dmmal.ini 中的 MAL_HOST,PORT 对应 dmmal.ini 中的 MAL_DW_PORT

    MON_DW_IP = 192.168.2.28:5238

    MON_DW_IP = 192.168.2.38:5238

     

    8、启动守护进程(主备机)

    启动/dm7/bin/下工具dmwatcher

    ./dmwatcher /dm7/data/DAMENG/dmwatcher.ini

     

    9、启动监视器

    ./dmmonitor /dm7/dmmonitor.ini

    展开全文
  • 数据库集群技术

    千次阅读 2016-03-29 09:11:29
    1.数据库集群的作用:  理想的数据库集群应该可以做到以下几点:  ◆ 在需要更高数据库处理速度的时候,我们只需简单增加数据库服务器就可以了。这样可以大大减小硬件投资的风险,而且大大提高现有服务的质量...
    先引用几段文章: 
    1.数据库集群的作用: 
    理想的数据库集群应该可以做到以下几点: 

    ◆      在需要更高数据库处理速度的时候,我们只需简单增加数据库服务器就可以了。这样可以大大减小硬件投资的风险,而且大大提高现有服务的质量。 

    ◆     在任何时刻需要有多个随时可用的实时同步数据服务。为了防灾,最好有多个异地的同步数据服务。这不光会大大增加数据可用性,还会有意想不到的更高数据库处理速度的效益。 

    ◆       除了密码保护之外,我们最好能控制企业内部对数据库的非法访问。 

    ◆     数据集的可扩性可能是最简单的要求了。但是,用增加数据库服务器的办法来扩大数据集对数据可用性会产生负面影响。如果没有数据冗余,那么每增加一台服务器,整个系统的可用性就会成倍地降低。最好的结果是我们能任意增大数据集而没有对可用性的负面影响。 

    2.MSCS作用: 

    MSCS解决方案可以采用主动/被动模式工作。在同一时间集群中只有一个节点是主动的,主动服务器存储着集群内的全部资源,并不断将数据写入共享硬盘,这就是所谓的quorum驱动器。它可以在故障恢复时,将共享状态信息从一个节点转移到另一个节点。定时的发送信号会通过服务器间的专用网传递,当处于被动模式的服务器没有受到这个信号,就认为主动服务器已经失效。此时,它便开始接管集群资源,并从quorum分区上读取状态信息。 

    3.软件实现SQL Server 2005的负载均衡 

    中间层 

    实现数据库的负载均衡技术,首先要有一个可以控制连接数据库的控制端。在这里,它截断了数据库和程序的直接连接,由所有的程序来访问这个中间层,然后再由中间层来访问数据库。这样,我们就可以具体控制访问某个数据库了,然后还可以根据数据库的当前负载来调整每次连接到哪个数据库。好处在两个方面:首先,它成功地将数据库放到了内网之中,更好地保护了数据库的安全性。如果数据库也在公网上,1433端口是很容易被攻击的,所以要保护数据库与之的连接,就用到了中间层。它可以将数据库更加好地保护在内网。其次,连接数据库的所有连接都可以控制,更方便DBA对数据的管理,看哪些连接更耗费数据库资源,以便更好地优化代码。 

    但是,也有两点要注意:第一,必须要做成Windows的服务程序。Windows发展到今天,如果以一个集成的大系统来讲,做成服务程序更加稳定,也更加安全,这样做即使用户不登录机器,也可以使用。第二,必须要使用多个中间层。从中间层的作用可以看出,它承接了数据库的所有连接,所以,一旦出了问题,就会导致整个系统瘫痪。所以做多个中间层是必要的,这样,如果一个坏了可以登录到另一个。 

    实现多据库数据同步 

    中间层有了,下一步的工作是设置构建数据库集群。对于负载均衡,最重要的就是所有服务器的数据都是同步的。这是一个集群所必需的,因为,如果数据不同步,那么用户从一台服务器读出的数据,就有别于从另一台服务器读出的数据,这是不能允许的。所以必须实现一个数据库的数据同步。这里设置一个用于写入的数据库,设置两个用于读出的数据库,因为据统计,一般来讲,70%的数据库操作为读操作。 

    首先,在写入数据库上做一个发布服务器,主要基于SQL Server 2005的复制技术,将即将用到的表都选上。注意,在连接上要选用模拟用户,然后共享时选择sa用户,这样就可以将数据共享了。 

    其次,在两个读服务器上做订阅服务,要注意同样的事项,这样一个“一写两读”的数据库集群就完成了。 

    由上我们可以看到SQL可以使用MSCS实现灾难恢复,用负载均衡减轻数据库的负担. 

    _______________________________________________________________________________________________________

             用来保存计算最终结果的数据库是整个信息系统的重要组成部分,技术也相对成熟。然而,对于所有数据库而言,除了记录正确的处理结果之外,也面临着一些挑战:如何提高处理速度,数据可用性、数据安全性和数据集可扩性。将多个数据库联在一起组成数据库集群来达到上述目标应该说是一个很自然的想法。

      集群(Cluster)技术是使用特定的连接方式,将价格相对较低的硬件设备结合起来,同时也能提供高性能相当的任务处理能力。

      本文试图对当前主要的数据库集群用到的具体技术和市场上的主流产品进行分析并作点评,从而为读者提供一个数据库集群的评价参考。

      下面讨论的数据库集群技术分属两类体系:基于数据库引擎的集群技术和基于数据库网关(中间件)的集群技术。

      

      基于数据库引擎的集群技术(共享磁盘或非共享磁盘)

      

      基于数据库网关(中间件)的集群技术(不共享磁盘) 
    关键技术

      在复杂的数据库集群技术之间做比较,其实就是比较它所包含的各项子技术性能和它们之间的协调运作能力,下面的文字将介绍数据库集群最需要得到重视的核心技术,同时也关注到了一些技术细节。

      提高处理速度的四种办法

      提高磁盘速度:主要思想是提高磁盘的并发度。尽管实现方法各不相同,但是它们最后的目的都是提供一个逻辑数据库的存储映象。

      【点评】系统为了提高磁盘访问速度,建立一个虚拟的涵盖所有数据“大”数据库,而不用去考虑数据的实际物理磁盘存放位置。

      分散数据的存放:利用多个物理服务器来存放数据集的不同部分,使得不同的服务器进行并行计算成为可能。

      ORACLE RAC是共享磁盘的体系结构,用户只需简单地增加一个服务器节点,RAC就能自动地将这节点加入到它的集群服务中去,RAC会自动地将数据分配到这节点上,并且会将接下来的数据库访问自动分布到合适的物理服务器上,而不用修改应用程序;UDB是非共享磁盘的体系结构,需要手工修改数据分区,MSCS和ASE也是同样情况。ICX是一种基于中间件的数据库集群技术,对客户端和数据库服务器都是透明的。可以用来集群几个数据库集群。

      【点评】系统通过化整为零的策略,将数据表格分散到多个服务器或者每个服务器分管几个内容不同的表格,这样做的目的在于通过多服务器间并行运算以提高访问速度。

      对称多处理器系统:

      利用多处理机硬件技术来提高数据库的处理速度。

      所有基于数据库引擎的集群都支持这个技术。

      【点评】将多CPU处理器进行合理调度,来同时处理不同的访问要求,但这种技术在数据库上的应用的实际收益是很有限的。

      交易处理负载均衡:在保持数据集内容同步的前提下,将只读操作分布到多个独立的服务器上运行。因为绝大多数的数据库操作是浏览和查询,如果我们能拥有多个内容同步的数据库服务器,交易负载均衡就具有最大的潜力(可以远远大于上面叙述的最多达四个处理器的对称多处理器系统)来提高数据库的处理速度,同时会具有非常高的数据可用性。

      所有基于数据库引擎的集群系统都只支持一个逻辑数据库映象和一个逻辑或物理的备份。这个备份的主要目的是预防数据灾难。因此,备份里的数据只能通过复制机制来更新,应用程序是不能直接更新它的。利用备份数据进行交易负载均衡只适用于一些非常有限的应用,例如报表统计、数据挖掘以及其它非关键业务的应用。

      【点评】负载平衡算是一项“老”技术了。但将性能提高到最大也是集群设计所追求的终极目标。传统意义上,利用备份数据进行交易负载均衡只适用于一些非常有限的应用。

      上述所有技术在实际部署系统的时候可以混合使用以达到最佳效果。

      提高可用性的四种方法

      硬件级冗余:让多处理机同时执行同样的任务用以屏蔽瞬时和永久的硬件错误。有两种实现方法:构造特殊的冗余处理机和使用多个独立的数据库服务器。

      基于数据库的集群系统都是用多个独立的数据库服务器来实现一个逻辑数据库,在任意瞬间,每台处理器运行的都是不同的任务。这种系统可以屏蔽单个或多个服务器的损坏,但是因为没有处理的冗余度,每次恢复的时间比较长。

      【点评】传统意义上,硬件越贵,性能越高,但往往事与愿违。想通过追加和升级硬件设备来改善硬件级的冗余,要进行详细的需求分析和论证。

      通讯链路级冗余:冗余的通讯链路可以屏蔽瞬时和永久的通讯链路级的错误。

      基于数据库引擎的集群系统有两种结构:共享磁盘和独立磁盘。RAC, MSCS 可以认为是共享磁盘的集群系统。UDB和ASE 是独立磁盘的集群系统。共享磁盘集群系统的通讯的冗余度最小。

      【点评】通讯链路级的冗余具有容错功能。

      软件级冗余:由于现代操作系统和数据库引擎的高度并发性,由竞争条件、死锁、以及时间相关引发的错误占据了非正常停机服务的绝大多数原因。采用多个冗余的运行数据库进程能屏蔽瞬时和永久的软件错误。基于数据库引擎的集群系统都用多个处理器来实现一个逻辑数据库,它们只能提供部分软件冗余,因为每一瞬间每个处理器执行的都是不同的任务。

      【点评】改善软件设计来提高冗余性能和屏蔽软件级错误是每个技术开发商的梦想。传统的集群系统只能提供部分软件冗余。

      数据冗余:

      1. 被动更新数据集:所有目前的数据复制技术(同步或异步),例如磁盘镜像、数据库文件复制以及数据库厂商自带的数据库备份工具都只能产生被动复制数据集。它一般只用于灾难恢复。

      【点评】大多数应用都是采用被动更新数据集的方法。这种方法容灾能力差,资源占用多,已面临淘汰和革新。

      2. 主动更新数据集:这种数据集需要一台或多台备份数据库服务器来管理,它可用于报表生成,数据挖掘,灾难恢复甚至低质量负载均衡。分同步和异步两种。

      异步主动复制数据集:先把事务处理交给主服务器来完成,然后事务处理再被串行地交给备份服务器以执行同样操作来保证数据一致性。所有的商用数据库都支持异步主动复制技术。

      同步主动复制数据集:要求所有并发事务处理在所有数据库服务器上同时完成。直接好处就是解决了队列管理问题,同时通过负载均衡实现更高性能和可用性。RAC, UDB, MSCS 和 ASE是用完全串行化并结合两阶段提交协议来实现的,设计目标就是为了获得一份可用于快速灾难恢复的数据集。

      【点评】主动更新数据集是目前比较先进的数据冗余方法。专业人员还可以进行更底层的技术细节比较。底层技术的差异直接影响着一些重要指标。

      提高安全和数据集可扩性的技术

      在提高数据库安全性和数据集可扩性这两方面,可以创新的空间是很小的。数据库最常见的安全办法是口令保护,要么是分布式的,要么是集中式的。在数据库前面增加防火墙会增加额外的延迟,因此,尽管许多安全侵犯事件是来自于公司内部,但是数据库防火墙还是很少被采用。如果数据库集群技术是基于中间件技术实现的,就有可能在不增加额外延迟的情况下,在数据经过的路径上实现防火墙功能。数据库数据集的可扩性只能通过将数据分布到多个独立的物理服务器上来实现。 
    主流产品

      在数据库集群产品方面,其中主要包括基于数据库引擎的集群技术的Oracle RAC、Microsoft MSCS、IBM DB2 UDB、Sybase ASE,以及基于数据库网关(中间件)的集群技术的ICX-UDS等产品。

      Oracle RAC

      Oracle RAC 支持 Oracle 数据库在集群上运行的所有类型的主流商业应用程序。这包括流行的封装产品,如 SAP、PeopleSoft 和 Oracle E-Business Suite 等,以及自主研发的应用程序,其中包括 OLTP 和 DSS,以及 Oracle 有效支持混合 OLTP/DSS 环境的独有能力。Oracle 是唯一提供具备这一功能的开放系统数据库的厂商。 Oracle RAC 运行于集群之上,为 Oracle 数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。如果集群内的一个节点发生故障,Oracle 将可以继续在其余的节点上运行。如果需要更高的处理能力,新的节点可轻松添加至集群。为了保持低成本,即使最高端的系统也可以从采用标准化商用组件的小型低成本集群开始逐步构建而成。

      Oracle 的主要创新是一项称为高速缓存合并的技术,它最初是针对 Oracle9i 真正应用集群开发的。高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存,从而最大限度地低降低磁盘 I/O。高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据无需在节点间进行分区。Oracle RAC 支持企业网格。Oracle RAC 的高速缓存合并技术提供了最高等级的可用性和可伸缩性。Oracle RAC能显著降低了运营成本,增强了灵活性,从而赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时,通过提高的利用率不断降低成本。

      Oracle RAC采用了“sharing everything”的实现模式,通过CPU共享和存储设备共享来实现多节点之间的无缝集群,用户提交的每一项任务被自动分配给集群中的多台机器执行,用户不必通过冗余的硬件来满足高可靠性要求。另一方面,RAC可以实现CPU的共享,即使普通服务器组成的集群也能实现过去只有大型主机才能提供的高性能。

      Microsoft MSCS

      数年以来,Microsoft一直致力于对自身服务器解决方案的伸缩能力、可用性与可靠性进行扩展。最初代号为Wolfpack且先后被称为Microsoft集群服务器与Microsoft集群服务的MSCS是Microsoft在NT集群技术领域中的首次重拳出击,它是公认的最佳Microsoft集群解决方案。在MSCS群集中,MSCS软件最多可以同四台运行在高速网络上的物理计算机建立连接。通常情况下,群集中的计算机能够按照“活动--活动”方式共享相同的存储子系统与功能,这意味着所有集群计算机(节点)均可主动通过共享负载的方式协同完成工作,并在某个节点出现故障时分担它的工作。MSCS的主要用途是通过自身提供的容错能力提高应用程序可用性。容错能力是指将相关处理过程从某个节点上的故障应用程序移植到集群中其它健康节点上的集群功能。当故障应用程序得到恢复后,集群应当能够对原先的集群节点实现“故障返回”。MSCS能够在不丢失任何与故障应用程序相关数据的前提下对集群上所运行的应用程序进行故障恢复与故障返回管理,并且能够在故障恢复过程中维护用户及应用程序状态。这种类型的集群功能被称作有状态集群功能。MSCS同时还允许用户在应用程序升级过程中继续进行工作。您可以采取滚动升级方式(例如每次在一个集群节点上升级应用程序并确保其它节点上的应用程序继续处于可用状态)而不必在升级过程中停止使用应用程序。

      SQL Server 2005是微软的下一代数据管理和分析解决方案,给企业级应用数据和分析程序带来更好的安全性、稳定性和可靠性,更易于创建、部署和管理。它凭借针对故障转移群集机制的支持能力,得以增强的多实例支持能力以及分析服务对象与数据备份及恢复能力,分析服务的可用性得到了提高。它提供了诸如表分区、快照隔离、64位支持等方面的高级可伸缩性功能,使用户能轻松构建和部署关键应用。表和索引的分区功能显著增强了对大型数据库的查询性能。

      

      利用Windows 2000 MSCS实现的4节点集群 
    性能指标

      这部分将介绍集群系统的细节技术指标。在做系统规划时,用户就可去掉一些应用中不太重要的指标,或赋予这些指标以不同的权重,从而进行专业的技术性能比较,选择最适合自己的数据库集群系统。

      处理速度

      磁盘技术:所有集群系统都能很好地应用磁盘技术,但是由于DM,FM会对磁盘系统带来传输速度的负面影响,因此这方面它们相对欠缺。

      数据分割:所有基于数据库引擎的集群系统都有很好数据分割能力。

      SMP:所有基于数据库引擎的集群系统的SMP性能指标都比较接近。

      负载均衡:一般的数据库引擎的集群系统由于使用了备份的数据集,因此只能支持有限的负载均衡。这一指标不同产品之间有差异。

      数据可用性

      处理器和软件冗余:只有部分集群系统支持该功能。

      通讯链路冗余:一般来说,共享磁盘的集群系统通讯链路冗余指标较低,独立磁盘的集群系统指标较高。

      数据冗余:

      主动异步复制:除了磁盘和文件镜像外,其他集群系统支持该功能。

      主动同步复制:所有集群系统支持该功能,细节指标略有不同。

      被动异步复制:所有集群系统该性能指标都比较接近。

      被动同步更新:所有集群系统该性能指标都比较接近。

      通过广域网的复制技术:

      远程主动异步复制:所有的集群系统都支持这种复制技术,只不过对队列的管理能力有所不同。DM,FM和RAID的此性能相对较低。RAID不支持远程复制功能。

      远程主动同步复制:ICX在这方面做的比较好。

      远程被动异步复制:DM 和 FM支持这种类型的复制,因为DM和FM对集群是透明的,是在集群系统的下一层工作的,所有的集群系统都可以利用它们提供的功能。

      远程被动同步复制:DM和FM支持这种类型的复制,因为这种复制方式只在距离很近的时候才能使用(使用双模光纤,半径五英里)。同样地,因为DM和FM对集群是透明的, 所有的集群系统都可以利用它们提供的功能, 如果部署的话,所有的集群系统都是类似的。

      安全性

      口令:这是所有集群系统的基本性能。分布式或集中式的口令保护基本上保证了数据的安全。

      数据库防火墙:大多数数据库集群系统得数据库防火墙很少被采用,而ICX则采用在数据经过的路径上实现防火墙功能。

      数据集的可扩性

      数据分区:所有基于数据库引擎的集群系统都具备数据分区以保证数据集的可扩展。

      数据分区的可用性:所有集群系统该性能指标比较接近。

      集群管理

      共享磁盘的集群系统,比如RAC、MSCS,它们的管理比较方便,其中RAC的服务更多。但是,由于此种系统中的每一单独的服务器需要特殊处理,和独立磁盘的集群系统比较,就容易管理多了(虽然进行初始化和修改配置的时候也不那么容易),但它们都要求应用程序对集群不透明,而且配置,修改也比较麻烦。

      独立磁盘的集群系统象 UDB、ASE此性能相对稍低,因为用的都是非共享磁盘,所以管理相对繁琐。

      ICX在易管理性(初始配置和将来的修改)方面和独立磁盘集群系统的性能相当,但是在对底层数据管理复杂性方面做得比较好。在对数据库引擎和数据进行底层修复的时候任务需要直接到每台数据库处理器上去做。

      那些磁盘工具,即DM、FM和RAID,它们对集群是透明的。管理相对简单得多。

      应用透明度

      因为在错误回复和分区方面对应用程序不透明以及它们对应用程序都有些特殊的要求,基于数据库引擎的RAC、MSCS、UDB、ASE和ICX在这方面都有待提高的地方。而DM、FM和RAID它们对应用程序可以说是完全透明的。 
    IBM DB2 UDB

      DB2 UDB大量自动或自我管理功能可使管理员能够节省更多时间来集中精力考虑驱动业务价值的问题,甚至可以消除较小的实施项目对专职管理员的需求。

      UDB的优势体现在DB2的开放无界:支持Unix, Linux 以及Windows等主流操作系统;支持各种开发语言和访问接口;同时具有良好的数据安全性和稳定性。DB2 V8.2的高可用性灾备技术,可在极短时间内使关键应用得到恢复。利用DB2数据分区部件(DPF)实现横向扩展,可以支持多达1000台服务器组成的庞大数据库群集,为构建企业级数据仓库提供坚实的技术基础。利用DB2的数据分区部件以及DB2信息集成器(DB2 II)技术,数据库操作可综合利用网格中的每台服务器的运算能力,实现真正意义上的网格运算。

      UDB V8.2应用更多的创新技术,Design Advisor可以帮助 DBA 制定全面的数据库设计决策,包括集成复杂的功能划分、物化查询表,大大缩短部署时间。自动生成统计信息概要代表了来自 IBM LEO研发项目的首次部署。自主对象维护特性可自动执行基于策略的管理和维护功能,如表重构、统计信息收集和数据库备份。高可用性灾难恢复和客户机重路由特性实现了具备随选能力的企业所需的24*7信息可用性和恢复力。此外,DB2 UDB 提供与 Java/Eclipse 和 Microsoft .NET IDE的深入集成或插件。

      

      DB2 UDB结构拓扑图

      SYBASE ASE

      ASE性能的提高是建立在虚拟服务器架构上的,这是 Sybase 独有的体系结构。当前的ASE版本是ASE15。与操作系统和相关软件保持独立让ASE15可以更智能化地进行系统自我调优。VSA只需要很少的内存资源和内部交换开销,所以ASE15可以管理大量的联机用户。能够使ASE提高性能并控制成本的最主要原因是它采用了专利技术的、自调整的优化器和查询引擎。它可以智能地调整复杂的查询操作并忽略那些未包含相关信息的分区上的数据。ASE15还通过一系列用来管理和诊断数据库服务器的新特性来降低运营成本。

      ASE15 拥有高可靠性和极低的运行风险。个人数据的安全性是ASE特别关注的领域,使用了一种无需修改应用的独特加密系统。当应用和安全软件进行连接时将降低实施成本并避免产生新的安全漏洞。ASE15 还通过一种简单、直接和可编程的脚本语言来方便进行加密和解密。在解决意外停机问题时,ASE15 在其已证实的可靠性和高系统利用率的基础上,增加了许多显著的功能来增强系统的可用性和灾难恢复过程。新的存储引擎支持四种数据分区方式,在不同的物理设备上进行不同的分区操作。能帮助数据库管理员迅速地建立冗余灾难恢复节点并在异构的数据平台上同步数据库。

      ASE15系统新的查询和存储引擎被设计用于支持下一代网格计算和集群技术。它结合了充分利用数据分区技术的查询处理机制和适用于解决集群问题的优化器技术。同时ASE15为事件驱动的企业提供了一个绝好的数据库平台。与web services 和 XML的架构将减少系统内部的相互依赖性,并为应用开发提供更大的灵活性。

      ICX-UDS

      ICX-UDS不受基于数据库引擎的集群技术限制,可以支持不同的数据库。

      它类似通常的代理服务器。把ICX放置在关键的网络路径上,监听数据库系统流量。ICX网关将自动过滤出无状态的查询访问,并将负载均衡到所有服务器上。在这里,网关就象一个在线“编译器”,它将所有对数据库的更新操作发送到所有数据库上执行,而将无状态的查询操作只发送到其中某一数据库服务器上。

      对于统计报表和数据挖掘类应用,可以通过复制和只读去获得更快的处理速度。还能指定更多的只读来负载均衡。ICX 网关的容错可以通过备份网关来达到。加载一个非同步的数据库可以造出不影响主服务机群的近于实时的数据源。

      

      ICX 网关和负载均衡器配置示意图 
    应用点评

      Oracle RAC和Oracle数据库提供的特定新管理性增强功能实现了企业网格。各种规模的企业都可以采用Oracle RAC来支持各类应用程序。

      企业网格采用大型标准化商用组件配置:处理器、网络和存储器。利用Oracle RAC的高速缓存合并技术,Oracle数据库实现了最高可用性和可伸缩性。现在,利用Oracle数据库和Oracle RAC将大幅降低了运行成本,进一步增强了灵活性,其动态提供节点、存储器、CPU和内存的特性可以更轻松、高效地保持服务级别,而通过提高的利用率又进一步降低了成本。企业网格是未来的数据中心,使企业具备更高的适应能力、前瞻性和敏捷性。

      集群技术随着服务器硬件系统与网络操作系统的发展将会在可用性、高可靠性、系统冗余等方面逐步提高。我们汇集了市场上的主流产品,并从分析性能指标的角度出发,对产品进行了简要评价。

      Sybase ASE是一个深受用户欢迎的高性能数据库,它具有一个开放的、可扩展的体系结构,易于使用的事务处理系统,以及低廉的维护成本。

      ASE可支持传统的、关键任务的OLTP和DSS应用,并且满足Internet应用的发展需要,Sybase可以很好地满足关键任务的企业业务应用的需求,提供数据库可靠性、集成性和高性能。ASE有效的多线索结构,内部并行机制和有效的查询优化技术提供了出色性能和可伸缩性;还可提供先进的企业集成、强健和数据访问与数据移动技术,支持跨越远程Sybase和non-Sybase数据库的分布事务和查询。ASE进一步扩展了这些功能,通过分布信息和管理商业事务,支持通过企业信息门户对商业系统进行个性化的用户访问。

      MSCS对于诸如电子邮件服务器、数据库应用程序之类的应用程序,是一种良好的运行方式。

      假设您决定在一个4节点MSCS群集上运行Microsoft Exchange 2000 Server。当安装MSCS软件以及适用于群集的Exchange 2000版本后,您可以对群集进行配置,以便使Exchange 2000能够在主要节点发生故障时在备份节点上进行故障恢复。当故障发生时,主服务器上肯定存在处于打开状态的用户会话,然而,MSCS能够在不丢失任何数据的情况下快速、自动的完成故障恢复。备份节点将从故障节点上接替工作负载及相关数据,并继续为用户提供服务。

      ICX的最大优点是在数据库集群技术面临的挑战上有了新的探索,此项基于中间件的数据库集群技术为获得具有高可扩性的高性能数据库提供了一条切实可行的途径,同时能灵活地适应未来的技术变化。

      这种中间件复制技术可位于关键的网络路径上,监听所有进出数据库系统的流量,方便地提供防火墙和其它安全服务,保护物理的数据库服务器。通过多个服务器的并发处理很容易地隐藏了处理的延迟。实时并行同步交易复制:一旦我们突破了实时并行同步交易复制的技术障碍,用户就能通过由多个数据库服务器构成的集群来获得高性能,高可用性和高安全性。

      DB2 UDB是一个可以随企业增长的数据库。当对网站的事务需求达到峰值时它可以迅速响应,它可以进行扩展以容纳分布在许多不同数据库中的数量不断增长的信息。

      随着信息基础结构从一个处理器发展到多个处理器再到高度并行的多个群集,它也随之扩展。将分区技术和群集技术集成到新的 DB2 UDB Enterprise Server Edition 中意味着该版本很灵活。DB2 UDB还添加了自主数据库技术,它使数据库管理员可以选择使用增强的自动化技术来配置、调优和管理他们的数据库。自主数据库管理意味着管理员可以在管理日常任务上花费较少的时间。表的多维群集减轻了 DBA 创建索引的工作负担,同时提供了数据群集以快速查询。DB2内置的已规划的和未规划的可用性能力确保了业务应用程序在任何时候都可用。诸如索引重建、索引创建和表装载之类的联机实用程序以及可以不停止数据库进行更改的配置参数,都意味着改进的性能和高可用性。

      【相关链接】

      理想的数据库集群应具备的特点

      提高速度:只通过简单地增加数据库服务器就能相对提高数据库处理速度。

      数据同步:在任何时刻需要有多个随时可用的实时同步数据服务。最好有多个异地的同步数据服务。

      安全保证:除了密码保护之外,我们最好能控制企业内部对数据库的非法访问。

      可扩展性:应保证我们能任意增大数据集而没有对可用性产生负面影响。

      一般来说,有关数据库集群的技术都非常庞杂。更具挑战性的是,实际应用要求在提高速度、数据同步、安全保证、可扩展性方面的指标能同时提升,而不是单纯提升某一指标而牺牲其他指标。全面提升这些技术指标是数据库集群技术都将面临的重大课题。

      【名词解释】

      集群:是一组通过协同工作方式运行同一套应用程序并针对客户端及应用程序提供单一系统映像的独立计算机。集群技术的目标在于通过多层网络结构进一步提高伸缩能力、可用性与可靠性。

      可伸缩性:是指一台计算机在维持可接受性能的前提下处理不断提高的工作负载的能力。

      可用性:是指存在质量、备用能力、获取简便性以及可访问能力。

      可靠性:是指系统牢固程度。

    展开全文
  • 共享存储数据库集群

    千次阅读 2020-12-31 17:22:38
    共享存储数据库集群 DMDSC 简介 DM 共享存储数据库集群的英文全称 DM Data Shared Cluster,简称 DMDSC。DM 共享存储数据库集群,允许多个数据库实例同时访问、操作同一数据库, 具有高可用、高性能、负载均衡等特性...

    共享存储数据库集群

    DMDSC 简介

    DM 共享存储数据库集群的英文全称 DM Data Shared Cluster,简称 DMDSC。DM 共享存储数据库集群,允许多个数据库实例同时访问、操作同一数据库, 具有高可用、高性能、负载均衡等特性。 DMDSC 支持故障自动切换和故障自动重加入,某一个数据库实例故障后,不会导致数据库服务无法提供。

    本章节主要介绍 DMDSC 集群的功能、概念、实现原理,并举例说明搭建过程和管理方法。阅读本章节可以帮助用户:

    • 了解 DMDSC/DMCSS/DMASM 等集群相关概念。
    • 了解 DMASM 分布式文件系统、 DMDSC 集群,以及基于 DMASM 的 DMDSC 集群配置过程和应用。

    DMDSC 集群是一个多实例、单数据库的系统。多个数据库实例可以同时访问、修改同一个数据库的数据。用户可以登录集群中的任意一个数据库实例,获得完整的数据库服务。数据文件、控制文件在集群系统中只有一份,不论有几个节点,这些节点都平等地使用这些文件。各个节点有自己独立的联机日志和归档日志。 这些文件就保存在共享存储上。

    DMDSC 集群得以实现的重要基础就是共享存储。DM 支持的共享存储有两种:裸设备和 DMASM。这两种存储的区别在于后者在前者的基础上,部署并使用了 DMASM 文件系统。为了方便对裸设备上的磁盘或文件进行管理,推荐用户使用后者。

    DMDSC 集群主要由数据库和数据库实例、共享存储、本地存储、通信网络、以及集群控制软件 DMCSS 组成。下面以部署了 DMASM 的 DMDSC 集群为例,展示 DMDSC 集群系统结构,如下图所示:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sWiG53nF-1609406467913)(../asset/start/DMDSCjqjgt.jpg)]

    DMDSC 主要特点包括:

    • 高可用性 只要集群中有一个活动节点,就能正常提供数据库服务。
    • 高吞吐量 多个节点同时提供数据库服务,有效提升集群的整体事务处理能力。
    • 负载均衡 用户的连接请求被平均分配到集群中的各个节点,确保各个节点的负载大致平衡。

    DMDSC 使用的环境

    部署 DMDSC 集群所用到的硬件和软件环境。

    软硬件环境环境介绍
    主机(2台)内存:2 GB 以上;网卡:双网卡;提供内部网络和外部网络服务;主机用于部署数据库实例 dmserver、DMCSS、DMASMSVR。
    共享存储两台主机可同时访问存储,可以划分为裸设备的磁盘。
    操作系统Linux、Unix、Windows 等。
    达梦数据库软件DM Database Server 64 V8
    其他 DM 软件dmserver、 dminit、 dmasmcmd、 dmasmsvr、 dmasmtool、 dmcss、 dmcssm等 ;位于 DM 数据库安装目录 /dmdbms/bin

    DMDSC 实现原理

    DMDSC 是一个共享存储的数据库集群系统。多个数据库实例同时访问、修改同一个数据库,因此必然带来了全局并发问题。DMDSC 集群基于单节点数据库管理系统之上,改造了 Buffer 缓冲区、事务系统、封锁系统和日志系统等,来适应共享存储集群节点间的全局并发访问控制要求。同时,引入缓存交换技术,提升数据在节点间的传递效率。

    DMCSS 介绍

    DMCSS (Dameng Cluster Synchronization Services) 达梦集群同步服务,使用 DMASM 集群或 DMDSC 集群都必须要配置 DMCSS 服务。在 DMASM 集群或 DMDSC 集群中,每个节点都需要配置一个 DMCSS 服务。这些 DMCSS 服务自身也构成一个集群,DMCSS集群中负责监控、管理整个 DMASM 集群和 DMDSC 集群的节点称为控制节点 (controlnode),其他 DMCSS 节点称为普通节点 (normal node)。DMCSS 普通节点不参与 DMASM 集群和 DMDSC 集群管理,当 DMCSS 控制节点故障时,会从活动的普通节点中重新选取一个 DMCSS 控制节点。

    DMCSS 工作的基本原理是:在 Voting disk 中,为每个被监控对象 (dmasmsvr、dmserver、DMCSS) 分配一片独立的存储区域,被监控对象定时向 Voting Disk 写入信息(包括时间戳、状态、命令、以及命令执行结果等);DMCSS 控制节点定时从 Voting Disk 读取信息,检查被监控对象的状态变化,启动相应的处理流程;被监控对象只会被动的接收 DMCSS 控制节点命令,执行并响应。

    DMCSS 主要功能包括:写入心跳信息、选举 DMCSS 控制节点、选取 DMASM/DMDSC 控制节点、管理被监控对象的启动流程、集群状态监控、节点故障处理、节点重加入等,DMCSS还可以接收并执行 DMCSSM 指令。

    DMASM 介绍

    DMASM (DM Auto Storage Manager) 是一个专用的分布式文件系统,使用 DMASM 自动存储管理方案,可以帮助用户更加便捷地管理 DMDSC 集群的数据库文件。DMASM 的主要部件包括:提供存储服务的裸设备、dmasmsvr 服务器、dmasmapi 接口、初始化工具 dmasmcmd 和管理工具 dmasmtool 等。

    DMDSC 集群可以直接使用裸设备作为共享存储,存放数据库文件。但是,由于裸设备存在的一些功能限制,造成 DMDSC 集群在使用、-维护上并不是那么灵活、方便。裸设备的使用限制如下:
    - 不支持动态扩展文件大小;在创建数据文件时,就必须指定文件大小,并且文件无法动态扩展。
    - 数据文件必须占用整个裸设备盘,造成空间浪费
    - 不支持类 linux 的文件操作命令,使用不方便
    - 操作系统支持最大裸设备数目较小,无法创建足够的数据库文件

    为了克服裸设备的这些使用限制, DM 专门设计了一个分布式文件系统 DMASM,来管理裸设备的磁盘和文件。 DMASM 提供了基本的数据文件访问接口,可以有效降低 DMDSC 共享存储的维护难度,DMASM 提供的主要功能包括:
    - 分布式管理
    支持多台机器并发访问 DMASM 磁盘和文件,提供全局并发控制。
    - 磁盘组管理
    支持创建和删除磁盘组,将裸设备格式化为 DMASM 格式,并由 dmasmsvr 统一管理;一个磁盘组可以包含一个或者多个 DMASM 磁盘;磁盘组支持在线增加 DMASM 磁盘,实现动态存储扩展。
    - 文件管理
    支持创建、删除、截断文件等功能;支持创建目录;支持动态扩展文件;文件可以存放在一个磁盘组的多个磁盘中,文件大小不再受限于单个磁盘大小。
    - 完善、高效的访问接口

    DMASM 文件系统将物理磁盘格式化后,变成可识别、可管理的 DMASM 磁盘,再通过DMASM 磁盘组将一个或者DMASM 磁盘整合成一个整体提供文件服务。
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5N4qoGNo-1609406467915)(../asset/start/DMASM.jpg)]

    通过 dmasmapi 可以获得各种文件管理功能。

    • 通用功能的管理工具

    dmasmtool 提供一套类 Linux 的文件操作命令用于管理 DMASM 文件,降低用户学习、使用 DMASM 文件系统的难度。

    • DMASM 原理

    为了帮助用户更好的理解、使用 DMASM,本小节从 DMASM 磁盘与文件管理、DMASM redo日志、簇映射表等方面介绍 DMASM 原理。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nQkBfEUl-1609406467916)(…/asset/start/DMASM.jpg)]

    DMASM 磁盘格式化以后,会逻辑划分为若干簇 (xtent),簇是管理 DMASM 磁盘的基本单位,DMASM 文件的最小分配单位也是簇。这些逻辑划分的簇根据其用途可以分为描述簇、inode 簇和数据簇。如下图所示:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LiICcG9C-1609406467921)(../asset/start/DMASM1.jpg)]

    创建、删除 DMASM 文件操作,在 DMASM 系统内部其实就是转换成修改、维护 inode AU 的具体动作。而扫描全局的 inode AU 链表就可以获取到磁盘组上所有的 DMASM 文件信息.

    展开全文
  • 使用Docker搭建高可用Mysql数据库集群

    千次阅读 2020-04-27 22:38:51
    来学习的是搭建Mysql数据库集群,使其能够在模拟高并发的情况下,在其中的一些Mysql结点宕机的情况下也能够正常的访问,不会因为一个结点的宕机,就不能够再提供服务。在上一篇文章中讲到的是环境的搭建,具体参看...

    前言

    这篇文章是搭建高可用,高负载的第二篇。来学习的是搭建Mysql数据库集群,使其能够在模拟高并发的情况下,在其中的一些Mysql结点宕机的情况下也能够正常的访问,不会因为一个结点的宕机,就不能够再提供服务。在上一篇文章中讲到的是环境的搭建,具体参看linux环境搭建,里面详细讲解了环境的搭建,有需要的可以移步去看那篇文章。

    具体的其中配置文件可以参看github中有一系列的文件配置信息。有需要学习的小伙伴可以对其进行下载,自行根据博客配置

    正文

    选择哪一种搭建集群的方式

    对于mysql来说有两种搭建集群的方法:Replication与PXC,如下图所示:
    在这里插入图片描述
    对于第一种情况的Replication弱一致性表示是对于当前结点的数据,在集群中的另外一个结点并不一定能够访问到,所以一般也都是价值比较低的数据。对于PXC来说实现的是强一致性,表示对于任意结点中的数据在其他的结点中也都能够访问到。对于阿里的服务器集群,及当下的主流网站,对于数据库集群的搭建都是采用第二种方法,下面来看具体的信息。

    PXC

    对于数据的同步是双向的,数据在每一个结点上面都可以进行读写。
    在这里插入图片描述
    同步复制,事务在所有集群节点要么同时提交,要么不提交
    在这里插入图片描述

    Replication

    对于数据的同步是单向的,就是例如我们在名为Master的结点上写入数据,对于Slave结点上可以读取到Master写入的数据,但是对于在Slave上写入的数据,在Master就不能读取到。
    在这里插入图片描述

    安装docker

    既然是要在Docker上配置mysql数据库集群,这里就先在linux服务器上安装Docker(这里说明以下对于dockers也是虚拟机,VM也是虚拟机,为什么说不使用到VM进行虚拟环境的搭建,然后搭建数据库集群? 因为对于VM来说是重量级的,对于Docker来说是轻量级的。对于VM每一个Vm虚拟机都是切实占用内存空间。但是对于Docker来说多个docker虚拟机来共享分配的空间大小,基础的配置不变,只是在其上进行了进一步的封装,更加便捷与易于管理与维护)

    Docker操作的基本命令

    1. 先更新软件包,其中的-y表示确定的意思
    yum -y update
    
    1. 安装Docker虚拟机。-y也表示确定意思。
    yum install -y docker
    
    1. 运行、重启、关闭Docker虚拟机
    service docker start
    service docker restart
    service docker stop
    
    1. 搜索镜像
    docker search 镜像名称
    eg: docker search java
    

    注意: 这里直接使用Docker的源镜像在国外可能会很慢,所以我们这里使用国内比较好的加速器进行加速。
    DaoCloud跳转链接
    复制以下代码进入到linux环境下运行,注意若是无法复制,使用XShell连接复制运行。
    在这里插入图片描述
    运行成功以后,输入命令 vi /etc/docker/daemon.json,将下图第一行最后的去掉。然后重新启动docker输入service docker restart
    在这里插入图片描述5. 下载镜像

    docker pull 镜像名称
    
    1. 查看镜像
    docker images
    
    1. 删除镜像
    docker rmi 镜像名称
    
    1. 运行容器
    docker run 启动参数  镜像名称
    
    1. 查看容器列表
    docker ps -a
    
    1. 停止、挂起、恢复容器
    docker stop 容器ID
    docker pause 容器ID
    docker unpase 容器ID
    
    1. 查看容器信息
    docker inspect 容器ID
    

    12.删除容器

    docker rm 容器ID
    
    1. 数据卷管理
    docker volume create 数据卷名称  #创建数据卷
    docker volume rm 数据卷名称  #删除数据卷
    docker volume inspect 数据卷名称  #查看数据卷
    
    1. 网络管理
    docker network ls 查看网络信息
    docker network create --subnet=网段 网络名称
    docker network rm 网络名称
    
    1. 避免VM虚拟机挂起恢复之后,Docker虚拟机断网
    vi /etc/sysctl.conf
    
    1. 文件中添加net.ipv4.ip_forward=1这个配置
    #重启网络服务
    systemctl  restart network
    

    安装PXC集群

    1. 前面我们提到我们使用PXC进行集群的搭建,所以先要对PXC镜像进行安装。
    
    docker pull percona/percona-xtradb-cluster
    

    在这里插入图片描述
    2. 为镜像更改名字:

    docker tag percona/percona-xtradb-cluster pxc
    

    在这里插入图片描述
    3. 创建net1网段

    docker network create --subnet=172.18.0.0/16 net1
    

    在这里插入图片描述

    1. 创建5个数据卷
      docker volume create --name v1
      docker volume create --name v2
      docker volume create --name v3
      docker volume create --name v4
      docker volume create --name v5
      在这里插入图片描述

    2. 创建5节点的PXC集群

    注意,每个MySQL容器创建之后,因为要执行PXC的初始化和加入集群等工作,耐心等待1分钟左右再用客户端连接MySQL。另外,必须第1个MySQL节点启动成功,用MySQL客户端能连接上之后,再去创建其他MySQL节点。

    #创建第1个MySQL节点
    docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=abc123456 -v v1:/var/lib/mysql -v backup:/data --privileged --name=node1 --net=net1 --ip 172.18.0.2 pxc
    #创建第2个MySQL节点
    docker run -d -p 3307:3306 -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -v v2:/var/lib/mysql -v backup:/data --privileged --name=node2 --net=net1 --ip 172.18.0.3 pxc
    #创建第3个MySQL节点
    docker run -d -p 3308:3306 -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -v v3:/var/lib/mysql --privileged --name=node3 --net=net1 --ip 172.18.0.4 pxc
    #创建第4个MySQL节点
    docker run -d -p 3309:3306 -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -v v4:/var/lib/mysql --privileged --name=node4 --net=net1 --ip 172.18.0.5 pxc
    #创建第5个MySQL节点
    docker run -d -p 3310:3306 -e MYSQL_ROOT_PASSWORD=abc123456 -e CLUSTER_NAME=PXC -e XTRABACKUP_PASSWORD=abc123456 -e CLUSTER_JOIN=node1 -v v5:/var/lib/mysql -v backup:/data --privileged --name=node5 --net=net1 --ip 172.18.0.6 pxc
    

    这个时候,我们就创建了5个SQL节点,我们可以使用本地的Navicat进行测试连接:
    在这里插入图片描述
    此时PXC集群已经搭建完成,对于在一个数据库中进行的更改,在其他数据库中也能够看得到,这里我们在db5中添加一个新表student,添加一定的字段:
    在这里插入图片描述
    发现在db3中,可以看到也有对应的更改。
    在这里插入图片描述

    负载均衡

    至于搭建负载均衡,可能很多小伙伴想到的是使用nginx进行负载均衡的搭建,这里来进行一个对比:对于Tcp/IP协议Haprosy已经成功运行了很多年,但是对于Nginx来说才刚刚开始支持,并且对于Haproxy支持的类型也比较多和稳定。
    在这里插入图片描述

    对于以上PXC集群已经搭建完成,这个时候就可以将数据进行同步。但是对于数据库上线以后,我们不能够将所有的数据请求打在同一个节点的上面,既然集群已经搭建完成,我们就需要让所有的节点都参与到数据的读写中,在数据请求到达时候要均匀的分布到每一个结点,所以就需要使用到负载均衡,将所有的节点都能够承担数据的访问请求。

    1. 安装Haproxy镜像
    docker pull haproxy
    

    在这里插入图片描述

    1. 使用
      配置文件如下:
    global
        #工作目录
        chroot /usr/local/etc/haproxy
        #日志文件,使用rsyslog服务中local5日志设备(/var/log/local5),等级info
        log 127.0.0.1 local5 info
        #守护进程运行
        daemon
    ​
    defaults
        log global
        mode    http
        #日志格式
        option  httplog
    ![在这里插入图片描述](https://img-blog.csdnimg.cn/20200427222412956.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDAxNTA0Mw==,size_16,color_FFFFFF,t_70)
        #日志中不记录负载均衡的心跳检测记录
        option  dontlognull
        #连接超时(毫秒)
        timeout connect 5000
        #客户端超时(毫秒)
        timeout client  50000
        #服务器超时(毫秒)
        timeout server  50000
    ​
    #监控界面   
    listen  admin_stats
        #监控界面的访问的IP和端口
        bind  0.0.0.0:8888
        #访问协议
        mode        http
        #URI相对地址
        stats uri   /dbs
        #统计报告格式
        stats realm     Global\ statistics
        #登陆帐户信息
        stats auth  admin:abc123456
    #数据库负载均衡
    listen  proxy-mysql
        #访问的IP和端口
        bind  0.0.0.0:3306  
        #网络协议
        mode  tcp
        #负载均衡算法(轮询算法)
        #轮询算法:roundrobin
        #权重算法:static-rr
        #最少连接算法:leastconn
        #请求源IP算法:source 
        balance  roundrobin
        #日志格式
        option  tcplog
        #在MySQL中创建一个没有权限的haproxy用户,密码为空。Haproxy使用这个账户对MySQL数据库心跳检测
        option  mysql-check user haproxy
        server  MySQL_1 172.18.0.2:3306 check weight 1 maxconn 2000  
        server  MySQL_2 172.18.0.3:3306 check weight 1 maxconn 2000  
        server  MySQL_3 172.18.0.4:3306 check weight 1 maxconn 2000 
        server  MySQL_4 172.18.0.5:3306 check weight 1 maxconn 2000
        server  MySQL_5 172.18.0.6:3306 check weight 1 maxconn 2000
        #使用keepalive检测死链
        option  tcpka  
    
    1. 创建两个Haproxy容器
      #创建第1个Haproxy负载均衡服务器
      docker run -it -d -p 4001:8888 -p 4002:3306 -v /home/soft/haproxy:/usr/local/etc/haproxy --name h1 --privileged --net=net1 --ip 172.18.0.7 haproxy
      #进入h1容器,启动Haproxy
      docker exec -it h1 bash
      haproxy -f /usr/local/etc/haproxy/haproxy.cfg
      #创建第2个Haproxy负载均衡服务器
      docker run -it -d -p 4003:8888 -p 4004:3306 -v /home/soft/haproxy:/usr/local/etc/haproxy --name h2 --privileged --net=net1 --ip 172.18.0.8 haproxy
      #进入h2容器,启动Haproxy
      docker exec -it h2 bash
      haproxy -f /usr/local/etc/haproxy/haproxy.cfg
      在这里插入图片描述
      完成以上以后我们就可以开始进行本地的验证验证是否成功。前面提到了映射到本地的4001端口,就是说由Docker虚拟机的8888端口映射到linux虚拟机的4001端口,然后我们在本地进行连接的访问处理:
      输入http://XXX.XXX.2.34/4001/dbs 发现对于以下的五个节点都有正常的运行。在这里插入图片描述
      然后我们使用以下语句,挂掉一个结点 docker stop node1 再次查看情况。发现Mysql_1已经停止运行。
      在这里插入图片描述
      这个时候,在本地进行连接:
      在这里插入图片描述
      然后在h1中进行一个更改,会发现对于其他的数据库连接也会有相对应的更改(除去db1,因为前面我们已经把db1给停掉)。

    通过以上的操作我们就暂时完成了对多个数据库进行了集群的搭建,使用到的是PXC,数据的强一致性。但是对于我们有了数据库集群,我们访问时候还是会访问到同一个节点,所以需要使用到负载均衡,使得我们搭建的数据库集群,在面对数据请求时候,能够将请求分布在各个节点之上,减少单个结点的压力。

    双机热备

    前面我们提到使用到了Haproxy技术实现了负载均衡,但是情况如下图所示:对于前端发送过来的请求通过Haproxy将请求数据分发确实能够降低每一个数据库实例的负载,但是若是Haproxy直接出现了故障,前端发起的请求就根本不可能到达后端的数据库,所以对于一个Haproxy不能够成为我们的瓶颈,还是要设置多个Haproxy实现双机热备。
    在这里插入图片描述
    想要实现双机热备技术我们需要先了解一个知识点就是虚拟IP
    在linux的网卡中可以设置多个虚拟ip地址,然后将这些ip地址分配给对应的程序。
    在这里插入图片描述

    具体实现细节

    1. 首先我们需要先定义对应的虚拟ip,然后将两个Haproxy定义在两个容器中,这里使用到了KeepAlived,将Haproxy存放在这两个容器中,此时这两个容器来抢占设置的虚拟Ip,如下图所示:对应的两个KeepAlived谁先抢到虚拟ip就被认定为是主服务器,对于备用服务器会和主服务器之间进行心跳检测,如果备用服务器没有收到主服务器的心跳检测响应,就意味着主服务器可能出现了故障,这个时候备用服务器就可以去抢用虚拟IP
      在这里插入图片描述
    2. 以上我们介绍了双机热备的实现原理,现在来整体观看一下具体的实现流程:
      1. 首先最右边是数据库集群,就是我们在最开始搭建的五个数据库结点的集群,然后使用到Haproxy实现负载均衡。
      2. 使用到一个Haproxy进行负载均衡可能就会出现一个Haproxy出现故障时候,对于整个数据库的集群都不能够再访问,所以需要搭建双机热备(两个Haproxy来实现)使用到Keepalived,搭建容器来抢用虚拟ip地址如下图中的172.18.0.15
      3. 对于这个虚拟ip地址是docker内部的ip地址,需要使用到宿主机的Keepalived来将宿主机的192.168.99.65地址映射到docker内部的虚拟ip地址。
      4. 此时流程执行是:
        1. 访问到节点192.168.99.65时候,keepalived映射到docker内部的*172.18.0.15**。
        2. 对于这个虚拟ip地址两个Haproxy容器来抢占这个ip地址,抢到的是主服务器,没有抢到的就是备用服务器,两者之前会开启心跳检测,在一个发生故障时候,另外一个能够及时替补上。
        3. 最后使用负载均衡访问数据库节点,减少单个数据库结点的压力。
          在这里插入图片描述

    安装keepalived

    因为我们有两个Haproxy,所以要先进入到对应的haproxy中:

    1. 对应的haproxy节点1
    #进入h1容器
    docker exec -it h1 bash
    #更新软件包
    apt-get update
    #安装VIM
    apt-get install vim
    #安装Keepalived
    apt-get install keepalived
    #编辑Keepalived配置文件(参考下方配置文件)
    vim /etc/keepalived/keepalived.conf
    # 这里若是不想下载vim可以使用 cat追加的方式
    #启动Keepalived
    service keepalived start
    #宿主机执行ping命令
    ping 172.18.0.201
    

    在这里插入图片描述
    将文件内容追加的配置文件中:
    在这里插入图片描述
    进行测试连接:
    在这里插入图片描述

    h1配置文件信息如下:

    vrrp_instance  VI_1 {
        state  MASTER
        # 对于state的值有两个属性有两个属性,一个是 MASTER(表示主服务器,对于BACKUP表示备用服务器,我们在配置的时候将两个值都设置为MASTER 来共同抢用虚拟ip。)
        interface  eth0
        # 保存到哪一个网卡,是一个虚拟的网卡
        virtual_router_id  51
            # keepalived 0-255 之间
        priority  100
    # 权重设置 硬件配置调整数字。
        advert_int  1
        # 心跳检测,1 表示1s。
        authentication {
            auth_type  PASS
            auth_pass  123456
        }
        # 心跳检测登录到某一个结点。
        virtual_ipaddress {
            172.18.0.201
        }
        # 虚拟ip设置 docker内部能看到
    }
    
    1. 对应的haproxy节点2 (配置如同h1所示,这里不再进行逐一演示)
       #进入h2容器
       docker exec -it h2 bash
       #更新软件包
       apt-get update
       #安装VIM
       apt-get install vim
       #安装Keepalived
       apt-get install keepalived
       #编辑Keepalived配置文件
       vim /etc/keepalived/keepalived.conf
       #启动Keepalived
       service keepalived start
       #宿主机执行ping命令
       ping 172.18.0.201
    

    配置文件内容如下:

    vrrp_instance  VI_1 {
        state  MASTER
        interface  eth0
        virtual_router_id  51
        priority  100
        advert_int  1
        authentication {
            auth_type  PASS
            auth_pass  123456
        }
        virtual_ipaddress {
            172.18.0.201
        }
    }
    
    1. 宿主机安装Keepalived,实现双击热备

      #宿主机执行安装Keepalived
      yum -y install keepalived
      #修改Keepalived配置文件
      vi /etc/keepalived/keepalived.conf
      #启动Keepalived
      service keepalived start
      

      在这里插入图片描述

      Keepalived配置文件如下:
      进入到/etc/keepalived/keepalived.conf 进行修改如下:

      vrrp_instance VI_1 {
          state MASTER
          interface ens33
          virtual_router_id 51
          priority 100
          advert_int 1
          authentication {
              auth_type PASS
              auth_pass 1111
          }
          virtual_ipaddress {
             	192.168.99.150
          }
      }
      
      virtual_server 192.168.99.150 8888 {
          delay_loop 3
          lb_algo rr
          lb_kind NAT
          persistence_timeout 50
          protocol TCP
      
          real_server 172.18.0.201 8888 {
              weight 1
          }
      }
      
      virtual_server 192.168.99.150 3306 {
          delay_loop 3
          lb_algo rr
          lb_kind NAT
          persistence_timeout 50
          protocol TCP
      
          real_server 172.18.0.201 3306 {
              weight 1
          }
      }
      

    数据的冷热备份

    冷备份

    数据的备份分为冷备份与热备份之分,对于冷备份来说,需要系统下线将数据进行备份以后,再将系统进行上线处理。当然也有折中的办法,就是对于我们配置的而多个PXC结点,因为其中的数据都是相同的所以可以先下线一个PXC结点,然后进行数据备份完成以后再重新上线即可。
    在这里插入图片描述

    热备份

    LVM:是Linux系统自带的一种备份的方式,Linux对某一个分区创建一个快照(就是将当前所有运行的状态记录下来,后面可以恢复到这个快照,就是恢复到创建快照时候机器的所有配置与状态)然后实现对这个分区数据的一个备份。原则上,可以备份任何类型的数据库 mysql,MonoDB,Innodb,但是比较麻烦而且还需要对数据库进行上锁,只能读取,不能够写入。
    XtraBackup: 能够实现在写入的同时对数据库进行备份处理,性能比较高,并且还不需要对数据库进行加锁。支持全量备份,与增量备份。
    全量备份与增量备份:数据的全部备份就是对数据库进行全部的备份,增量备份就是哪些数据发生了变化就对哪些数据进行备份。对于第一次的备份一定要采用全量备份,后面时候可以采用到增量备份。

    展开全文
  • 数据库集群数据库集群数据库集群数据库集群
  • 数据库分发客户的请求海量增加,致使集群系统的响应能力大幅度下降。...完成对数据库集群系统多指标动态负载均衡的技术研究。实验的结果表明,该方法减少了集群系统存在的瓶颈,增强了集群系统的响应能力。
  • 详细讲述了lvs+keepalived+mysql cluster集群,非常不错的资源,其中还有mysql各节点配置的详细参数的解释!
  • 数据库集群Mycat搭建和配置
  • #KunLun分布式数据库集群KunLun分布式数据库集群(Kunlun DDC)是一个分布式关系数据库管理系统,开发用于管理大量(数TB甚至PB级)的关系数据和#KunLun分布式数据库集群KunLun分布式数据库集群(Kunlun DDC) )是...
  • Moebius集群的架构 Moebius集群采用无共享... Moebius集群由一组数据库服务器组成,每个服务器上安装相同的数据库集群支持无共享磁盘架构,各机器可以不连接一个共享设备,数据可以存储在每个机器自己的存储介质中。
  • 对异构数据库集群中间件的研究,即对于负载均衡的分析和设计。使用了三层体系架构模式,基于中间件技术而设计的,其中间件为一个构建在普通硬件上的数据库集群中间件,把网络内的各种异构数据库进行连接,组建起数据库...
  • 数据库集群的搭建

    万次阅读 2018-05-14 18:47:10
    对数据的各种操作也是愈加的困难,传统的关系型数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性,减少对事务的支持,减少对复杂查询的支持,来获取...
  • 网站集群部署数据库技术设计方案,网站集群部署设计方案 数据库集群部署方案

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 418,545
精华内容 167,418
关键字:

数据库集群