Các nhà sản xuất máy chủ và nhà cung cấp đám mây cung cấp các loại giải pháp lưu trữ khác nhau để đáp ứng nhu cầu cơ sở dữ liệu của bạn. Khi mua một máy chủ mới hoặc chọn một phiên bản đám mây để chạy cơ sở dữ liệu của mình, chúng ta thường tự hỏi mình - chúng ta nên phân bổ bao nhiêu dung lượng đĩa? Như chúng ta sẽ tìm hiểu, câu trả lời không hề nhỏ vì có một số khía cạnh cần xem xét. Dung lượng đĩa là thứ cần phải được suy nghĩ trước vì việc thu hẹp và mở rộng dung lượng đĩa có thể là một hoạt động rủi ro đối với cơ sở dữ liệu dựa trên đĩa.
Trong bài đăng trên blog này, chúng ta sẽ xem xét cách kích thước ban đầu cho không gian lưu trữ của bạn, sau đó lập kế hoạch về dung lượng để hỗ trợ sự phát triển của cơ sở dữ liệu MySQL hoặc MariaDB của bạn.
Cách MySQL sử dụng dung lượng đĩa
MySQL lưu trữ dữ liệu trong các tệp trên đĩa cứng trong một thư mục cụ thể có biến hệ thống "datadir". Nội dung của datadir sẽ phụ thuộc vào phiên bản máy chủ MySQL và các tham số cấu hình đã tải và các biến máy chủ (ví dụ:general_log, slow_query_log, binary log).
Thông tin lưu trữ và truy xuất thực tế phụ thuộc vào các công cụ lưu trữ. Đối với công cụ MyISAM, chỉ mục của bảng được lưu trữ trong tệp .MYI, trong thư mục dữ liệu, cùng với tệp .MYD và .frm cho bảng. Đối với công cụ InnoDB, các chỉ mục được lưu trữ trong vùng bảng, cùng với bảng. Nếu innodb_file_per_table được đặt, các chỉ mục sẽ nằm trong tệp .ibd của bảng cùng với tệp .frm. Đối với công cụ bộ nhớ, dữ liệu được lưu trữ trong bộ nhớ (heap) trong khi cấu trúc được lưu trữ trong tệp .frm trên đĩa. Trong MySQL 8.0 sắp tới, các tệp siêu dữ liệu (.frm, .par, dp.opt) sẽ bị xóa với sự ra đời của lược đồ từ điển dữ liệu mới.
Điều quan trọng cần lưu ý là nếu bạn đang sử dụng không gian bảng chia sẻ InnoDB để lưu trữ dữ liệu bảng ( innodb_file_per_table =OFF ), kích thước dữ liệu vật lý MySQL của bạn dự kiến sẽ tăng liên tục ngay cả sau khi bạn cắt bớt hoặc xóa các hàng dữ liệu khổng lồ. Cách duy nhất để lấy lại không gian trống trong cấu hình này là xuất, xóa cơ sở dữ liệu hiện tại và nhập lại chúng trở lại thông qua mysqldump. Do đó, điều quan trọng là phải đặt innodb_file_per_table =ON nếu bạn lo lắng về không gian đĩa, vì vậy khi cắt bớt một bảng, không gian có thể được lấy lại. Ngoài ra, với cấu hình này, thao tác DELETE khổng lồ sẽ không giải phóng dung lượng ổ đĩa trừ khi BẢNG TỐI ƯU HÓA được thực thi sau đó.
MySQL lưu trữ từng cơ sở dữ liệu trong thư mục riêng của nó theo đường dẫn "datadir". Ngoài ra, các tệp nhật ký và các tệp MySQL có liên quan khác như tệp socket và PID, theo mặc định, cũng sẽ được tạo trong datadir. Vì lý do hiệu suất và độ tin cậy, bạn nên lưu trữ các tệp nhật ký MySQL trên một đĩa hoặc phân vùng riêng biệt - đặc biệt là nhật ký lỗi MySQL và nhật ký nhị phân.
Ước tính kích thước cơ sở dữ liệu
Cách cơ bản để ước tính kích thước là tìm tỷ lệ tăng trưởng giữa hai thời điểm khác nhau, sau đó nhân nó với kích thước cơ sở dữ liệu hiện tại. Đo lưu lượng cơ sở dữ liệu vào giờ cao điểm của bạn cho mục đích này không phải là phương pháp hay nhất và không đại diện cho việc sử dụng cơ sở dữ liệu của bạn nói chung. Hãy nghĩ về một hoạt động hàng loạt hoặc một quy trình được lưu trữ chạy lúc nửa đêm hoặc mỗi tuần một lần. Cơ sở dữ liệu của bạn có thể phát triển đáng kể vào buổi sáng, trước khi có thể bị thu hẹp bởi hoạt động dọn phòng lúc nửa đêm.
Một cách khả thi là sử dụng các bản sao lưu của chúng tôi làm yếu tố cơ sở cho phép đo này. Sao lưu vật lý như Percona Xtrabackup, MariaDB Backup và ảnh chụp nhanh hệ thống tệp sẽ tạo ra bản trình bày chính xác hơn về kích thước cơ sở dữ liệu của bạn so với sao lưu logic, vì nó chứa bản sao nhị phân của cơ sở dữ liệu và các chỉ mục. Sao lưu logic như mysqldump chỉ lưu trữ các câu lệnh SQL có thể được thực thi để tái tạo các định nghĩa đối tượng cơ sở dữ liệu ban đầu và dữ liệu bảng. Tuy nhiên, bạn vẫn có thể đưa ra một tỷ lệ tăng trưởng tốt bằng cách so sánh các bản sao lưu mysqldump.
Chúng ta có thể sử dụng công thức sau để ước tính kích thước cơ sở dữ liệu:
Ở đâu,
- B - Kích thước sao lưu đầy đủ của tuần hiện tại,
- B - Kích thước sao lưu đầy đủ của tuần trước,
- Dữ liệu db - Tổng kích thước dữ liệu cơ sở dữ liệu,
- Db chỉ mục - Tổng kích thước chỉ mục cơ sở dữ liệu,
- 52 - Số tuần trong năm,
- Y - Năm.
Tổng kích thước cơ sở dữ liệu (dữ liệu và chỉ mục) bằng MB có thể được tính bằng cách sử dụng các câu lệnh sau:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+Phương trình trên có thể được sửa đổi nếu bạn muốn sử dụng các bản sao lưu hàng tháng. Thay đổi giá trị không đổi của 52 thành 12 (12 tháng trong một năm) và bạn đã sẵn sàng.
Ngoài ra, đừng quên tài khoản cho innodb_log_file_size x 2, innodb_data_file_path và đối với Galera Cluster, hãy thêm gcache.size giá trị.
Ước tính kích thước nhật ký nhị phân
Nhật ký nhị phân được tạo bởi MySQL master cho các mục đích sao chép và khôi phục tại thời điểm. Nó là một tập hợp các tệp nhật ký chứa thông tin về các sửa đổi dữ liệu được thực hiện trên máy chủ MySQL. Kích thước của nhật ký nhị phân phụ thuộc vào số lượng thao tác ghi và định dạng nhật ký nhị phân - STATEMENT, ROW hoặc MIXED. Nhật ký nhị phân dựa trên câu lệnh thường nhỏ hơn nhiều so với nhật ký nhị phân dựa trên hàng, bởi vì nó chỉ bao gồm ghi các câu lệnh trong khi dựa trên hàng bao gồm thông tin hàng đã sửa đổi.
Cách tốt nhất để ước tính mức sử dụng đĩa tối đa của nhật ký nhị phân là đo kích thước nhật ký nhị phân trong một ngày và nhân nó với expire_logs_days giá trị (mặc định là 0 - không tự động xóa). Điều quan trọng là phải đặt expire_logs_days vì vậy bạn có thể ước tính kích thước một cách chính xác. Theo mặc định, mỗi bản ghi nhị phân được giới hạn khoảng 1GB trước khi MySQL xoay tệp nhật ký nhị phân. Chúng ta có thể sử dụng một sự kiện MySQL để đơn giản xóa nhật ký nhị phân cho mục đích ước tính này.
Đầu tiên, hãy đảm bảo rằng biến event_scheduler được bật:
mysql> SET GLOBAL event_scheduler = ON;Sau đó, với tư cách là người dùng có đặc quyền (với các đặc quyền EVENT và RELOAD), hãy tạo sự kiện sau:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Đối với khối lượng công việc đòi hỏi nhiều ghi, bạn có thể cần phải rút ngắn khoảng thời gian này xuống còn 30 phút hoặc 10 phút trước khi nhật ký nhị phân đạt đến kích thước tối đa 1GB, sau đó làm tròn đầu ra lên đến một giờ. Sau đó, xác minh trạng thái của sự kiện bằng cách sử dụng câu lệnh sau và xem cột LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Sau đó, hãy xem các nhật ký nhị phân mà chúng ta có bây giờ:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Sau đó, chúng tôi có thể tính toán mức tăng trưởng nhật ký nhị phân trung bình của chúng tôi là khoảng ~ 562 MB mỗi giờ trong giờ cao điểm. Nhân giá trị này với 24 giờ và expire_logs_days giá trị:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Chúng tôi sẽ nhận được 94416 MB khoảng ~ 95 GB dung lượng đĩa cho nhật ký nhị phân của chúng tôi. Nhật ký chuyển tiếp của Slave về cơ bản giống với nhật ký nhị phân của chủ, ngoại trừ việc chúng được lưu trữ ở phía nô lệ. Do đó, tính toán này cũng áp dụng cho nhật ký chuyển tiếp phụ.
Đĩa trục chính hay trạng thái rắn?
Có hai loại hoạt động I / O trên tệp MySQL:
- Tệp định hướng I / O tuần tự:
- Không gian bảng hệ thống InnoDB (ibdata)
- Tệp nhật ký MySQL:
- Nhật ký nhị phân (binlog.xxxx)
- REDO nhật ký (ib_logfile *)
- Nhật ký chung
- Nhật ký truy vấn chậm
- Nhật ký lỗi
- Tệp định hướng I / O ngẫu nhiên:
- Tệp dữ liệu tệp mỗi bảng InnoDB (* .ibd) với innodb_file_per_table =ON (mặc định).
Cân nhắc đặt các tệp theo hướng I / O ngẫu nhiên trong hệ thống con đĩa thông lượng cao để có hiệu suất tốt nhất. Đây có thể là ổ đĩa flash - SSD hoặc thẻ NVRAM hoặc đĩa trục quay RPM cao như SAS 15K hoặc 10K, với bộ điều khiển RAID phần cứng và bộ phận hỗ trợ bằng pin. Đối với các tệp hướng I / O tuần tự, việc lưu trữ trên HDD với bộ nhớ đệm ghi được hỗ trợ bằng pin sẽ đủ tốt cho MySQL. Lưu ý rằng khả năng bị giảm hiệu suất nếu pin đã hết.
Chúng tôi sẽ đề cập đến lĩnh vực này (ước tính thông lượng đĩa và phân bổ tệp) trong một bài đăng riêng.
Lập kế hoạch và kích thước năng lực
Lập kế hoạch năng lực có thể giúp chúng tôi xây dựng một máy chủ cơ sở dữ liệu sản xuất với đủ tài nguyên để tồn tại trong các hoạt động hàng ngày. Chúng tôi cũng phải cung cấp cho các nhu cầu đột xuất, tính đến nhu cầu lưu trữ và thông lượng đĩa trong tương lai. Do đó, lập kế hoạch dung lượng là rất quan trọng để đảm bảo cơ sở dữ liệu có đủ chỗ trống cho đến chu kỳ làm mới phần cứng tiếp theo.
Tốt nhất bạn nên minh họa điều này bằng một ví dụ. Xem xét tình huống sau:
- Chu kỳ phần cứng tiếp theo:3 năm
- Kích thước cơ sở dữ liệu hiện tại:2013 MB
- Kích thước sao lưu đầy đủ hiện tại (tuần N):1177 MB
- Kích thước sao lưu đầy đủ trước đó (tuần N-1):936 MB
- Kích thước Delta:241MB mỗi tuần
- Tỷ lệ Delta:tăng 25,7% mỗi tuần
- Tổng số tuần trong 3 năm:156 tuần
- Ước tính tổng kích thước cơ sở dữ liệu:((1177 - 936) x 2013 x 156) / 936 = 80856 MB ~ 81 GB sau 3 năm
Nếu bạn đang sử dụng nhật ký nhị phân, hãy tổng hợp nó từ giá trị mà chúng tôi nhận được trong phần trước:
- 81 + 95 =176 GB bộ nhớ cho cơ sở dữ liệu và nhật ký nhị phân.
Thêm ít nhất 100% dung lượng cho các tác vụ vận hành và bảo trì (sao lưu cục bộ, lưu trữ dữ liệu, nhật ký lỗi, tệp hệ điều hành, v.v.):
- 176 + 176 =352 GB tổng dung lượng ổ đĩa.
Dựa trên ước tính này, chúng tôi có thể kết luận rằng chúng tôi sẽ cần ít nhất 352 GB dung lượng đĩa cho cơ sở dữ liệu của mình trong 3 năm. Bạn có thể sử dụng giá trị này để biện minh cho việc mua phần cứng mới của mình. Ví dụ:nếu bạn muốn mua một máy chủ chuyên dụng mới, bạn có thể chọn 6 x 128 SSD RAID 10 với bộ điều khiển RAID được hỗ trợ bằng pin sẽ cung cấp cho bạn tổng dung lượng đĩa khoảng 384 GB. Hoặc, nếu bạn thích đám mây hơn, bạn có thể nhận được 100GB bộ nhớ khối với IOPS được cung cấp để sử dụng cơ sở dữ liệu 81GB của chúng tôi và sử dụng bộ nhớ khối liên tục tiêu chuẩn cho nhật ký nhị phân 95GB của chúng tôi và các hoạt động sử dụng khác.
Chúc bạn đo kích thước vui vẻ!
