Có phải là xấu khi có một ổ cứng rất đầy đủ trên một máy chủ cơ sở dữ liệu lưu lượng truy cập cao?

Chạy một máy chủ Ubuntu với MySQL cho một máy chủ cơ sở dữ liệu sản xuất lưu lượng truy cập cao. Không có gì khác đang chạy trên máy ngoại trừ phiên bản MySQL.

Chúng tôi lưu trữ các bản sao lưu cơ sở dữ liệu hàng ngày trên máy chủ DB, có bất kỳ hiệu năng nào xảy ra hay lý do tại sao chúng ta nên giữ đĩa cứng tương đối trống không? Nếu đĩa được lấp đầy tới 86% + với cơ sở dữ liệu và tất cả các bản sao lưu, liệu nó có ảnh hưởng đến hiệu suất không?

Vì vậy, máy chủ DB chạy với 86-90% + dung lượng đầy đủ có thể hoạt động kém hơn bất kỳ cách nào so với máy chủ chỉ chạy với đĩa đầy 10%?

Tổng kích thước đĩa trên máy chủ là hơn 1 TB, do đó, thậm chí 10% đĩa phải đủ để hoán đổi O / S cơ bản và như vậy.

Trước hết, bạn KHÔNG muốn giữ các bản sao lưu cơ sở dữ liệu của mình trên cùng một ổ đĩa vật lý hoặc nhóm RAID như cơ sở dữ liệu của bạn. Lý do cho điều này là do lỗi đĩa (nếu bạn đang chạy mà không có bảo vệ RAID) hoặc lỗi RAID nghiêm trọng (nếu bạn đang sử dụng RAID-1 hoặc RAID-5) sẽ khiến bạn mất cơ sở dữ liệu và sao lưu cơ sở dữ liệu.

Câu hỏi của bạn về hiệu suất đĩa liên quan đến mức độ đầy đủ của ổ đĩa phụ thuộc vào cách dữ liệu trên đĩa được truy cập. Đối với đĩa quay có hai yếu tố vật lý ảnh hưởng đến hiệu suất I / O. Họ đang:

• tìm kiếm thời gian - đó là thời gian để ổ đĩa di chuyển đầu đĩa từ vị trí theo dõi hiện tại của nó sang rãnh chứa dữ liệu được yêu cầu

• độ trễ quay - là thời gian trung bình để dữ liệu mong muốn đến đầu đọc khi ổ đĩa quay - đối với ổ 15K RPM, thời gian này là 2 ms (mili giây)

Ổ đĩa của bạn đầy đủ có thể ảnh hưởng đến thời gian tìm kiếm trung bình mà I / O của máy chủ của bạn đang trải qua. Ví dụ: nếu ổ đĩa của bạn đã đầy và bạn có các bảng cơ sở dữ liệu được đặt trên ổ đĩa ở đầu cực đối diện của đĩa, thì khi bạn thực hiện truy cập I / O dữ liệu từ mỗi bảng này, tôi sẽ trải nghiệm dữ liệu từ mỗi bảng này. thời gian tìm kiếm tối đa của ổ đĩa.

Tuy nhiên, điều đó đang được nói, nếu ổ đĩa của bạn đã đầy và ứng dụng của bạn chỉ truy cập một phần nhỏ dữ liệu được lưu trữ trên ổ đĩa và tất cả các dữ liệu này được đặt liền kề trên ổ đĩa, thì các I / O này sẽ bị ảnh hưởng tối thiểu theo thời gian tìm kiếm .

Thật không may, câu trả lời cho câu hỏi này là "số dặm của bạn sẽ thay đổi", nghĩa là cách ứng dụng của bạn truy cập dữ liệu và vị trí của dữ liệu đó sẽ xác định hiệu suất I / O của bạn sẽ là bao nhiêu.

Ngoài ra, như được đề cập bởi @gravyface, sẽ là "cách tốt nhất" để tách các yêu cầu lưu trữ hệ điều hành của bạn khỏi cơ sở dữ liệu của bạn. Một lần nữa, điều này sẽ giúp giảm thiểu chuyển động đầu trên bề mặt đĩa vì có cả hai trên cùng một ổ đĩa có thể gây ra tìm kiếm liên tục giữa hệ thống hoạt động và khu vực cơ sở dữ liệu của ổ đĩa vì cả hệ điều hành và phần mềm cơ sở dữ liệu đều thực hiện các yêu cầu I / O.

Có hai góc độ để xem xét ở đây: Hiệu suất và Mạnh mẽ.

Về hiệu năng, thông thường nên có các trục đĩa riêng biệt (hoặc nhóm RAID / bộ ổ đĩa) cho:

1. Các công cụ hệ điều hành (nhị phân, nhật ký, thư mục nhà, v.v.)
2. Hoán đổi không gian (có thể được kết hợp với (1) nếu bạn không muốn sử dụng trao đổi)
3. DB sản xuất
4. Nhật ký giao dịch của DB sản xuất (nếu được sử dụng)
5. Cơ sở dữ liệu / bản sao lưu

Lý do đằng sau điều này khá đơn giản: Bạn không muốn hiệu suất DB bị ảnh hưởng bởi "những thứ khác" yêu cầu đĩa (ví dụ: nếu máy bắt đầu hoán đổi nhiều và phân vùng trao đổi nằm ở phía bên kia của đĩa từ dữ liệu DB bạn có đĩa dài tìm cách tranh luận với).

Từ quan điểm mạnh mẽ, bạn muốn cùng một loại sự cố, nhưng vì một lý do khác: Như những người khác đã chỉ ra rằng bạn không muốn một đĩa thất bại lấy ra cả DB và các bản sao lưu của nó (mặc dù thực tế bạn nên sao chép các bản sao lưu máy chủ dù sao trong trường hợp thất bại thảm hại).

Bạn cũng muốn tránh mọi cấu hình với /phân vùng nguyên khối chứa mọi thứ - đây là một lỗi phổ biến đáng tiếc, bi thảm và đáng báo động trong thế giới Linux không được chia sẻ bởi các hệ thống giống Unix khác.
Như Gravyface đã đề cập trong bình luận của mình, nếu bạn bằng cách nào đó lấp đầy /hệ thống của mình thì gần như chắc chắn sẽ gặp sự cố, và việc dọn dẹp / khôi phục có thể tốn thời gian và tốn kém nếu hệ thống có một /phân vùng duy nhất thay vì cấu trúc phân cấp các điểm gắn kết.

Tôi khuyên bạn nên di chuyển cơ sở dữ liệu và sao lưu tạm thời (xem bên dưới) sang một phân vùng khác với root (/).

Ngoài ra, hãy đưa ra một sơ đồ xoay / duy trì hợp lý cho các bản sao lưu kết xuất cơ sở dữ liệu nén (giả định) của bạn. Không có lý do gì để giữ nhiều bản sao lưu trên đĩa cục bộ. Không có gì để khắc phục thảm họa và khi di chuyển ra khỏi trang web, nên được gỡ bỏ khỏi đĩa.

Đó là quy trình vận hành khá chuẩn.

Điều này khiến tôi nhớ về một lỗi trên NetApp khi các hệ thống tệp gần đầy đã giảm hiệu suất của chúng (như một nửa). (phải thừa nhận rằng đó là một vài năm trước).

Câu trả lời như mọi người nói là tùy, nhưng nó đáng để suy nghĩ kỹ.

Nhược điểm chính của hệ thống tập tin đầy đủ là danh sách các nút miễn phí có khả năng bị phân mảnh và ở khắp mọi nơi.

Có ba loại dữ liệu nằm trên đĩa cứng cho cơ sở dữ liệu.

1. Tập tin cơ sở dữ liệu thực tế của bạn. Đây sẽ là một tập tin preallocated lớn thường phát triển thành khối lớn (ví dụ 10%).
2. Nhật ký, nhật ký giao dịch của bạn liên tục được ghi vào, xóa, ghi vào, v.v ...
3. Các tệp tạm thời cho các truy vấn lớn không thể chạy trong bộ nhớ.

(1) chỉ cần không gian trống khi phân bổ thêm dung lượng cho tập tin của bạn. Nếu cơ sở dữ liệu của bạn không phát triển, nó sẽ không bị ảnh hưởng bởi hệ thống tệp không gian đĩa thấp. Nếu nó được phân bổ, nó có thể yêu cầu một khối rất lớn không phù hợp với bất kỳ danh sách miễn phí nào mà bạn đã phân đoạn ngay cơ sở dữ liệu của mình và gây ra việc tìm kiếm khi nó cần dữ liệu để sẵn sàng vào bộ nhớ.

(2) một bản ghi ngây thơ của các bản ghi trong đó nó sử dụng HĐH để quản lý phân bổ không gian và xóa nó sẽ bị ảnh hưởng. Giả sử cơ sở dữ liệu của bạn không chỉ đọc, sẽ có một dòng nhật ký liên tục, chúng sẽ thường xuyên bị phân mảnh trên một không gian đĩa cứng thấp. Cuối cùng, điều này sẽ làm tổn thương hiệu suất viết của bạn.

(3) tempDB, nếu DB cần nó cho các truy vấn bằng văn bản kém chất lượng hoặc không đủ RAM, thì bạn đã gặp vấn đề lớn hơn không gian đĩa thấp gây ra vấn đề về hiệu suất vì ngay cả hiệu suất đọc của bạn cũng có thể bị ràng buộc. Bạn cũng có nguy cơ bị cúp nếu MySql cần phân bổ dung lượng đĩa cho tempDB và đĩa cứng đã hết.

Về sao lưu ...

1. Mỗi doanh nghiệp tôi đã làm việc giữ các bản sao lưu trên cùng một máy. Khi nói đến khôi phục (ai quan tâm đến các bản sao lưu, thì đó là phần khôi phục được tính). Không có gì có thể đánh bại tốc độ có tệp db ngay trên cùng một đĩa.
2. Hy vọng rõ ràng, đảm bảo các bản sao lưu không chỉ là cục bộ.

Nói tóm lại, tôi sẽ nói rằng bạn sẽ sống sót khi cung cấp DB của bạn không bị nặng nề. Nếu có, thì dung lượng đĩa thấp là một vấn đề. Nhưng nếu tôi là bạn, tôi sẽ làm việc sau đây sớm hơn là sau này.

1. Khẳng định tôi có đủ RAM
2. Phân tách nhật ký và tất cả dữ liệu thoáng qua từ DB của bạn.
3. Cách ly hệ điều hành của bạn, MySql của bạn sẽ cài đặt từ phần còn lại.

Sử dụng các trục và bộ điều khiển riêng nếu bạn có thể cho 1.

Tiếp theo là các trục chính riêng biệt

Tiếp theo là các phân vùng riêng biệt của một người nghèo.

Gần đây tôi đã gặp một vấn đề tương tự khi tôi sử dụng hết dung lượng đĩa trên một trong các máy chủ sao chép của mình. Hiệu quả ngay lập tức là sao chép bị sập và sau đó tôi không thể đăng nhập vào MySQL vì tệp mysqld.sock không thể mở được.