AWS를 프로덕션 서버로 사용하고 있습니다. 어제 내 mongodb 실행이 중지되었고 로깅할 공간이 충분하지 않다는 메시지가 표시되었습니다. 공간을 더 추가하기 위해 AWS 콘솔에서 볼륨을 편집하고 볼륨 크기를 16Gib로 늘렸습니다. Linux 명령줄에서 lsblk의 결과는 다음과 같습니다.
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /
parted의 인쇄 명령은 다음 결과를 보여줍니다.
print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
128 1049kB 2097kB 1049kB BIOS Boot Partition bios_grub
1 2097kB 8590MB 8588MB ext4 Linux
2 8590MB 17.2GB 8590MB Linux
df-h는 다음 결과를 표시합니다.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.8G 4.3G 3.5G 56% /
devtmpfs 488M 56K 488M 1% /dev
tmpfs 498M 0 498M 0% /dev/shm
서버에서 아무것도 잃지 않고 /dev/xvda1에 8GB의 추가 공간을 추가해야 합니다. 저는 Linux 서버를 처음 접했습니다. 도움이나 조언을 주시면 감사하겠습니다.
EDIT1 - Google 이후에도 resize2fs를 시도했지만 다음 출력이 표시됩니다.
resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 2096635 (4k) blocks long. Nothing to do!
답변1
먼저, 이러한 작업을 시도하기 전에 전체 백업을 수행해야 합니다.
파티션 테이블에서 두 번째 파티션을 제거해야 합니다(예: gdisk
각 ext2/3/4를 사용하면 사이트에 좋은 답변이 있는 몇 가지 질문이 있습니다.parted
xfs_growfs
resize2fs
파일 시스템 성장- 이 주제를 시도하기 전에 광범위하게 조사해 보는 것이 좋습니다. 어렵지는 않지만 작은 실수라도 치명적인 데이터 손실로 이어질 수 있습니다.
또 다른 옵션은 16G 이상의 디스크(또는 더 작은 1~4GB /dev/xvda boot/OS 디스크 및 데이터베이스용으로 두 번째로 큰 /dev/xvdb 디스크)를 사용하여 새 VM을 생성하는 것입니다. 저장 공간을 다시 늘려야 합니다.) 두 번째 가상 머신을 원래 가상 머신과 동일하게 만든 다음, 원래 가상 머신의 데이터를 새 가상 머신에 복사합니다.
rsync
아마도 복제에 가장 적합할 것입니다. 원본 VM이 여전히 실행 중이고 대량의 데이터에 대한 요청을 처리하는 동안 데이터를 재동기화한 다음 해당 데이터베이스 서비스를 종료하고 다시 재동기화하여 처음 이후 추가/변경된 모든 데이터를 전송할 수 있습니다. rsync가 시작되었습니다. 그런 다음 원래 가상 머신을 종료하고 원래 가상 머신과 동일한 IP 주소를 사용하여 새 가상 머신을 다시 시작합니다. 이렇게 하면 가동 중지 시간이 최소화됩니다.