精华内容
下载资源
问答
  • 技术创新变革未来 ORACLE数据库双活RAC实践 目录 1多租户数据库 6DataPump的新特性 212c R2 sharding 7在线迁移活跃数据文件 3IN Memory 8表分区或子分区在线迁移 4多LGWR进程 9不可见字段 5RMAN Recover Table ...
  • 数据库双活部署

    2018-09-08 14:35:49
    介绍农行的数据库实现双活的案例,非常有参考价值。 实现灾备,实现快速反应。
  • PAGE \* MERGEFORMAT 10基于 Oracle数据库双活方案对比分析Oracle RAC/ADG/OGG1.基于Oracle数据库技术的容灾方案都有哪些?如何选择?容灾向来是以RPO/RTO来定义其级别,所谓的双活只是业内对某种较高容灾级别的架构...

    PAGE \* MERGEFORMAT 10

    基于 Oracle数据库双活方案对比分析

    Oracle RAC/ADG/OGG

    1.基于Oracle数据库技术的容灾方案都有哪些?如何选择?

    容灾向来是以RPO/RTO来定义其级别,所谓的双活只是业内对某种较高容灾级别的架构的俗称,根据不同的角度对其理解也有所偏差。那么基于此,本人暂且认为只要是两个数据中心同时能提供业务服务的就认为是所谓的双活。在这个前提条件下,从Oracle数据库本身的技术来讲,有这么几种方案。

    ■?基于跨中心实现的远距离RAC架构。?

    1)基于ASM冗余设计实现。?

    2)基于存储集群化之后的分布式存储卷实现。

    ■ 基于Oracle ADG/OGG 实现的主备库架构。

    我们先从大的方案比较:

    1)从RPO角度来看,RAC方案可以做到理论上的绝对同步。ADG可以做到近似同步,但是一般用在异步场合。

    2)从RTO角度来看,RAC方案可以做到理论上的秒级自动故障转移。ADG一般需要人工去实现备库切换,而且需要应用改变连接IP地址,重新启动。

    3)从风险角度来看,RAC方案一旦实现距离拉伸,最大的风险在于远距离光纤条件下的节点之间的数据交互。而ADG方案就没有该风险存在。

    4)从方案的复杂度来看,RAC方案理论上需要第三点的仲裁,需要双中心二层打通等复杂环境条件。而ADG和OGG方案只需要网络三层可达即可。

    5)从投资成本来看,RAC方案实现距离的拉伸之后,需要的环境成本(网络条件、仲裁条件)等都需要较高的成本。ADG和OGG方案没有这些成本。

    由此可以看出,实际上从容灾角度考虑(RTO/RPO),那么RAC方案一定是比ADG方案能实现RTO和RPO的更高目标,但是从成本和风险角度考虑,ADG又是最佳的选择。

    那么撇开成本和风险,只考虑容灾目标的话,我们再来比较一下对于RAC方案的两种不同存储架构的差异:

    1)首先是实现难度及投资比较,ASM冗余设计架构的复杂度在于 ASM 层的设计。Oracle RAC 实例节点看到的共享盘是基于双中心存储实现的镜像策略,所有IO的读写分发是由ASM本身的冗余算法规则来决定的,DBA不仅仅要根据磁盘情况来设计合理的 Failure Group,而且需要结合第三方站点的网络存储卷来合理设计仲裁磁盘组的分配。更重要的是需要结合实际的网络环境指标(延时、稳定性等)进行复杂的性能、稳定性、灾难测试等来调整ASM的一些IO参数。基于分布式存储卷设计架构的复杂度在于整体架构的复杂度。

    例如仲裁一致性问题,是指双中心之间的存储集群和数据库RAC集群的仲裁结果是否能保证一致性。存储集群是靠仲裁站点分别于两个站点之间的网络连通性来判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。二者仲裁时的一致性如何保障是非常重要的一个问题。假设在发生站点级别故障时,数据库集群首先根据网络故障触发仲裁,判定站点A的节点存活。而存储随后再发生存储集群的仲裁,这个时候如果根据仲裁站点判定的结果恰恰仲裁委站点B的节点存活。那么数据库集群整体就会宕掉,这对于业务来讲就是一个灾难。

    2)从实现的基本条件来看,两种架构的实现都会依赖双中心的二层打通。双中心的波分设备、以太转换设备、光纤链路租用就是必不可少的条件了。包括其购置成本和日后的运维成本等。这是非常可观的一项成本预算。从存储层的架构组成来看,ASM冗余设计架构不需要存储层增加任何其他设备成本及运维成本。但是分布式存储卷架构需要依赖存储层的虚拟化网关产品来实现存储虚拟化集群,无疑这需要增加相应的购置成本和相应的运维成本。尤其注意存储集群产品是否有容量许可成本问题。从第三点的仲裁站点成本来看,两种方案都需要第三点的仲裁,区别在于ASM冗余设计架构需要的是NAS存储,而分布式存储卷架构需要的基于以太网的计算资源来配置仲裁虚拟机。投入成本没有什么差异。

    3)从Oracle运维成本来看,ASM冗余设计架构对DBA的要求非常苛刻,需要DBA不仅仅能够深知其中的原理,而且需要对性能的分析有较深的造诣,从而保障在复杂的双中心联动环境下各种复杂情况下的性能及稳定性变动有快速和准确的判断和处理能力。分布式存储卷架构对DBA的要求没有特殊的苛刻要求但是需要增加对存储集群的专业维护成本。

    从银行业的角度来看,行业看中的更多的是RPO和RTO以及风险度本身这几个点。

    从RPO和RTO角度来选的话,那么方案一定是RAC的方案。但是从风险角度来考虑的话,那么ADG会是比较好的选择。OGG主要用于异构平台之间的数据传输。但是这几中方案并不是只能选择其中一种而舍弃其他的方案。方案各有优劣,为了尽可能达到整体最优,可以考虑方案的组合。

    比如说同城实现RAC、异地实现ADG。

    展开全文
  • 本PostgreSQL数据库双活部署实例使用Bucardo开源工具实现,Bucardo开源工具是一个perl语言编写的程序,其依赖PG数据库的plperl语言组件,进而严格依赖perl的版本(数据库服务器安装的perl大版本号必须和官方说明的...

    前言:

    本PostgreSQL数据库双活部署实例使用Bucardo开源工具实现,Bucardo开源工具是一个perl语言编写的程序,其依赖PG数据库的plperl语言组件,进而严格依赖perl的版本(数据库服务器安装的perl大版本号必须和官方说明的perl版本严格一致,小版本号不限制),数据库的perl环境记录于$PG_HOME/etc/sysconfig/plLanguages.config。

    环境说明:

    数据库服务器一:

    操作系统版本

    RHEL6.5

    IP地址

    10.19.100.50

    数据库版本

    PostgreSQL-10.1

    数据库端口

    5432

     

    数据库服务器二:

    操作系统版本

    RHEL6.5

    IP地址

    10.19.100.51

    数据库版本

    PostgreSQL-10.1

    数据库端口

    5432

     

    一. 安装前准备

    该步骤在服务器一和服务器二上均需要执行

    1.确定数据库依赖的Perl版本

    $ more /PostgreSQL/10/etc/sysconfig/plLanguages.config
    
    PG_PERL_VERSION=5.24
    PG_PYTHON_VERSION=3.4
    PG_TCL_VERSION=8.6
    
    PG_PERL_PATH=PERL_INSTALL_PATH
    PG_PYTHON_PATH=PYTHON_INSTALL_PATH
    PG_TCL_PATH=TCL_INSTALL_PATH

    2. 检查服务器上已安装的perl版本

    $ perl -v
    
    This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

    如果显示的perl版本不为第一步显示的版本(这里是5.24),则需要重新安装perl(任意小版本均可),我这里使用perl5-5.24.4

    $ tar zxvf perl-5.24.4.tar.gz
    $ cd perl-5.24.4
    ./Configure

    进行Configure时务必不要指定-d参数,其中有2个重要选项不能采用默认配置:

    • Build a shared libperl.so (y/n) [n] 这里要选Y
    • Build a threading Perl? [n]  这里要选Y
    make
    make test
    sudo make install

    3. 检查plperl.so引用

    数据库在创建plperl语言支持时使用的库文件位于$PG_HOME/lib/postgresql/plperl.so(不同版本的数据库可能有所不同),需要检查该库文件的依赖包是否正确。

    $ ldd $PG_HOME/lib/postgresql/plperl.so
            linux-vdso.so.1 =>  (0x00007fff561fa000)
            libperl.so => /usr/lib64/perl5/CORE/libperl.so
            libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc7c2d97000)
            libc.so.6 => /lib64/libc.so.6 (0x00007fc7c2a05000)
            libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc7c27ec000)
            libdl.so.2 => /lib64/libdl.so.2 (0x00007fc7c25e7000)
            libm.so.6 => /lib64/libm.so.6 (0x00007fc7c2363000)
            libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc7c212c000)
            libutil.so.1 => /lib64/libutil.so.1 (0x00007fc7c1f28000)
            /lib64/ld-linux-x86-64.so.2 (0x0000003555000000)
            libfreebl3.so => /lib64/libfreebl3.so (0x00007fc7c1cc6000)

    或者

    $ ldd $PG_HOME/lib/postgresql/plperl.so
            linux-vdso.so.1 =>  (0x00007fff561fa000)
            libperl.so => not found
            libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc7c2d97000)
            libc.so.6 => /lib64/libc.so.6 (0x00007fc7c2a05000)
            libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc7c27ec000)
            libdl.so.2 => /lib64/libdl.so.2 (0x00007fc7c25e7000)
            libm.so.6 => /lib64/libm.so.6 (0x00007fc7c2363000)
            libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc7c212c000)
            libutil.so.1 => /lib64/libutil.so.1 (0x00007fc7c1f28000)
            /lib64/ld-linux-x86-64.so.2 (0x0000003555000000)
            libfreebl3.so => /lib64/libfreebl3.so (0x00007fc7c1cc6000)

    若如上所示,libperl.so引用的是系统自带的非5.24版本的libperl.so或没有引用任何libperl.so,则需要修改ldconfig配置,使perl5-5.24的库文件被包含在ldconfig的搜索路径中:

    $ vi /etc/ld.so.conf.d/perl5-5.24.conf
    /usr/local/lib/perl5/5.24.4/x86_64-linux-thread-multi/CORE

    正确的引用应如下所示

    $ ldd /PostgreSQL/10/lib/postgresql/plperl.so
            linux-vdso.so.1 =>  (0x00007fff1dbff000)
            libperl.so => /usr/local/lib/perl5/5.24.4/x86_64-linux-thread-multi/CORE/libperl.so (0x00007fa26ea0b000)
            libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa26e7ed000)
            libc.so.6 => /lib64/libc.so.6 (0x00007fa26e45b000)
            libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fa26e242000)
            libdl.so.2 => /lib64/libdl.so.2 (0x00007fa26e03d000)
            libm.so.6 => /lib64/libm.so.6 (0x00007fa26ddb9000)
            libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa26db82000)
            libutil.so.1 => /lib64/libutil.so.1 (0x00007fa26d97e000)
            /lib64/ld-linux-x86-64.so.2 (0x0000003834e00000)
            libfreebl3.so => /lib64/libfreebl3.so (0x00007fa26d71c000)

    4. 测试数据库plperl语言组件是否能正确运行

    确保库文件正确以后需要检查一下数据库是否能正确使用该语言组件包,这里创建一个简单的plperl程序检查一下:

    create language plperlu;
    create language plperl;
     
    CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $$
    if ($_[0] > $_[1]) { return $_[0]; }
    return $_[1];
    $$ LANGUAGE plperl;
     
    select perl_max(1,3);
     perl_max
    ----------
    3
    (1 row)

    二. 安装Bucardo及其依赖包

    该步骤在服务器一和服务器二上均需要执行

    1. 安装Bucardo依赖的perl模块

    安装perl模块最方便的方式是使用spam命令从官方服务器上获取模块包及其依赖包,在无法连接官方服务器的内网可以采用下载相应压缩包,编译安装的方式,perl模块下载地址为:http://search.cpan.org/

    • 安装DBI
    $ tar zxvf DBI-1.634.tar.gz
    $ cd DBI-1.634
    $ perl Makefile.PL
    $ make
    $ make test
    $ sudo make install
    • 安装DBD:pg
    $ tar zxvf DBD-Pg-3.5.3.tar.gz
    $ cd DBD-Pg-3.5.3
    $ perl Makefile.PL
    $ make
    $ make test
    $ sudo make install
    • 安装DBIx-Safe
    $ tar zxvf DBIx-Safe-1.2.5.tar.gz
    $ cd DBIx-Safe-1.2.5
    $ perl Makefile.PL
    $ make
    $ make test
    $ sudo make install
    • 安装boolean
    $ tar zxvf boolean-0.45.tar.gz
    $ cd boolean-0.45
    $ perl Makefile.PL
    $ make
    $ make test
    $ sudo make install
    • 安装Test::Simple
    $ tar zxvf Test-Simple-1.001014.tar.gz
    $ cd Test-Simple-1.001014
    $ perl Makefile.PL
    $ make
    $ make test
    $ sudo make install
    • 安装Encode::Locale
    $ tar zxvf Encode-Locale-1.05.tar.gz
    $ cd Encode-Locale-1.05
    $ Perl Makefile.PL
    $ make
    $ make test
    $ sudo make install

    2. 安装Bucardo

    完成上述perl模块以后,Bucardo本身安装非常简单。

    $ export INSTALL_BUCARDODIR=/PostgreSQL/Bucardo
    $ tar zxvf bucardo-5.4.1.tar.gz
    $ cd bucardo-5.4.1
    $ perl MakeFile.pl
    $ make
    $ make test
    $ make install

    同时,需要把INSTALL_BUCARDODIR=/PostgreSQL/Bucardo 设置为.bash_profile中的环境变量

    3. 部署Bucardo辅助对象

    这里需要注意,PG-10.1以后的版本 select version()函数的输出字符串格式有变化,而Bucardo-5.4.1(已经是我写这篇文章时的最新版本)还是采用PG-9.*版本的select version()输出字符串格式做检测,因此需要修改bucardo脚本,否则无法通过版本检测。

    最简单的就是把所有检查脚本的地方全注释掉。找到所有如下语句,全部用##注释。

    ##if ($maj < 8 or (8 == $maj and $min < 1)) {
    ##  die "Sorry, Bucardo requires Postgres version 8.1 or higher. This is only $maj.$min\n";
    ##}

    Bucardo以侵入式的方式在数据库上创建必要的辅助对象,并需要在被同步表上创建触发器。辅助对象通过下面的命令安装:

    $ ./bucardo install
     
    Current connection settings:
    1. Host:           <none>
    2. Port:           5432
    3. User:           postgres
    4. Database:       bucardo
    5. PID directory:  /var/run/bucardo
    Enter a number to change it, P to proceed, or Q to quit: P

    因为Bucardo默认是为PostgreSQL开发的,所以连接的数据库、端口和用户都需要按命令行提示进行修改。如果没有任何报错,那么Bucardo的辅助对象就创建完了。

    三. 利用Bucardo配置数据库双向同步

    服务器一和服务器二上需要预先创建好要同步的对象,这里以下面的建表语句创建的数据库对象为例说明如何配置双向同步

    CREATE TABLE t1
    (
      col1 numeric NOT NULL,
      col2 numeric,
      CONSTRAINT pk_1 PRIMARY KEY (col1)
    )

    这里需要注意一点,被同步的对象一定要有主键,如果没有主键在创建同步队列时会失败。虽然可以通过一些办法强行对无主键表进行同步,但会在同步发生数据冲突时产生不可预料的错误。

    1.  首先配置服务器一向服务器二的同步

    该步骤在仅在服务器一配置

    • 添加源数据库
    $ ./bucardo add database pg50 dbname=postgres port=5432 host=10.19.100.50 user=postgres pass=123456
    Added database "pg50"
    • 添加目标数据库
    $ ./bucardo add database pg51 dbname=postgres port=5432 host=10.19.100.51 user=postgres pass=123456
    Added database "pg51"
    • 添加数据库组
    $ ./bucardo add dbgroup grp1 pg50:source pg51:target
    Created dbgroup "grp1"
    Added database "pg50" to dbgroup "grp1" as source
    Added database "pg51" to dbgroup "grp1" as target
    • 添加表集群(Bucardo是一种已经灭绝的西班牙山羊,所以这里集群是用 herd:羊群)

     

    $ ./bucardo add table public.t1 herd=herd_test
    Added the following tables or sequences:
      public.t1
    Created the relgroup named "herd_test"
    The following tables or sequences are now part of the relgroup "herd_test":
      public.t1

    注意:要同步的表必须有主键

    • 添加同步信息
    $ ./bucardo add sync sync50to51 herd=herd_test dbs=grp1 conflict_strategy=latest

    注意:sync名称需要以字母开头

    conflict_strategy表示解决数据冲突的方式,可为:

    source ,target ,skip, random ,latest ,abort

    • 运行软件并开始同步
    $ sudo mkdir -p /var/log/bucardo
    $ sudo mkdir /bucardo
    $ sudo chown -R postgres:postgres /var/log/bucardo/
    $ sudo chown -R postgres:postgres /bucardo
    $ ./bucardo start

    下面是其他管理用命令

    停止同步:bucardo stop
    暂停/恢复某一组同步:bucardo pause/resume sync50to51
    查看同步状态:bucardo status

    完成以上操作后,所有对服务器一上postgres用户的public.t1表的操作会被同步到服务器二的postgres用户public.t1表上。接下来进行服务器二到服务器一的同步配置以完成双向同步。

    2.  配置服务器二向服务器一的同步(其实就是上一步反过来做)

    该步骤在仅在服务器二配置

    • 添加源数据库
    $ ./bucardo add database pg51 dbname=postgres port=5432 host=10.19.100.51 user=postgres pass=123456
    • 添加目标数据库
    $ ./bucardo add database pg50 dbname=postgres port=5432 host=10.19.100.50 user=postgres pass=123456
    • 添加数据库组
    $ ./bucardo add dbgroup grp1 pg51:source pg50:target
    • 添加表集群
    $ ./bucardo add table t1 herd=herd_test
    • 添加同步信息
    $ ./bucardo add sync sync51to50 herd=herd_test dbs=grp1 conflict_strategy=latest
    • 运行软件并开始同步
    $ sudo mkdir -p /var/log/bucardo
    $ sudo mkdir /bucardo
    $ sudo chown -R postgres:postgres /var/log/bucardo/
    $ sudo chown -R postgres:postgres /bucardo
    $ ./bucardo start

           这样双向同步就配置完成了,所有在服务器二上对postgres数据库下public.t1表的修改也会被同步到服务器一的postgres数据库的public.t1上

     

    转载于:https://www.cnblogs.com/aegis1019/p/9128120.html

    展开全文
  • 数据库双活技术已成为企业重点关注的对象,社区最近组织了交流活动,以帮助大家更好的明确理解数据中心建设。我们将活动内容总结为设计原则、技术选型和五大难点攻克。 前篇见:银行跨数据中心数据库双活架构设计:...

    数据库双活技术已成为企业重点关注的对象,社区最近组织了交流活动,以帮助大家更好的明确理解数据中心建设。我们将活动内容总结为设计原则、技术选型和五大难点攻克。

    前篇见:银行跨数据中心数据库双活架构设计:设计原则及技术选型(点击标题可读)

    本篇交流分享者——本次活动专家:

    孔再华 民生银行 数据库架构师

    冯帅 点融网 高级DBA

    韩成亮 某金融单位 数据库架构师

    还有以下会员热心分享:

    liuhefromoracle Oracle 数据库管理员

    匿名会员

    难点一:数据库双活,如何解决几十公里延时带来的性能问题?

    几十公里的延时主要表现在两方面,一个是存储双写延迟,一个是节点通信延迟。

    从存储延时来说首先要做到本地读。这个在GPFS文件系统里是可以做到的。其次是增大缓存,减少同步写的次数。对于数据库里的大对象,最好使用inline的方式放在常规表空间里,或者存放在开启了文件缓存的表空间里。对于数据库日志,一定要设置足够的日志缓冲池,避免因为缓冲池不够发生的同步写。

    在通信的延迟上,我们需要做到的是尽量减少通信。所以要想办法解决热点数据问题。同时能够本地访问和缓冲的都要想办法实现。例如推荐采用客户端偏好链接。基于current member来组织表和数据等等。(孔再华)

    有个问题,由于CF节点只有一个,对于写来说,必然存在两个站点的DB2 MEMBER都同时需要通过RDMA访问CF节点GBP,本地来说,问题不存在,跨站点RDMA访问的话,这个通信耗时和性能是否需要重点关注?(邓毓)

    你说的非常正确,跨站点的member和CF通信需求是双活环境调优的关键。所以这个就是重点关注的对象,要减少这种交互。数据库提供了mon_get_cf等相关表函数能够抓取CF的功能和耗时,进而分析是什么操作最慢,能不能减少或者调整。(孔再华)

    ※※※

    我从Oracle数据库层RAC说一下吧,个人比较喜欢用ASM,用ASM可以解决一部分性能问题,之所以说一部分是因为ASM也只能解决"读"的问题;

    由于距离产生的延迟,那么最好的办法就是不缩短距离,这个好像是废话,但是对于Oracle ASM的 redundancy来说其实是可以做到的,比如创建Oracle ASM的磁盘组的时候选择的是Normal redundancy的方式,那么磁盘组就会至少有2个failure group ,而我们可以把2个failure group里的物理盘手工的划分到不同的物理位置,一般双活都有2个机房,那么一个failure group里放一个机房的磁盘,另外一个fialure group里放置另外一个机房的磁盘,这样双活也就实现了,但是随即而来的问题就是物理距离的增加和光信号的衰减和传输的性能降低,Oracle ASM考虑到提升一部分功能,在参数里提供了asm_preferred_read_failure_groups这个参数,也就是说当做物理读的时候每一个机房里的节点(RAC节点)都可以配置自己优先读的“机房” ,这样可以保证“读”不受“距离”的影响,但是“写” 是必须要在双节点都完成的,所以对于ASM来说对于“写”也没有特别好的办法解决距离产生的延迟。 当然这个时候如果RAC的节点的使用和划分以及应用层的布置是都慎重考虑的,否则有可能会出现本来业务应该登陆节点1 而因为配置问题缺被随机分到了节点2,那这个时候反而适得其反。(liuhefromoracle)

    ※※※

    数据双活和网络延迟的性能问题是一个很难平衡的问题。常见的方案是采用专线连接,更快的服务器,优化的网络基础设施和应用,而且几十公里的距离只能算同城,对于数据双活而言并不是很大的问题,当然也可以选择较近的距离作为数据中心位置。(韩成亮)

    ※※※

    数据写到主服务器,commit时复制到从服务器。复制完毕commit完成。

    只有commit有性能问题,是批量操作性质,可以把通信开销降到最低。

    但是如果有锁,锁的传递需要时间。

    复制时如果从服务器失效,操作应该依然成功,要在主服务器记录从服务器遗漏事务。待从服务器复活,回复遗漏事务。

    如果写几千条记录到主服务器,这期间没有复制开销。在commit时复制,产生一个批量传输,开销是很小的。

    但是如果主机从机都在录入数据,他们之间是否有重复记录是不易检测的。一个办法是commit时检测,重复数据导致commit失败。如果在恢复遗漏事务时发生重复记录啦,唯一的办法是抛弃重复记录。

    所以主从系统需要阶段性一致性检查,如果有不一致数据,以时间戳最新的为准。(匿名用户)

    难点二:如何解决热点数据在双活环境的问题?

    热点数据是指当前业务频繁访问的数据。如果是单节点数据库,这些数据集中在一起可以提高缓冲池命中率。但是在集群环境恰恰相反!不同数据库成员节点访问同样的热点数据会产生竞争问题。

    所以在集群环境,需要考虑热点数据的分布。大的pagesize会存放更多的row,会有更大的概率产生竞争。所以在集群环境,尽量使用小的pagesize, 例如4K。

    而对于热点表,我们可用通过在使用分区表等数据库技术来从物理上打散当前的热点数据。例如我们在计费系统的双活环境里面,针对热点的日志表,传统分区表一般使用时间列来组合数据,而我们是用了current member这个变量和序列号组合,做了个隐藏列,实现本地节点插入数据落在自己单独的分区里,同时本地分区也是被轮询使用,彻底打散热点数据。部分定义如下:

    "SERIALIZED_REQUEST" BLOB(1048576) INLINE LENGTH 1000 LOGGED NOT COMPACT ,

    "CURMEM" SMALLINT IMPLICITLY HIDDEN WITH DEFAULT CURRENT NODE ,

    "IDKEY" SMALLINT IMPLICITLY HIDDEN GENERATED ALWAYS AS (MOD(ID,10) + MOD(CURMEM,4)*10) )

    COMPRESS YES ADAPTIVE

    INDEX IN "TBS_LOG_IDX_4K" PARTITION BY RANGE("IDKEY")

    (PART "PART0" STARTING(0) IN "TBS_LOG_DAT" INDEX IN "TBS_LOG_IDX_4K" LONG IN "TBS_CLOB_DAT",

    对于热点表的热点索引,建议使用分区索引,random索引等方式。也可以加入current member列作为索引的一部分,从而减少成员节点间的竞争。(孔再华)

    ※※※

    主要是通过部署负载均衡设备,当然热点数据的可以通过读写分离和缓存来实现,业务层面或者架构层面的调整其实是最简洁有效的。(冯帅)

    难点三:在双活环境应该怎么设计数据库对象?

    其实作为双活环境不可避免的存在很多问题,比如说网络延迟,热点数据,数据耦合等,其实最主要是数据的一致性,作为双中心的环境,我们需要保证数据库的一致性,这个就要求我们在设计表或者其他对象的时候需要考虑这方面可能出现的问题,加强对于业务维护时间戳的维护,同时减少双数据中心的单个时间点的高数据交互,对业务逻辑进行拆分打散,避免大事务对复制延迟的影响,这就要求我们在设计表的时候需要进行更加细致的拆分,特别是对于热点数据,尽量使用缓存处理。(韩成亮)

    难点四:本地数据库双活的异地容灾该怎么做?

    数据库双活环境做异地容灾就是选择如何复制数据。复制数据有两种方式,一种是通过存储复制,另一种是通过数据库复制技术。存储复制只需要复制单数据中心的数据,在异地搭建同架构的集群环境(可以使轻量级的,资源配置不要求一致)。我行就有系统通过SRDF存储异步复制技术将数据复制到异地。数据库复制技术更推荐使用。因为数据集复制技术能够规避存储复制坏块的风险。同时对网络带宽的压力也小很多(只复制变化的日志)。这个是更加推荐的方式。(孔再华)

    ※※※

    异地容灾主要看你需要实现什么样的级别。

    常见的容灾方案有

    1 基于存储层的容灾复制方案

    2 基于逻辑卷的容灾复制方案

    3 基于log的逻辑复制方式(ORACLE REDO、MYSQL binlog)

    4 还有一些第三方的软件

    5 自己开发的一些脚本或者工具

    其实,总的来说,本地数据库双活的异地容灾,单活异地容灾最大的区别在于,你以哪个为主,同步的频率,同时,如果你的环境已经是双活,那么异地容灾说白了仅仅是一个冷备。

    至于如何做,需要切合你的业务需求。(韩成亮)

    难点五:有没有针对双活环境的数据库开发规范?

    在双活环境大部分开发规范是和单机数据库的开发规范一样的,但是有写针对这个环境特点的开发规范:

    事务处理设计:

    尽量避免热点数据和不必要的数据重复访问。例如计费系统的查重,入表,更新表等操作,可以改变为最后只插入一条最终的记录。

    尽量将业务分表。例如计费里面将不同的业务计入不同的流水表里面。

    合理设计索引。不要建立不必要的索引,适当使用聚合索引。

    批处理:

    由于CF通信和存储复制的延时,双活环境的单个事务会比单机版慢,所以批处理建议通过提高并发的方式来加快处理速度。

    拆分批处理,将单次批拆成多个批一起跑。例如一天的归档拆成按照小时的归档。

    作业拆分,使用跟多并发的方式处理单个批处理。

    报表:

    在双活环境里面运行实时报表需要慎重,防止GBP的DE空间被占满。尽量避免出现全表扫描的报表。合理安排利用索引,减少记录扫描数量。(孔再华)

    ※※※

    其实还有一些更加严格的安全规范,行为规范

    1. 表结构变更必须通知DBA进行审核。

    2. 禁止有super权限的应用程序账号存在。

    3. 禁止有DDL、DCL权限的应用程序账号存在。

    4. 重要项目的数据库方案选型和设计必须提前通知DBA参与。

    5. 批量导入、导出数据必须通过DBA审核,并在执行过程中观察服务。

    6. 批量更新数据,如UPDATE、DELETE操作,必须DBA进行审核,并在执行过程中观察服务。

    7. 产品出现非数据库导致的故障时,如被攻击,必须及时通DBA,便于维护服务稳定。

    8. 业务部门程序出现BUG等影响数据库服务的问题,必须及时通知DBA,便于维护服务稳定。

    9. 业务部门推广活动或上线新功能,必须提前通知DBA进行服务和访问量评估,并留出必要时间以便DBA完成扩容。

    10. 出现业务部门人为误操作导致数据丢失,需要恢复数据的,必须第一时间通知DBA,并提供准确时间点、 误操作语句等重要线索。

    11. 提交线上建表改表需求,必须详细注明涉及到的所有SQL语句(包括INSERT、DELETE、UPDATE),便于DBA进⾏行审核和优化。

    12. 对同一个表的多次alter操作必须合并为一次操作。

    13. 不要在MySQL数据库中存放业务逻辑。

    14. 禁止在线上做数据库压力测试。

    15. 禁止从测试、开发环境直连数据库。(冯帅)

    活动相关资料:

    银行存储链路稳定性及容错方案分析

    活动地址:http://www.talkwithtrend.com/activity/?id=881返回搜狐,查看更多

    欢迎关注:

    架构师成长营

     

    展开全文
  • 详细描述了如何实现SQL SERVER数据库双活,包括最高等级的数据零丢失容灾,全自动(不需要修改客户代码的)负载均衡读写分离等功能。
  • 云端的数据库多租户;云端的数据库多租户;云端的数据库多租户;云端的数据库多租户;云端的数据库多租户;多租户架构;云端数据库多租户;云端数据库多租户;云端数据库多租户;云端数据库多租户;云端数据库多租户;云端...
  • A,B两端数据库根据业务不同来划分主次对外提供服务,两端数据库都处于活动状态,都能独立工作且双向同步,举个例子,业务A,优先接入A端数据库,同时,A端的数据会同步到B端,B端会有少量业务A接入,同时也需要同步B...

    A,B两端数据库根据业务不同来划分主次对外提供服务,两端数据库都处于活动状态,都能独立工作且双向同步,举个例子,业务A,优先接入A端数据库,同时,A端的数据会同步到B端,B端会有少量业务A接入,同时也需要同步B端数据到A端数据库,当发生数据故障或者网络中断的时候,启用B端数据库作为唯一接入提供方,对外提供服务,在修复好故障或者网络正常后,当数据同步一致性启用A端作为少量业务A的接入方,这里面A,B两端数据库之间通过稳定、低延时的私有专线连接实现数据与配置的同步。这里面会根据延迟的重要性不同和所需网络带宽的确定优先原则,确保业务的持续性,提高用户的访问体验。

    如果业务量不大,没必要做数据库双活,因为数据库双活需要的运维资源成本、开发成本都非常高,注意机房间的延时问题,延时大的可能达到100ms以上,如果业务需要多次跨机房请求应用的话,延迟的问题会彻底放大, 跨机房的专线很大概率会出问题,要做好运维或者程序层面的容错,核心业务和次要业务需要分而治之,双活的业务形式越简单越好,甚至可以只做核心业务,数据库双活的监控、部署、测试等流程也要跟上,在业务允许的情况下,考虑用户分区,特别是用户,订单,活动等业务比较容易做到,控制跨机房消息体大小,越小越好。

    数据双活是片面的,真正的双活,要在数据中心的从上到下各个层面,都要实现双活。存储、服务器、网络、数据库、应用,各层面都要有双活的设计,这样才能真正意义上实现数据中心层面的双活,企业中的IT基础架构设施都是多年发展和积累起来的,从硬件设备、网络、存储、应用软件、中间件到数据库都是各种各样的,不同层面的整合各家又都有不同的技术,在多种可能的技术选择方案中寻求平衡和控制是比较复制的,所以整合我认为是目前实现数据中心双活的难点,技术选型的承上启下更是关键。收起

    展开全文
  • 某银行中有关双数据中心对数据库双活和灾备的建设经验。
  • 原标题:基于 Oracle RAC/ADG/OGG 等设计数据库双活方案,必须掌握五方面知识点上周,社区组织活动就数据库(Oracle)双活方案进行了深入探讨,包括如何选择双活方案、具体方案的复杂度、技术关键点、具体应用场合等等...
  • ...
  • ...
  • 我从Oracle数据库层RAC说一下吧,个人比较喜欢用ASM,用ASM可以解决一部分性能问题,之所以说一部分是因为ASM也只能解决"读"的问题;由于距离产生的延迟,那么最好的办法就是不缩短距离,这个好像是废话,但是对于...
  • 灾备中心要承载业务运行,这已经是一个共识。因此灾备中心的概念也在弱化,取而代之的是IDC数据中心概念。首先数据需要在多数据中心复制,保证数据不丢失。...这也是为什么要做双活的数据中心。 每个系统在...
  • 其实双活这个字眼并不属于容灾范畴,容灾向来是以RPO/RTO来定义其级别,所谓的双活只是业内对某种较高容灾级别的架构的俗称,根据不同的角度对其理解也有所偏差。那么基于此,本人暂且认为只要是两个数据中心同时能...
  • 本文主要向大家介绍了MySQL数据库之MySQL双活部署方案 ,通过具体的内容向大家展现,希望对大家学习MySQL数据库有所帮助。Pactera文思海辉运维云系统MySQL双...部署数据库双活83.1.架构配置83.2.配置复制账户83.3.Ma...
  • 本文主要向大家介绍了MySQL数据库之MySQL双活部署方案 ,通过具体的内容向大家展现,希望对大家学习MySQL数据库有所帮助。Pactera文思海辉运维云系统MySQL双...部署数据库双活83.1.架构配置83.2.配置复制账户83.3.Ma...
  • {"moduleinfo":{"card_count":[{"count_phone":1,"count":1}],"search_count":[{"count_phone":4,"count":4}]},"card":[{"des":"阿里云数据库专家保驾护航,为用户的数据库应用系统进行性能和风险评估,参与配合进行...
  • 数据库性能及容灾一体化解决方案:双重负载均衡、读写分离,彻底解决数据库性能问题;数据库双活集群,彻底解决数据库系统的高可靠性及高可用性问题,做到故障时候数据零丢失,服务不停止。
  • 主要围绕以下五点进行分享:多当中的难点多的架构数据库改造DBA 挑战收益与展望多当中的难点我们先来看一下多的第一个难点:要考虑做多到底是同城的多还是异地的多。跨地域网络延时是现阶段很难突破的...
  • 本文根据 GOPS2017·上海站演讲《饿了么异地双活数据库实战》整理发布 作者简介: 虢国飞,饿了么 DBA负责人 从事数据库行业10+年,专注于MySQL、PgSQL、MSSQL等数据库领域的管理、研究和平台的研发等工作,...
  • Oracle数据库中心双活之道:ASM vs VPLEX 来源 https://www.cnblogs.com/wenjiewang/p/7460212.html 双活方案对比:ASM vs V-PLEX 作者:王文杰 Oracle公司 Principle system analyst Oracle高级服务部 ...

空空如也

空空如也

1 2 3 4 5 ... 17
收藏数 338
精华内容 135
关键字:

数据库双活