开始的现象是 MySQL 服务重启失败
深入排查错误日志，发现之前出现过磁盘空间不足的日志记录
[ERROR] [MY-000035] [Server] Disk is full writing './binlog.056637' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.因为我是采用 Helm 在 AKS 内部署的 MySQL 服务，并且挂载的磁盘是 Azure 内置存储类动态创建 Azure 磁盘 PV （支持实施动态扩容）
于是，只需手动将挂载到mysql pod 的 pvc 的 resources.request.storage 属性值调大，再重启 mysql pod 就完成了本次故障修复
下面简短的帮大家科普下azure disk 如何支持 kubernetes storage class 动态创建持久化卷（persistent volume）
存储类（storage class）用于定义使用持久性卷（persistent volume）动态创建存储单位的方式。
在 AKS 上使用 Azure 磁盘 CSI 驱动程序时，还有两个使用 Azure 磁盘 CSI 存储驱动程序的内置 StorageClasses。 其他这些 CSI 存储类是使用群集连同树中默认的存储类一起创建的。
managed-csi：使用 Azure Standard SSD 本地冗余存储 (LRS) 创建托管磁盘。 从 Kubernetes 版本 1.29 开始，在跨多个可用性区域部署的 Azure Kubernetes 服务 (AKS) 群集中，此存储类利用 Azure 标准 SSD 区域冗余存储 (ZRS) 来创建托管磁盘。managed-csi-premium：使用 Azure 高级 LRS 创建托管磁盘。 从 Kubernetes 版本 1.29 开始，在跨多个可用性区域部署的 Azure Kubernetes 服务 (AKS) 群集中，此存储类利用 Azure 高级区域冗余存储 (ZRS) 来创建托管磁盘。
这两个存储类中的回收策略可确保在删除相应 PV 时删除基础 Azure 磁盘。 存储类还会将 PV 配置为可扩展。 只需使用新大小编辑永久性卷声明 (PVC) 即可。
如需了解当前pod挂载的pvc是否支持动态扩容，只需向上查看这个 pvc 的 yaml 文件中引用的 storage class 是否具备 allowVolumeExpansion: true 这个属性
example-sc.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumerexample-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: custom-azure-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: azuredisk-csi-waitforfirstconsumer
resources:
requests:
storage: 5Gi这样挂载了 custom-azure-disk pvc 的pod如果想扩容磁盘时，只需手动修改 example-pvc.yaml 文件中的 resources.request.storage 属性的值即可（例如讲 5Gi 改成 10 Gi）
