When dealing with poorly optimized databases like the MySQL instance described, storage management becomes critical. The scenario presents a classic case where automatic growth patterns collide with finite storage resources. The immediate solution requires expanding the underlying storage infrastructure while ensuring the LVM configuration properly utilizes all available space.

The existing setup consists of:

• Original configuration: 2 disks in RAID 10
• Current configuration: 4 disks (additional 2 disks added)
• LVM implementation managing the storage

The key to solving this lies in properly using pvresize without size constraints:

# First verify the current PV size
pvdisplay /dev/mapper/raid_device

# Then resize to use all available space
pvresize /dev/mapper/raid_device

# Confirm the new size
pvdisplay /dev/mapper/raid_device

For a comprehensive solution, follow this sequence:

1. Extend the RAID array (already completed)
2. Resize the physical volume
3. Extend the volume group (if needed):

vgextend vg_name /dev/mapper/raid_device

lvextend -l +100%FREE /dev/vg_name/lv_name

# For ext4:
resize2fs /dev/vg_name/lv_name

# For xfs:
xfs_growfs /mount_point

To prevent future issues, implement monitoring with this sample script:

#!/bin/bash
THRESHOLD=90
CURRENT=$(df -h /mysql_mount | awk '{print $5}' | tail -1 | cut -d'%' -f1)

if [ "$CURRENT" -gt "$THRESHOLD" ]; then
    echo "Warning: MySQL storage reaching capacity" | mail -s "Storage Alert" admin@example.com
fi

Consider these my.cnf tweaks to control growth:

[mysqld]
innodb_autoextend_increment=64  # Default 8, controls growth increments
innodb_data_file_path=ibdata1:10G:autoextend:max:50G  # Set maximum size

When dealing with MySQL servers that aggressively consume storage, particularly in vendor-configured environments, administrators often face the need to expand underlying storage without downtime. The scenario described involves:

• Original 2-disk RAID 10 configuration
• New 2-disk addition to the array
• LVM-based storage needing expansion

The standard pvresize command expects explicit size parameters:

# Typical usage with explicit size
pvresize --setphysicalvolumesize 20G /dev/mapper/vg_data

This becomes problematic when you want to utilize all available space rather than calculating exact figures.

To expand to maximum available space, simply omit the size parameter:

# Expand to maximum available space
pvresize /dev/mapper/vg_data

This automatically detects and utilizes all available space in the underlying physical device.

Here's the full procedure from RAID expansion to filesystem growth:

# 1. Verify the new disk capacity
lsblk
cat /proc/mdstat

# 2. Rescan the block devices (if needed)
echo 1 > /sys/block/md0/device/rescan

# 3. Expand the physical volume
pvresize /dev/mapper/vg_data

# 4. Verify the new PV size
pvs

# 5. Extend the logical volume (assuming 100%FREE)
lvextend -l +100%FREE /dev/mapper/vg_data-lv_mysql

# 6. Resize the filesystem (ext4 example)
resize2fs /dev/mapper/vg_data-lv_mysql

# 7. Verify MySQL can see the new space
mysql -e "SHOW VARIABLES LIKE 'innodb_data_file_path';"

For production environments, consider these enhancements:

# Safety check before resizing
pvdisplay /dev/mapper/vg_data
vgdisplay vg_data

# Alternative for XFS filesystems
xfs_growfs /mount/point

# Monitoring growth pattern
watch -n 60 "df -h /var/lib/mysql; pvs; vgs; lvs"

For MySQL instances that aggressively fill available space, implement monitoring:

#!/bin/bash
THRESHOLD=90
CURRENT=$(df /var/lib/mysql | awk '{print $5}' | tail -1 | sed 's/%//')

if [ "$CURRENT" -ge "$THRESHOLD" ]; then
    logger "MySQL storage threshold breached - expanding LVM"
    lvextend -L+5G /dev/mapper/vg_data-lv_mysql
    resize2fs /dev/mapper/vg_data-lv_mysql
fi