PolarDB开源数据库进阶课3 共享存储在线扩容

本文涉及的产品
PolarClaw,2核4GB
简介: 本文继续探讨穷鬼玩PolarDB RAC一写多读集群系列,介绍如何在线扩容共享存储。实验环境依赖《在Docker容器中用loop设备模拟共享存储》搭建。主要步骤包括:1) 扩容虚拟磁盘;2) 刷新loop设备容量;3) 使用PFS工具进行文件系统扩容;4) 更新数据库实例以识别新空间。通过这些步骤,成功将共享存储从20GB扩容至30GB,并确保所有节点都能使用新的存储空间。

背景

继续穷鬼玩PolarDB RAC一写多读集群系列, 上2篇分别介绍了《在Docker容器中用loop设备模拟共享存储》 , 《如何搭建PolarDB容灾(standby)节点》 .

本篇文章介绍一下如何在线扩容共享存储? 实验环境依赖 《在Docker容器中用loop设备模拟共享存储》 , 如果没有环境, 请自行参考以上文章搭建环境.

还需要参考如下文档:

DEMO

b站视频链接

Youtube视频链接

现在虚拟磁盘20GB

-rw-r--r--   1 digoal  staff    20G Dec 18 11:19 VirtualDisk.img

1、宿主机, 扩容虚拟磁盘/data_volumn/VirtualDisk.img , 例如扩容10GB.

cd ~/data_volumn     
dd if=/dev/zero bs=1m count=10240 oflag=direct >> ~/data_volumn/VirtualDisk.img

扩容后变成了30GB

$ ll  ~/data_volumn/VirtualDisk.img  
-rw-r--r--  1 digoal  staff    30G Dec 18 11:30 /Users/digoal/data_volumn/VirtualDisk.img

2、在pb1容器中可以看到虚拟磁盘已经变成了30GB

$ ll -h /data/VirtualDisk.img  
-rw-r--r-- 1 postgres postgres 30G Dec 18 11:30 /data/VirtualDisk.img

3、容器pb1, 扩容loop设备

当前loop1对应的该虚拟磁盘, 显示还是20G

$ losetup -l /dev/loop1  
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE             DIO LOG-SEC  
/dev/loop1         0      0         0  0 /data/VirtualDisk.img   1     512  
  
$ lsblk |grep loop1  
loop1    7:1    0    20G  0 loop

刷新loop1设备容量:

$ sudo losetup -c /dev/loop1

可以看到, loop设备变成30G了

postgres@dad7520e4620:~/primary$ lsblk |grep loop1  
loop1    7:1    0    30G  0 loop

pb2 , pb3 容器都变成了30G, 这个还和macOS docker容器技术有关, 如果你的环境没有变化, 可能需要在PolarDB其他容器内也做相应的刷新操作.

postgres@60d4e0a501f7:~/replica1$ lsblk|grep loop1  
loop1    7:1    0    30G  0 loop

4、文件系统扩容. 使用 PFS 文件系统提供的工具,对块设备上扩大后的物理空间进行格式化,以完成文件系统层面的扩容。

在能够访问共享存储的 任意一台主机上 运行 PFS 的 growfs 命令

$ sudo pfs -C disk growfs -h  
pfs growfs [-o|--oldcknum=n1] [-n|--newcknum=n2] [-f|--force] pbdname  
  -h, --help:             show this help message  
  -o, --oldcknum:         old chunk number(10GB/chunk)  
  -n, --newcknum:         new chunk number  
  -f, --force:            growfs forcedly (default is disabled)

其中:

-o 表示共享存储扩容前的空间(以 10GB 为单位)  
-n 表示共享存储扩容后的空间(以 10GB 为单位)

如果你不知道存储目前有多大, 可以使用dumpfs的结果进行计算:

$ sudo pfs -C disk dumpfs nvme1n1  
pfs tool cmd record:dumpfs nvme1n1   
[PFS_LOG] Dec 18 13:38:14.693399 INF [31813] pfs build version:libpfs_version_("pfsd-build-desc-_-Wed Sep  4 17:22:25 CST 2024")  
[PFS_LOG] Dec 18 13:38:14.693504 INF [31813] pid: 31812, caller: sudo pfs -C disk dumpfs nvme1n1    
[PFS_LOG] Dec 18 13:38:14.693524 INF [31813] pid: 31811, caller: sudo pfs -C disk dumpfs nvme1n1    
[PFS_LOG] Dec 18 13:38:14.693554 INF [31813] pid: 14, caller: bash    
[PFS_LOG] Dec 18 13:38:14.693579 INF [31813] open device cluster disk, devname nvme1n1, flags 0x1  
[PFS_LOG] Dec 18 13:38:14.693588 INF [31813] disk dev path: /dev/nvme1n1  
[PFS_LOG] Dec 18 13:38:14.693603 INF [31813] open local disk: open(/dev/nvme1n1, 0x10000)  
chunk 0:   
    ck_magic   0x504653434a  
    ck_chunksize 10737418240  
    ck_blksize 4194304  
    ck_sectsize 4096  
    ck_number  0  
    ck_nchunk  2  
    ck_checksum 2397668946  
    ck_physet[MT_BLKTAG].ms_nsect 80  
    ck_physet[MT_DIRENTRY].ms_nsect 64  
    ck_physet[MT_INODE].ms_nsect 64  
    ck_physet[MT_BLKTAG].ms_sectbda 0x1000  
    ck_physet[MT_DIRENTRY].ms_sectbda 0x51000  
    ck_physet[MT_INODE].ms_sectbda 0x91000  
chunk 1:   
    ck_magic   0x5046534348  
    ck_chunksize 10737418240  
    ck_blksize 4194304  
    ck_sectsize 4096  
    ck_number  1  
    ck_nchunk  2  
    ck_checksum 86206895  
    ck_physet[MT_BLKTAG].ms_nsect 80  
    ck_physet[MT_DIRENTRY].ms_nsect 64  
    ck_physet[MT_INODE].ms_nsect 64  
    ck_physet[MT_BLKTAG].ms_sectbda 0x280001000  
    ck_physet[MT_DIRENTRY].ms_sectbda 0x280051000  
    ck_physet[MT_INODE].ms_sectbda 0x280091000  
type  free  used  total  
blktag  4861  259 5120  
dentry  4093  3 4096  
inode 4093  3 4096

所有chunk ck_chunksize相加, 或者 ck_blksize 4194304 * blktag total 5120 =

postgres=# select pg_size_pretty(4194304*5120::int8);  
 pg_size_pretty   
----------------  
 20 GB  
(1 row)

本例将共享存储从 20GB 扩容至 30GB:

sudo pfs -C disk growfs -o 2 -n 3 nvme1n1  
  
日志如下:  
  
pfs tool cmd record:growfs -o 2 -n 3 nvme1n1   
[PFS_LOG] Dec 18 13:48:34.705607 INF [31841] pfs build version:libpfs_version_("pfsd-build-desc-_-Wed Sep  4 17:22:25 CST 2024")  
[PFS_LOG] Dec 18 13:48:34.705750 INF [31841] pid: 31840, caller: sudo pfs -C disk growfs -o 2 -n 3 nvme1n1    
[PFS_LOG] Dec 18 13:48:34.705783 INF [31841] pid: 31839, caller: sudo pfs -C disk growfs -o 2 -n 3 nvme1n1    
[PFS_LOG] Dec 18 13:48:34.705799 INF [31841] pid: 14, caller: bash    
Init chunk 2  
    metaset        2/1: sectbda      0x500001000, npage       80, objsize  128, nobj 2560, oid range [    2000,     2a00)  
    metaset        2/2: sectbda      0x500051000, npage       64, objsize  128, nobj 2048, oid range [    1000,     1800)  
    metaset        2/3: sectbda      0x500091000, npage       64, objsize  128, nobj 2048, oid range [    1000,     1800)  
  
pfs growfs succeeds!

查看pfs nvme1n1元数据, 可以看到pfs已扩容成功

$ sudo pfs -C disk dumpfs nvme1n1  
pfs tool cmd record:dumpfs nvme1n1   
[PFS_LOG] Dec 18 13:55:57.320348 INF [31867] pfs build version:libpfs_version_("pfsd-build-desc-_-Wed Sep  4 17:22:25 CST 2024")  
[PFS_LOG] Dec 18 13:55:57.320437 INF [31867] pid: 31866, caller: sudo pfs -C disk dumpfs nvme1n1    
[PFS_LOG] Dec 18 13:55:57.320459 INF [31867] pid: 31865, caller: sudo pfs -C disk dumpfs nvme1n1    
[PFS_LOG] Dec 18 13:55:57.320472 INF [31867] pid: 14, caller: bash    
[PFS_LOG] Dec 18 13:55:57.320503 INF [31867] open device cluster disk, devname nvme1n1, flags 0x1  
[PFS_LOG] Dec 18 13:55:57.320516 INF [31867] disk dev path: /dev/nvme1n1  
[PFS_LOG] Dec 18 13:55:57.320520 INF [31867] open local disk: open(/dev/nvme1n1, 0x10000)  
chunk 0:   
    ck_magic   0x504653434a  
    ck_chunksize 10737418240  
    ck_blksize 4194304  
    ck_sectsize 4096  
    ck_number  0  
    ck_nchunk  3  
    ck_checksum 2262034622  
    ck_physet[MT_BLKTAG].ms_nsect 80  
    ck_physet[MT_DIRENTRY].ms_nsect 64  
    ck_physet[MT_INODE].ms_nsect 64  
    ck_physet[MT_BLKTAG].ms_sectbda 0x1000  
    ck_physet[MT_DIRENTRY].ms_sectbda 0x51000  
    ck_physet[MT_INODE].ms_sectbda 0x91000  
chunk 1:   
    ck_magic   0x5046534348  
    ck_chunksize 10737418240  
    ck_blksize 4194304  
    ck_sectsize 4096  
    ck_number  1  
    ck_nchunk  3  
    ck_checksum 219744067  
    ck_physet[MT_BLKTAG].ms_nsect 80  
    ck_physet[MT_DIRENTRY].ms_nsect 64  
    ck_physet[MT_INODE].ms_nsect 64  
    ck_physet[MT_BLKTAG].ms_sectbda 0x280001000  
    ck_physet[MT_DIRENTRY].ms_sectbda 0x280051000  
    ck_physet[MT_INODE].ms_sectbda 0x280091000  
chunk 2:   
    ck_magic   0x5046534348  
    ck_chunksize 10737418240  
    ck_blksize 4194304  
    ck_sectsize 4096  
    ck_number  2  
    ck_nchunk  3  
    ck_checksum 3123774169  
    ck_physet[MT_BLKTAG].ms_nsect 80  
    ck_physet[MT_DIRENTRY].ms_nsect 64  
    ck_physet[MT_INODE].ms_nsect 64  
    ck_physet[MT_BLKTAG].ms_sectbda 0x500001000  
    ck_physet[MT_DIRENTRY].ms_sectbda 0x500051000  
    ck_physet[MT_INODE].ms_sectbda 0x500091000  
type  free  used  total  
blktag  7420  260 7680  
dentry  6141  3 6144  
inode 6141  3 6144

5、数据库实例层扩容, 所有PolarDB 计算节点共享存储的pfsd守护进程都需要刷新一下, 才能知道新空间已经可以被使用了.

在pb1 primary 节点创建polar_vfs插件:

CREATE EXTENSION IF NOT EXISTS polar_vfs;

在所有replica节点执行以下函数, 函数的参数名为块设备名, 最后在pb1 primary节点执行, 注意先后顺序.

SELECT polar_vfs_disk_expansion('nvme1n1');  
  
返回如下:  
 polar_vfs_disk_expansion   
--------------------------  
 t  
(1 row)

执行完毕后,数据库实例层面的扩容也就完成了。此时,新的存储空间已经能够被数据库使用了。

参考

《穷鬼玩PolarDB RAC一写多读集群系列 | 在Docker容器中用loop设备模拟共享存储》

《穷鬼玩PolarDB RAC一写多读集群系列 | 如何搭建PolarDB容灾(standby)节点》

https://apsaradb.github.io/PolarDB-for-PostgreSQL/zh/operation/grow-storage.html#%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AE%9E%E4%BE%8B%E5%B1%82%E6%89%A9%E5%AE%B9

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
7月前
|
SQL 关系型数据库 MySQL
开源新发布|PolarDB-X v2.4.2开源生态适配升级
PolarDB-X v2.4.2开源发布,重点完善生态能力:新增客户端驱动、开源polardbx-proxy组件,支持读写分离与高可用;强化DDL变更、扩缩容等运维能力,并兼容MySQL主备复制及MCP AI生态。
开源新发布|PolarDB-X v2.4.2开源生态适配升级
|
10月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
7月前
|
SQL 关系型数据库 MySQL
开源新发布|PolarDB-X v2.4.2开源生态适配升级
PolarDB-X v2.4.2发布,新增开源Proxy组件与客户端驱动,支持读写分离、无感高可用切换及DDL在线变更,兼容MySQL生态,提升千亿级大表运维稳定性。
1822 24
开源新发布|PolarDB-X v2.4.2开源生态适配升级
|
9月前
|
人工智能 关系型数据库 MySQL
开源PolarDB-X:单节点误删除binlog恢复
本文由邵亚鹏撰写,分享了在使用开源PolarDB-X过程中,因误删binlog导致数据库服务无法启动的问题及恢复过程。作者结合实践经验,详细介绍了在无备份情况下如何通过单节点恢复机制重启数据库,并提出了避免类似问题的几点建议,包括采用高可用部署、定期备份及升级至最新版本等。
|
11月前
|
存储 关系型数据库 数据库
高性能云盘:一文解析RDS数据库存储架构升级
性能、成本、弹性,是客户实际使用数据库过程中关注的三个重要方面。RDS业界率先推出的高性能云盘(原通用云盘),是PaaS层和IaaS层的深度融合的技术最佳实践,通过使用不同的存储介质,为客户提供同时满足低成本、低延迟、高持久性的体验。
|
12月前
|
存储 Cloud Native 关系型数据库
PolarDB开源:云原生数据库的架构革命
本文围绕开源核心价值、社区运营实践和技术演进路线展开。首先解读存算分离架构的三大突破,包括基于RDMA的分布式存储、计算节点扩展及存储池扩容机制,并强调与MySQL的高兼容性。其次分享阿里巴巴开源治理模式,涵盖技术决策、版本发布和贡献者成长体系,同时展示企业应用案例。最后展望技术路线图,如3.0版本的多写多读架构、智能调优引擎等特性,以及开发者生态建设举措,推荐使用PolarDB-Operator实现高效部署。
523 4
|
存储 关系型数据库 MySQL
开源PolarDB- X|替换Opengemini时序数据场景下产品力校验
本文作者:黄周霖,数据库技术专家,就职于南京北路智控股份有限公司,负责数据库运维及大数据开发。
|
8月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
516 158
|
8月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
8月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
1324 152

相关产品

  • 云原生数据库 PolarDB