트래픽이 많은 데이터베이스 서버에 매우 가득 찬 하드 드라이브를 설치하는 것이 좋지 않습니까?

트래픽이 많은 프로덕션 데이터베이스 서버를 위해 MySQL과 함께 Ubuntu 서버를 실행합니다. MySQL 인스턴스 이외의 다른 머신에서는 아무것도 실행되지 않습니다.

매일 데이터베이스 백업을 DB 서버에 저장하는데, 성능 저 하나 하드 디스크를 상대적으로 비워 두어야하는 이유가 있습니까? 디스크가 데이터베이스와 모든 백업으로 최대 86 % 이상 채워져 있으면 성능이 전혀 저하되지 않습니까?

따라서 전체 용량이 86-90 % 이상인 DB 서버는 10 % 전체 디스크로 실행되는 서버보다 성능이 떨어질까요?

서버의 총 디스크 크기는 1TB를 초과하므로 디스크의 10 % 만 기본 O / S 스와핑에 충분해야합니다.

우선 데이터베이스 백업을 데이터베이스와 동일한 실제 드라이브 또는 RAID 그룹에 보관하지 마십시오. 그 이유는 디스크 장애 (RAID 보호없이 실행중인 경우) 또는 치명적인 RAID 장애 (RAID-1 또는 RAID-5를 사용하는 경우)로 인해 데이터베이스 및 데이터베이스 백업이 유실 될 수 있기 때문입니다.

디스크 성능에 대한 질문은 디스크 드라이브의 용량이 디스크의 데이터에 액세스하는 방법에 따라 다릅니다. 디스크 회전의 경우 I / O 성능에 영향을주는 두 가지 물리적 요소가 있습니다. 그들은:

• 탐색 시간-디스크 드라이브가 디스크 헤드를 현재 트랙 위치에서 요청 된 데이터가 포함 된 트랙으로 이동하는 데 걸리는 시간입니다.

• 회전 대기 시간-드라이브가 회전함에 따라 원하는 데이터가 읽기 헤드에 도달하는 데 걸리는 평균 시간-15K RPM 드라이브의 경우 2ms (밀리 초)

드라이브가 가득 차면 서버 I / O의 평균 검색 시간에 영향을 줄 수 있습니다. 예를 들어, 드라이브가 가득 차서 디스크 플래터의 가장 반대쪽 끝에있는 드라이브에 실제로 데이터베이스 테이블이있는 경우, 각 테이블에서 데이터에 액세스하는 I / O를 수행 할 때 해당 I / O가 경험합니다. 드라이브의 최대 탐색 시간.

그러나 드라이브가 가득 차서 응용 프로그램이 드라이브에 저장된 데이터의 작은 부분에만 액세스하고이 모든 데이터가 드라이브에 연속적으로 위치하면 이러한 I / O는 탐색 시간에 의해 최소한의 영향을받습니다. .

불행히도이 질문에 대한 답은 "마일리지가 다를 것"입니다. 즉, 응용 프로그램이 데이터에 액세스하는 방법과 해당 데이터의 위치에 따라 I / O 성능이 결정됩니다.

또한 @gravyface에서 언급했듯이 운영 체제 스토리지 요구 사항을 데이터베이스와 분리하는 것이 "모범 사례"입니다. 다시 말하지만, 운영 체제와 데이터베이스 소프트웨어가 모두 I / O 요청을 수행 할 때 동일한 드라이브에 둘 다 있으면 드라이브의 운영 체제와 데이터베이스 영역 사이를 계속 탐색 할 수 있으므로 디스크 표면에서 헤드 이동을 최소화하는 데 도움이됩니다.

여기서 고려해야 할 각도는 성능과 견고성입니다.

성능 측면에서 일반적으로 다음과 같은 경우 별도의 디스크 스핀들 (또는 RAID 그룹 / 드라이브 세트)을 사용하는 것이 좋습니다.

1. OS 항목 (바이너리, 로그, 홈 디렉토리 등)
2. 스왑 공간 (스왑을 사용하지 않을 경우 (1)과 결합 될 수 있음)
3. 생산 DB
4. 프로덕션 DB의 트랜잭션 로그 (사용 된 경우)
5. 데이터베이스 덤프 / 백업

그 이유는 매우 간단합니다. 디스크를 요구하는 "다른 것들"에 의해 DB 성능에 영향을 미치지 않기를 원합니다 (예 : 머신이 많이 스왑을 시작하고 스왑 파티션이 DB 데이터에서 디스크의 다른쪽에있는 경우) 긴 디스크를 사용하려고합니다).

견고성 관점에서 보면 동일한 종류의 분류가 필요하지만 다른 이유가 있습니다. 다른 사람들이 지적했듯이 고장난 디스크가 DB와 백업을 모두 꺼내지 않기를 원합니다 (실제로는 백업을 복사해야합니다) 치명적인 오류가 발생한 경우 서버).

또한 /모든 것을 포함 하는 모 놀리 식 파티션의 구성을 피하고 싶습니다. 이것은 다른 유닉스 계열 시스템과 공유하지 않는 Linux 세계에서 발생 하는 불행하고 비극적이며 놀라 울 정도로 흔한 실수입니다.
Gravyface가 그의 의견에서 언급했듯이, 어떻게 든 /시스템 을 채울 수 있다면 거의 확실하게 충돌이 발생하며 시스템 /에 체계적으로 구성된 마운트 포인트 계층 구조가 아닌 단일 파티션 이 있으면 정리 / 복구에 많은 시간과 비용이 소요될 수 있습니다 .

데이터베이스 및 임시 (아래 참조) 백업을 루트 (/)가 아닌 다른 파티션으로 옮기는 것이 좋습니다.

또한 (가정 된) 압축 된 데이터베이스 덤프 백업에 대한 적절한 회전 / 보존 체계를 생각해보십시오. 많은 수의 백업 사본을 로컬 디스크에 보관할 이유가 없습니다. 재해 복구를 위해 아무 작업도 수행하지 않으며 오프 사이트로 이동할 때는 디스크에서 제거해야합니다.

그것은 거의 표준 운영 절차입니다.

이것은 거의 가득 찬 파일 시스템의 성능이 절반으로 줄어드는 NetApp의 버그를 상기 시켰습니다. (몇 년 전이었던 것 같습니다).

모두가 말한 대답은 달려 있지만 그것을 생각할 가치가 있습니다.

전체 파일 시스템의 주요 단점은 사용 가능한 inode 목록이 여러 곳에서 조각화 될 가능성이 있다는 것입니다.

데이터베이스의 하드 디스크에는 세 가지 유형의 데이터가 있습니다.

1. 실제 데이터베이스 파일 이 파일은 일반적으로 큰 덩어리 (예 : 10 %)로 커지는 사전 할당 된 큰 파일입니다.
2. 로그, 지속적으로 기록, 삭제, 기록되는 트랜잭션 로그 등
3. 메모리에서 실행할 수없는 큰 쿼리의 임시 파일

(1) 파일 세트에 더 많은 공간을 할당 할 때 여유 공간 만 필요합니다. 데이터베이스가 커지지 않으면 디스크 공간 부족 파일 시스템의 영향을받지 않아야합니다. 그러나 할당하는 경우 즉시 데이터베이스를 조각화하고 데이터를 메모리에 준비해야 할 때 탐색을 유발하는 사용 가능한 목록에 맞지 않는 매우 큰 청크를 요청할 수 있습니다.

(2) OS를 사용하여 공간을 할당하고 삭제하면 로그가 순진하게 영향을받습니다. 데이터베이스가 읽기 전용이 아니라고 가정하면 일정한 로그 스트림이 있으며 하드 디스크 공간이 부족한 경우 종종 조각화됩니다. 궁극적으로 이것은 쓰기 성능을 저하시킵니다.

(3) tempDB, DB가 거친 쓰기 쿼리에 필요하거나 RAM이 충분하지 않으면 읽기 성능조차도 디스크에 바인딩 될 수 있으므로 디스크 공간 부족보다 성능 문제를 일으키는 큰 문제가 있습니다. MySql이 tempDB에 디스크 공간을 할당해야하고 하드 디스크가 부족한 경우에도 중단 위험이 있습니다.

백업 정보 ...

1. 내가 일한 모든 기업은 동일한 머신에 백업을 유지합니다. 복원 (백업에 관심이있는 사람)은 복원이 중요합니다. 같은 디스크에 db 파일이있는 속도를 능가하는 것은 없습니다.
2. 백업이 로컬이 아닌지 확인하십시오.

간단히 말해서 DB가 무겁지 않다고해도 살아남을 것이라고 말할 수 있습니다. 그렇다면 디스크 공간 부족이 문제입니다. 그러나 내가 당신이라면 나는 나중에보다 빨리 다음 작업을 할 것입니다.

1. 충분한 RAM이 있는지 확인
2. DB에서 로그 및 모든 임시 데이터를 분리합니다.
3. OS와 MySql 설치를 나머지에서 분리합니다.

가능한 경우 별도의 스핀들과 컨트롤러를 사용하십시오.

별도의 스핀들이 뒤 따름

가난한 사람의 별도 파티션이 이어졌습니다.

최근에 복제 서버 중 하나의 모든 디스크 공간을 모두 사용했을 때 비슷한 문제가있었습니다. 즉각적인 효과는 복제가 중단 된 후 mysqld.sock 파일을 열 수 없기 때문에 MySQL에 로그인 할 수 없었습니다.