GBase8a 数据库集群v953扩容案例问题分享

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 Tair(兼容Redis),内存型 2GB
简介: GBase8a 数据库集群v953扩容案例问题分享

概述
某个项目的GBase8a集群v953版本计划在多vc其中的vc1扩容3节点双实例,分享如何回退重分布,及无法取消重分布如何手工介入解决。

问题分析及处理
集群总体环境如下:

集群版本:GBase8a_MPP_Cluster-953.27.20-patch6.2

集群操作系统:kylin v10

1.回退重分布
参照v95扩容步骤在重分布过程中采用rebalance database dbname的方式以库为单位扩容,期间观察扩容节点的空间变化,发现重分布完成后空间没有变化,查询gbase.table_distribution发现大部分都是随机表,当前版本的gcluster_rebalancing_random_table_quick_mode参数默认值是1开启的状态,

关于该参数的说明参考如下:

因为随机分布表的特性,数据在任何节点都不影响查询结果,而且大部分随机分布表都是大表,也就是不适合选择某个列做Hash分布表。而这种表因为磁盘占用大,如果参与重分布,则需要大量的时间,所以数据库提供了参数,默认随机分布表做快速重分布,不重新分散数据,而是保留现有数据状态。

调整随机表参数
Set global gcluster_rebalancing_random_table_quick_mode = 0;

此时需要回退重分布的随机表

获取切片id
查看gcadmin showdistribution vc vc1 查看对应的切片信息, State: old获取对应的 Distribution ID: 1

清理重分布任务表
delete from gclusterdb.rebalancing_status;

回退重分布
命令

rebalance {instance|database dbname|table tbname} [to distributionID]

说明

该重分布命令,默认是将老的分布策略(distributionid 较小的),重分布到新的(较大的),在某些情况下,也存在要回退的可能性,比如随机分布表默认是快速重分布,但现场因为磁盘空间问题做的扩容,参数忘记设置了,而此时只有部分表做了重分布操作。清理现有任务,避免后续的重分布 delete from rebalancing_status; 回退到老的分布策略 通过rebalance table to 方法,将表回退到1,注意其中的gclusterdb.rebalancing_status不能手工回退。

gbase.table_distribution查找对应db的随机表名称并拼接sql批量执行 : rebalance table tablename to 1;

再次清理重分布任务表
delete from gclusterdb.rebalancing_status;

重新开始重分布
参考重分布方案,不再重复。

2.手动介入取消重分布
由于大表重分布过程中遇到跑批锁表情况,需要取消重分布释放锁。

cancel reablance table tablename 指定表名的方式取消重分布

正常情况下会回滚取消,现场取消等待接近一个小时还未回滚完成,检查数据节点空间也没有任何释放。

通过查询所有vc1的数据节点执行:

gncli -ugbase -pxxxxxx -e”show processlist”|grep -iv sleep

查看任务存在:

select * from db.tablename limit 0,1000000000 target into server字样的任务正在rollback回滚的状态

gncli执行 kill 对应会话id后释放任务

再观察gclusterdb.rebalacing_status的状态已经取消了。

相关文章
|
2月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
3月前
|
SQL 数据库 数据安全/隐私保护
数据库数据恢复——sql server数据库被加密的数据恢复案例
SQL server数据库数据故障: SQL server数据库被加密,无法使用。 数据库MDF、LDF、log日志文件名字被篡改。 数据库备份被加密,文件名字被篡改。
|
3月前
|
存储 NoSQL 数据库
Redis 逻辑数据库与集群模式详解
Redis 是高性能内存键值数据库,广泛用于缓存与实时数据处理。本文深入解析 Redis 逻辑数据库与集群模式:逻辑数据库提供16个独立存储空间,适合小规模隔离;集群模式通过分布式架构支持高并发和大数据量,但仅支持 database 0。文章对比两者特性,讲解配置与实践注意事项,并探讨持久化及性能优化策略,助你根据需求选择最佳方案。
132 5
|
4月前
|
SQL 关系型数据库 数据库
【YashanDB知识库】OM仲裁节点故障后手工切换方案和yasom仲裁重新部署后重新纳管数据库集群方案
本文介绍了主备数据库集群的部署、OM仲裁故障切换及重新纳管的全过程。首先通过解压软件包并调整安装参数完成数据库集群部署,接着说明了在OM仲裁故障时的手动切换方案,包括关闭自动切换开关、登录备节点执行切换命令。最后详细描述了搭建新的yasom仲裁节点以重新纳管数据库集群的步骤,如生成配置文件、初始化进程、执行托管命令等,确保新旧系统无缝衔接,保障数据服务稳定性。
|
4月前
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,展现卓越性能与性价比。其轻量版满足国产化需求,兼具高性能与低成本,适用于多种场景,推动数据库技术革新与发展。
|
1月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—oracle数据库执行错误truncate命令的数据恢复案例
oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下,oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况,例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。
|
3月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
3月前
|
SQL 存储 分布式数据库
分布式存储数据恢复—hbase和hive数据库数据恢复案例
分布式存储数据恢复环境: 16台某品牌R730xd服务器节点,每台服务器节点上有数台虚拟机。 虚拟机上部署Hbase和Hive数据库。 分布式存储故障: 数据库底层文件被误删除,数据库不能使用。要求恢复hbase和hive数据库。
139 12