技术干货 | GreatDB新一代读写分离架构，如何炼就近乎0损耗的性能？

旁门
旁门 2023-11-07 10:18:00 52457
分类专栏： 资讯
优化数据库性能并降低成本是每位架构师和DBA都必须面对的挑战。其中，读写分离是一种常见方法：即通过将读操作和写操作分发到不同的数据库实例，实现多副本负载和性能提升。

 

传统的中间件方案，例如基于Proxysql、HAProxy、MySQL Router等方案，中间件路由转发效率瓶颈会导致性能明显下降，并且发生故障时，中间件的维护、数据库主备副本切换后的数据一致性判断、实例可用性等都需要DBA介入处理。

 

图片

（传统读写分离架构）

 

那么，如何优化读写分离的中间件层或架构呢？

 

 
一、GreatDB Paxos高可用架构

我们来看下万里安全数据库GreatDB如何实现读写分离架构：  

图片

读写分离的核心思想是将数据库的读操作和写操作分发到不同的数据库实例。通常情况下，业务SQL读写操作会被分发到主库（primary）上，而只读操作则被分发到其他副本节点（secondary）。

GreatDB Paxos+VIP架构通过判断数据库primary、secondary等角色节点，对外暴露读写VIP或只读VIP的方式提供给业务层。业务侧只需要接入不同的只读VIP和可读写VIP，即可实现读、写业务在不同数据库实例上完成，从而提供高效的数据读写分离。

 

 
二、安装配置步骤

 

安装前准备工作：

名称

主机信息

读写VIP预分配

软件包版本

操作系统

组复制primary节点

172.17.134.68

读写VIP：172.17.134.200

DB：GreatDB-6.0.3

CentOS7.6

组复制secondary1节点

172.17.134.61

只读VIP：172.17.134.201

辅助工具：GreatADM管理平台

 X86平台

组复制secondary2节点

172.17.134.60

只读VIP：172.17.134.201

压测工具：sysbench

  

1、初始化Paxos实例部署组复制

    我们使用GreatADM管理平台快速部署GreatDB Paxos架构。按照规划，172.17.134.68为primary主实例，172.17.134.60-61为secondary 从实例，GreatADM自动在拓扑上打上数据库database_1-database_3的标签，方便大家辨识数据库实例节点。如下：

 

图片

 

2、加载VIP PLUGIN并配置写VIP

通过图形化运维管理平台GreatADM在线加载VIP配置插件"greatdb_ha.so"，默认提供基于primary主实例的读写vip配置，基于secondary从实例的只读vip，则可根据用户实际读写比例按需进行配置。过程如下：

 

图片

 

查看对应3个GreatDB实例的cnf配置文件，增加了如下几项参数：

  • SQL
  • 登录数据库，可通过show plugins命令查看加载的高可用插件
  • mysql> show plugins;
  • +----------------------------------+----------+--------------------+----------------------+---------+
  • | Name | Status | Type | Library | License |
  • +----------------------------------+----------+--------------------+----------------------+---------+
  • ......
  • | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
  • | greatdb_ha | ACTIVE | DAEMON | greatdb_ha.so | GPL |
  • +----------------------------------+----------+--------------------+----------------------+---------+
参数具体作用介绍：
  • SQL
  • 1、启用VIP plugin 开启新插件，在my.cnf配置文件中增加
  • plugin_load_add=greatdb_ha.so
  • 或者在启动数据库实例后， 执行
  • install plugin greatdb_ha soname 'greatdb_ha.so';
  • 2、开启浮动VIP功能
  • loose-greatdb_ha_enable_mgr_vip = 1
  • 3、配置写浮动ip，写vip会随着primary主实例的切换漂移到新主实例上，做到绑定primary主实例的vip切换
  • loose-greatdb_ha_mgr_vip_ip = 172.17.134.200
  • 4、配置VIP所在网段的子网掩码
  • loose-greatdb_ha_mgr_vip_mask = '255.255.255.0'
  • 5、配置网卡名称，插件会将vip绑定到组复制的primary主实例所在机器指定网卡，比如配置为eth0，
  • 为了防止网卡原有的ip被覆盖，实际绑定后，会绑定在名为eth0:0的网卡子口上
  • loose-greatdb_ha_mgr_vip_nic = 'eth0'
  • 6、目前只支持单主MGR模式，所以需要设置：
  • loose-group_replication_single_primary_mode= TRUE
  • loose-group_replication_enforce_update_everywhere_checks= FALSE

 

注意事项：
启用VIP绑定网卡，因需要root操作系统权限，需要做提权操作。
配置浮动IP需要相关内核权限，方法有两种，如下：

方法1：给greatdbd进程的启动用户（例如是greatdb用户）设置root权限，通过setcap为greatdbd可执行文件添加CAP_NET_ADMIN和CAP_NET_RAW的capability。需要sudo权限或root调用setcap命令，如下提权：

  • SQL
  • setcap CAP_NET_ADMIN,CAP_NET_RAW+ep bin/greatdbd


如果是setcap命令为greatdbd添加capability后， 需要登录系统的用户和启动greatdbd的保持一致，用root用户登录系统，再用普通用户启动greatdbd，setcap会失效，从而绑定浮动IP的时候报错没有权限。

方法2：对于LD_LIBRARY_PATH：可以把非系统目录下的动态库添加软链接到系统库，或在/etc/ld.so.conf.d/ 下添加greatdb.conf文件，并添加非系统库路径，一般是/path/to/greatdb/bin/../lib/private， 可以通过ldd bin/greatdbd查看。

  • SQL示例如下：
  • [root@gip ~]# cat /etc/ld.so.preload
  • /greatdb/svr/greatdb/bin/../lib/private/libcrypto.so.1.1
  • /greatdb/svr/greatdb/bin/../lib/private/libssl.so.1.1
  • /greatdb/svr/greatdb/bin/../lib/private/libprotobuf-lite.so.3.19.4
完整greatbdb_ha.so plugin加载之后的my.cnf增加的参数：
  • SQL
  • [mysqld]
  • plugin-load-add=greatdb_ha.so
  • loose-greatdb_ha_enable_mgr_vip=1
  • loose-greatdb_ha_mgr_vip_ip =172.17.134.200
  • loose-greatdb_ha_mgr_vip_mask=255.255.0.0
  • loose-greatdb_ha_mgr_vip_nic=eth0
  • loose-group_replication_single_primary_mode=1
  • loose-group_replication_enforce_update_everywhere_checks=0

 

3、手动启用只读VIP并做配置

只读VIP可根据用户实际需求选配，当然用户可直接接入secondary节点，接入只读VIP的好处是：当secondary节点故障时可自动切换，保证业务的连续性。

接下来，只读vip是默认在两个secondary实例上配置浮动vip，配置方式如下：

  • JavaScript
  • 配置读浮动ip， secondary节点会绑定读ip,允许配置多个只读vip，中间以‘,’逗号分隔，有几个secondary节点就可以配置几个read_vip
  • loose-greatdb_ha_mgr_read_vip_ips = "172.17.134.201"
当然，当secondary故障，也可选择读vip转移到primary实例，需要按需设置如下参数：
  • SQL
  • loose-greatdb_ha_mgr_read_vip_floating_type = "TO_ANOTHER_SECONDARY"
  • 配置读ip失效以后的处理方式有2种，分为两个参数值（"TO_PRIMARY", "TO_ANOTHER_SECONDARY"）：
  • 当secondary节点故障是，重新绑定到primary上，或者重新绑定到另外一个活动的secondary节点上，默认值是TO_PRIMARY绑定到primary上。

 

两种模式下，vip故障切换过程如下：

假如GreatDB的3个数据库节点为A/B/C实例。

实例A为primary实例，其他2个B、C为secondary实例。假如B、C两个节点上支持各配置一个只读VIP，对业务层暴露1个，另1个可作为冗余备用。当主实例故障不可用时，原始绑定primary实例的写VIP会自动漂移到新选举出的primary实例B上。

实例B原有的只读VIP根据配置参数greatdb_ha_mgr_read_vip_floating_type的不同，其漂移行为有所不同：
1、当greatdb_ha_mgr_read_vip_floating_type=TO_PRIMARY时，实例B的读浮动IP将不受影响，因为它当前就是故障后集群的primary主节点；
2、当greatdb_ha_mgr_read_vip_floating_type=TO_ANOTHER_SECONDARY时，实例B的读浮动IP将主动漂移到实例C，即实例C将同时拥有两个读浮动IP。

 

其他参数

配置ARP包广播重复次数。当节点绑定浮动IP以后，广播ARP包来更新广播域内的ARP缓存，此参数是广播次数，默认是5次，合法取值范围为3-20，动态参数。

  • SQL
  •  loose-greatdb_ha_send_arp_packge_times = 5

 

配置通信端口，通过端口进行数据传输。当发生状态变更时，primary node根据原本的绑定关系，按照变更小、平均分配的原则重新分配绑定关系，并将绑定关系通过配置端口发送给secondary 节点， secondary节点根据绑定关系解绑或绑定指定vip。此参数为静态参数，需要重启实例才可生效。

  • Plain Text
  • loose-greatdb_ha_port = 33932

 

配置完成之后，在各个实例节点使用

set global greatdb_ha_force_change_mgr_vip=1 启用完整的写VIP+只读VIP配置，通过show variables like '%vip%'; 查看配置信息。

图片

 

4、查看实例和网卡VIP绑定关系

  • JavaScript
  • ·
  • mysql> select * from performance_schema.replication_group_members;
  • +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  • | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
  • +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  • | group_replication_applier | a4dc970c-6bd6-11ee-bfe0-00163efffd9c | 172.17.134.68 | 3308 | ONLINE | SECONDARY | 8.0.32 | XCom |
  • | group_replication_applier | bc1563c5-6bd6-11ee-bd65-00163e036eee | 172.17.134.61 | 3308 | ONLINE | PRIMARY | 8.0.32 | XCom |
  • | group_replication_applier | bc16dfeb-6bd6-11ee-a8c1-00163ee52ace | 172.17.134.60 | 3308 | ONLINE | SECONDARY | 8.0.32 | XCom |
  • +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  • 3 rows in set (0.00 sec)
1、查看primary 172.17.134.61实例主机的IP绑定信息，读写vip绑定在172.17.134.61主机eth0网卡上：
2、[root@gip ~]# ip a |grep eth0eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    inet 172.17.134.61/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0    inet 172.17.134.200/20 brd 172.17.143.255 scope global secondary eth0:1
3、查看secondary 实例主机的IP绑定信息如下，只读vip绑定在172.17.134.60主机eth0网卡上
4、[root@gip ~]# ip a|grep eth0eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    inet 172.17.134.60/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0    inet 172.17.134.201/20 brd 172.17.143.255 scope global secondary eth0:0[root@gip ~]# [root@gip ~]# 

 

接下来，我们用sysbench来实际测试下写VIP+只读VIP的读写分离效果。

 

三、读写分离测试

 

使用sysbench数据库进行读写分离测试，分别使用oltp_read_write.lua + 写vip172.17.134.200做数据初始化写入，用oltp_read_only.lua+ 只读vip 做数据readonly查询。

首先连接写VIP创建测试库test_vip；并直接sysbench初始化写入测试数据，命令如下：

  • SQL
  • [root@gip ~]# greatdb -ugreatdb -p'!QAZ2wsx' -h172.17.134.200 -P3308 -e "create database test_vip" ；sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=172.17.134.200 --mysql-port=3308 --mysql-user=greatdb --mysql-password='!QAZ2wsx' --mysql-db=test_vip --report-interval=1 --tables=10 --table-size=100000 --time=60 --threads=10 prepare ；
  • sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
  • Initializing worker threads...
  • Creating table 'sbtest1'...
  • Creating table 'sbtest3'...
  • Creating table 'sbtest9'...
  • Creating table 'sbtest4'...
  • Creating table 'sbtest10'...
  • Creating table 'sbtest6'...
  • Creating table 'sbtest5'...
  • Creating table 'sbtest7'...
  • Creating table 'sbtest2'...
  • Creating table 'sbtest8'...
  • Inserting 100000 records into 'sbtest3'
  • Inserting 100000 records into 'sbtest9'
  • Inserting 100000 records into 'sbtest6'
  • Inserting 100000 records into 'sbtest1'
  • Inserting 100000 records into 'sbtest4'
  • Inserting 100000 records into 'sbtest7'
  • Inserting 100000 records into 'sbtest5'
  • Inserting 100000 records into 'sbtest8'
  • Inserting 100000 records into 'sbtest2'
  • Inserting 100000 records into 'sbtest10'
  • Creating a secondary index on 'sbtest10'...
  • Creating a secondary index on 'sbtest7'...
  • Creating a secondary index on 'sbtest9'...
  • Creating a secondary index on 'sbtest6'...
  • Creating a secondary index on 'sbtest1'...
  • Creating a secondary index on 'sbtest2'...
  • Creating a secondary index on 'sbtest5'...
  • Creating a secondary index on 'sbtest3'...
  • Creating a secondary index on 'sbtest4'...
  • Creating a secondary index on 'sbtest8'...
  • [root@gip ~]#
  • 查看初始化的数据信息
  • [root@gip ~]# greatdb -ugreatdb -p'!QAZ2wsx' -h172.17.134.200 -P3308 -e "show tables from test_vip"
  • greatdb: [Warning] Using a password on the command line interface can be insecure.
  • +--------------------+
  • | Tables_in_test_vip |
  • +--------------------+
  • | sbtest1 |
  • | sbtest10 |
  • | sbtest2 |
  • | sbtest3 |
  • | sbtest4 |
  • | sbtest5 |
  • | sbtest6 |
  • | sbtest7 |
  • | sbtest8 |
  • | sbtest9 |
  • +--------------------+
  • [root@gip ~]#
  • [root@gip ~]# ip a |grep eth0
  • 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
  • inet 172.17.134.61/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0
  • inet 172.17.134.200/20 brd 172.17.143.255 scope global secondary eth0:1
  • [root@gip ~]# 
数据初始化成功，测试数据正常写入，写vip有效绑定primary主实例，数据库可正常写入和查询。

只读vip压测：

  • SQL
  • [root@gip ~]#sysbench --test=/usr/share/sysbench/oltp_read_only.lua --mysql-host=172.17.134.201 --mysql-port=3308 --mysql-user=greatdb --mysql-password='!QAZ2wsx' --mysql-db=test_vip --report-interval=1 --tables=10 --table-size=100000 --time=60 --threads=5 run
  • WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
  • sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
  • Running the test with following options:
  • Number of threads: 5
  • Report intermediate results every 1 second(s)
  • Initializing random number generator from current time
  • Initializing worker threads...
  • Threads started!
  • [ 1s ] thds: 5 tps: 49.92 qps: 844.67 (r/w/o: 739.84/0.00/104.83) lat (ms,95%): 167.44 err/s: 0.00 reconn/s: 0.00
  • [ 2s ] thds: 5 tps: 54.96 qps: 895.40 (r/w/o: 785.48/0.00/109.93) lat (ms,95%): 108.68 err/s: 0.00 reconn/s: 0.00
  • [ 3s ] thds: 5 tps: 52.03 qps: 803.46 (r/w/o: 699.40/0.00/104.06) lat (ms,95%): 179.94 err/s: 0.00 reconn/s: 0.00
  • [ 4s ] thds: 5 tps: 45.99 qps: 731.90 (r/w/o: 639.91/0.00/91.99) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
  • [ 5s ] thds: 5 tps: 47.02 qps: 757.29 (r/w/o: 664.26/0.00/93.04) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
  • [ 6s ] thds: 5 tps: 45.99 qps: 749.82 (r/w/o: 656.84/0.00/92.98) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
  • [ 7s ] thds: 5 tps: 46.02 qps: 720.33 (r/w/o: 628.28/0.00/92.04) lat (ms,95%): 297.92 err/s: 0.00 reconn/s: 0.00
  • [ 8s ] thds: 5 tps: 47.97 qps: 764.58 (r/w/o: 669.63/0.00/94.95) lat (ms,95%): 282.25 err/s: 0.00 reconn/s: 0.00
  • [ 9s ] thds: 5 tps: 43.98 qps: 716.64 (r/w/o: 627.69/0.00/88.96) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
  • [ 10s ] thds: 5 tps: 49.05 qps: 773.79 (r/w/o: 676.69/0.00/97.10) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
  • [ 11s ] thds: 5 tps: 43.96 qps: 721.41 (r/w/o: 632.48/0.00/88.93) lat (ms,95%): 303.33 err/s: 0.00 reconn/s: 0.00
  • [ 12s ] thds: 5 tps: 50.02 qps: 793.33 (r/w/o: 693.29/0.00/100.04) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
  • [ 13s ] thds: 5 tps: 46.97 qps: 754.54 (r/w/o: 660.60/0.00/93.94) lat (ms,95%): 308.84 err/s: 0.00 reconn/s: 0.00
  • [ 14s ] thds: 5 tps: 40.03 qps: 634.51 (r/w/o: 554.45/0.00/80.06) lat (ms,95%): 325.98 err/s: 0.00 reconn/s: 0.00
  • [ 15s ] thds: 5 tps: 52.00 qps: 835.06 (r/w/o: 732.05/0.00/103.01) lat (ms,95%): 108.68 err/s: 0.00 reconn/s: 0.00
  • ......
  • [root@gip ~]# ip a|grep eth0
  • 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
  •  inet 172.17.134.60/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0
  • inet 172.17.134.201/20 brd 172.17.143.255 scope global secondary eth0:0
  • [root@gip ~]# 
尝试连接只读VIP做写入操作：
[root@gip ~]#greatdb -ugreatdb -p'!QAZ2wsx' -h172.17.134.201 -P3308 -e "create database test_write" 
greatdb: [Warning] Using a password on the command line interface can be insecure.
ERROR 1290 (HY000) at line 1: The MySQL server is running with the --super-read-only option so it cannot execute this statement
[root@gip ~]# 
 结论：只读VIP可正常做只读压测，绑定secondary节点，只读功能正常，拒绝写入数据。

 

 

 
四、方案优势

 

通过读写分离架构和网卡子口绑定VIP的方式，可以实现数据库实例的分离和近0性能损耗的目标。

GreatDB Paxos+VIP架构优化精简了中间件的SQL转发过程，从根本上做到了读写负载分离，且greatdb_ha.so plugin和数据库集成于一身，实现了简单、易用、高效，具体优势如下：

1
提高数据库性能

通过将读操作和写操作分发到不同的数据库实例，可以充分利用多副本负载的优势，提高数据库的性能和响应速度；

2
降低成本

基于现有的物理网卡子口，实现网络带宽的高效使用，无需独立部署中间件层，剔除人工维护中间件时间，降低硬件成本；

3
增强可用性

在主节点发生故障时，只读VIP可以自动转移到其他活动的实例节点继续提供服务，避免了单点故障和瓶颈问题，增强了系统可用性和稳定性；

4
简化维护和管理

内置plugin方式，解决了传统业务借助keepalived、lvs等外部软件安装部署及配置的过程，并且可以动态灵活地启用、禁用，搭配万里数据库GreatADM图形化管理平台，可实现一键式的交付部署，提升整体方案交付效率；

5
扩展性增强

读写分离架构和网卡子口绑定VIP+paxos高可用组复制，可以更方便地实现扩展。最多可扩展为9个数据副本，实现系统的在线水平扩展，从而能够满足客户日益增长的业务需求。

 

综上所述，使用GreatDB Paxos+VIP架构既可保证业务层读写分离的诉求，又能尽可能地减少性能损耗，使性能损耗近乎为0。与此同时，保证了故障切换对业务透明，不需要DBA过多技术投入、维护代价较低。

因此，对于需要提高数据库性能并降低成本的企业来说，GreatDB Paxos+VIP架构是一种非常有吸引力的高可用方案。

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=28124
赞同 0
评论 0 条

相关文章

  • 技术干货｜tp5, laravel, yii2我该选择哪个？ 2022-09-16 52801 浏览

    没有最好，只有更适合和语言之争一样，框架一样没有那个最好这种说法，只有更适合。这里的更适合我要给大家解释下。1、更适合是 你非常了解一个框架 ，一定要注意不是因为你使用过 就一定更适合，因为只有你认证

  • 【总结帖】2023年达梦技术干货攻略年度合集 2024-01-12 50270 浏览

    【干货攻略】栏目是达梦数据定期发布的达梦数据库相关技术知识的分享板块。自2016年以来，【干货攻略】栏目已持续为大家分享技术干货文章两百多篇。本文为大家盘点2023年已发布的数据库干货攻略，以年度合集的方式展现给大家。一起来看看，2023年度达梦数据发布了哪些干货攻略吧！（点击文章标题即可访问原文）日常运维【干货攻略】notin遇到null是如何形成大坑的【干货攻略】达梦检查点运行机制【干货攻略】

  • 【干货】信创电脑的测试技术 2023-11-20 52263 浏览

    |信创电脑的简介先介绍一下什么是信创？信创：即信息技术应用创新产业，主要包括基础设施、基础软件、应用软件和信息安全等四大领域，是基于改变中国信息产业“缺芯少魂”现状、建立中国自主完整信息产业链、提升国内信息产业竞争力、保障国家信息安全的战略考虑，逐渐发展演变出的创新产业。从产业链角度看，信创产业主要由基础硬件、基础软件、应用软件、信息安全4部分构成，其中芯片、整机、操作系统、数据库、中间件是最重要

  • 雍正优选 | 本周硬核干货及技术活动推荐！ 2023-07-10 53507 浏览

    金牌播报员姓名：雍正技能：专治八阿哥（BUG）职责：行业资讯、发版报道雍正喵每周汇总，是本喵在社区打工的固定工作。准时为大家精选行业内优质的技术分享，掌握最新动态。爱可生开源社区，一个有深度的MySQL社区，喵~播报详情本周行业分享精选_●MYSQL5.7性能优化心得篇【海鲨数据库架构师】►点击阅读_●为什么需要插入意向锁？【一树一溪】►点击阅读_●MySQL：每次update一定会修改数据吗？【

  • 技术干货分享！东方通＆云祺联合直播揭秘数据保护新方案 2023-06-25 51018 浏览

    驱动数据保护，共筑数字安全。6月27日下午15:00，东方通“通享会”直播将与云祺科技带来首次联合直播。本次活动中，邀请到云祺高级技术工程师代小龙分享相关数据备份技术与云祺灾备实践经验，同时，东方通生态发展部总经理张荃还将与其围绕数据安全保护展开多角度、多层次的互动交流，共同输出技术干货、宝贵经验、前沿观点......精彩无限，值得关注!东方通软件学堂，将在06月27日15:00直播预约嘉宾：成都

  • 干货时间：聊聊DevOps下的技术系列之契约测试 2023-12-29 48351 浏览

    1、服务交互带来的问题在上一篇文章中，我们系统的列举了DevOps各个流程中常用的测试技术。接着上一篇的图，我们简单画下一个系统应用的内部服务的调用关系：交付一个大的系统可能涉及到多家ISV进行集成，每家ISV自己又存在前端、网关、后端等多个微服务，且各自ISV或者服务均存在自己的SE、开发和测试人员，都有自己相对独立的版本演进，服务之间存在调用关系。思考一下，这会带来哪些问题呢？通过接口文档或者

  • 技术干货分享！东方通＆云祺联合直播揭秘数据保护新方案 2023-06-25 53332 浏览

    驱动数据保护，共筑数字安全。6月27日下午15:00，东方通“通享会”直播将与云祺科技带来首次联合直播。本次活动中，邀请到云祺高级技术工程师代小龙分享相关数据备份技术与云祺灾备实践经验，同时，东方通生态发展部总经理张荃还将与其围绕数据安全保护展开多角度、多层次的互动交流，共同输出技术干货、宝贵经验、前沿观点......精彩无限，值得关注!东方通软件学堂，将在06月27日15:00直播预约嘉宾：成都

  • 【技术干货】关于医疗数据库承载，今天聊点儿实在的 2023-07-10 52754 浏览

    随着医院信息管理系统(HIS)的逐步升级与信息平台、科研平台等新业务的上线，医院数据的使用分析从原来的业务辅助，转变成为信息化建设的重要应用。但无论数据库是否采用虚拟化技术承载，或者是否采用容灾、双活等高可靠技术，依然会由于各种不可控因素导致业务暂停或者数据丢失，如何杜绝这类情况？此外，随着医院业务类型与业务系统数量的增多，集中式数据库不再是医疗数据库的唯一选择，我们也看到了大量分布式数据库在医院

  • 重温杨廷琨的19篇技术解析干货，重识盖国强眼中这位值得信赖的创业伙伴 2023-12-20 49787 浏览

    上期彩蛋视频杨廷琨老师说到，作为一个优秀的DBA，要能够做到深入钻研、胆大心细，保持持续学习的能力；杨长老本人也是这样做的，通过在工作学习中不断积累技术知识和经验，并养成记录的习惯，以便时时回顾、常看常新。小编今天选取了杨长老多篇技术解读文章，希望能给大家带来有益参考~SQL语句中常量的处理SQL调优之一次更新操作的优化SQL优化之为何增加DISTINCT后查询效率反而提高？Oracle中的NUL

  • 【技术干货】关于医疗数据库承载，今天聊点儿实在的 2023-07-10 47195 浏览

    随着医院信息管理系统(HIS)的逐步升级与信息平台、科研平台等新业务的上线，医院数据的使用分析从原来的业务辅助，转变成为信息化建设的重要应用。但无论数据库是否采用虚拟化技术承载，或者是否采用容灾、双活等高可靠技术，依然会由于各种不可控因素导致业务暂停或者数据丢失，如何杜绝这类情况？此外，随着医院业务类型与业务系统数量的增多，集中式数据库不再是医疗数据库的唯一选择，我们也看到了大量分布式数据库在医院

旁门
旁门L1
粉丝 0 发表 16 + 关注 私信
上周热门
如何使用 StarRocks 管理和优化数据湖中的数据？  2951
【软件正版化】软件正版化工作要点  2872
统信UOS试玩黑神话：悟空  2833
信刻光盘安全隔离与信息交换系统  2728
镜舟科技与中启乘数科技达成战略合作，共筑数据服务新生态  1261
grub引导程序无法找到指定设备和分区  1226
华为全联接大会2024丨软通动力分论坛精彩议程抢先看！  165
2024海洋能源产业融合发展论坛暨博览会同期活动-海洋能源与数字化智能化论坛成功举办  163
点击报名 | 京东2025校招进校行程预告  163
华为纯血鸿蒙正式版9月底见！但Mate 70的内情还得接着挖...  159
本周热议
我的信创开放社区兼职赚钱历程 40
今天你签到了吗？ 27
如何玩转信创开放社区—从小白进阶到专家 15
信创开放社区邀请他人注册的具体步骤如下 15
方德桌面操作系统 14
用抖音玩法闯信创开放社区——用平台宣传企业产品服务 13
我有15积分有什么用? 13
如何让你先人一步获得悬赏问题信息？（创作者必看） 12
2024中国信创产业发展大会暨中国信息科技创新与应用博览会 9
中央国家机关政府采购中心：应当将CPU、操作系统符合安全可靠测评要求纳入采购需求 8
热门标签更多

加入交流群

请使用微信扫一扫!