Những ngày mua sắm trực tuyến lớn nhất trong năm sắp đến gần. Cơ sở dữ liệu của bạn đã sẵn sàng chưa? Bằng cách điều chỉnh 20 biến hệ thống MariaDB chính, bạn sẽ củng cố hiệu suất của cơ sở dữ liệu của mình , khả năng mở rộng và tính khả dụng , đảm bảo mọi khách hàng tiềm năng đều có trải nghiệm người dùng mượt mà. Các biến hệ thống sau xuất hiện nhiều lần trong việc định cấu hình môi trường máy chủ MariaDB tối ưu. Thực hiện các đề xuất của chúng tôi để có những giá trị phù hợp nhất và biến khoảng thời gian Thứ Sáu Đen - Thứ Hai Điện Tử năm nay trở thành khoảng thời gian tuyệt vời nhất từ trước đến nay.
Một số lưu ý quan trọng:
- Đừng chấp nhận những đề xuất này một cách mù quáng. Mỗi môi trường MariaDB là duy nhất và cần phải suy nghĩ thêm trước khi thực hiện bất kỳ thay đổi nào. Rất có thể bạn sẽ cần điều chỉnh các cài đặt này cho trường hợp sử dụng và môi trường cụ thể của mình.
- Tệp cấu hình MariaDB nằm trong /etc/my.cnf. Mỗi khi sửa đổi tệp này, bạn sẽ cần phải khởi động lại dịch vụ MySQL để những thay đổi mới có thể có hiệu lực.
20 Đề xuất điều chỉnh Thứ Sáu Đen và Thứ Hai Điện tử
1. Kích thước hồ bơi đệm InnoDB
Kích thước vùng đệm InnoDB, đây là cài đặt số 1 cần xem xét cho bất kỳ cài đặt nào sử dụng InnoDB. Vùng đệm là nơi dữ liệu và chỉ mục được lưu vào bộ nhớ đệm; có nó càng lớn càng tốt sẽ đảm bảo bạn sử dụng bộ nhớ chứ không phải đĩa cho hầu hết các hoạt động đọc.
2. Kích thước tệp nhật ký InnoDB
innodb_log-file-size là kích thước của nhật ký làm lại, được sử dụng để đảm bảo ghi nhanh và bền. Có hai gợi ý chung cho việc định cỡ tệp nhật ký InnoDB:
- Đặt tổng kích thước kết hợp của các tệp nhật ký InnoDB lớn hơn 25–50% kích thước vùng đệm InnoDB
hoặc
- Đặt kích thước nhật ký tệp nhật ký InnoDB kết hợp bằng với các mục nhật ký trị giá một giờ trong thời gian tải cao điểm
Các tệp nhật ký lớn hơn có thể dẫn đến khôi phục chậm hơn trong trường hợp máy chủ gặp sự cố. Tuy nhiên, chúng cũng làm giảm số lượng điểm kiểm tra cần thiết và giảm I / O đĩa.
Đánh giá kích thước của nhật ký nhị phân trị giá một giờ khi tải hoạt động, sau đó quyết định xem có tăng kích thước của tệp nhật ký InnoDB hay không.
Nhận đúng kích thước tệp nhật ký innodb là điều quan trọng để đạt được hiệu suất hệ thống tốt. Công cụ lưu trữ MariaDB’s InnoDB sử dụng không gian nhật ký làm lại có kích thước cố định (hình tròn). Kích thước được kiểm soát bởi innodb_log_file_size và innodb_log_files_in_group (mặc định 2). Nhân các giá trị đó để có được không gian nhật ký làm lại có sẵn để sử dụng. Mặc dù về mặt kỹ thuật, việc bạn sử dụng biến innodb_log_file_size hay innodb_log_files_in_group để kiểm soát kích thước không gian làm lại không quan trọng, hầu hết mọi người chỉ làm việc với innodb_log_file_size và để innodb_log_files_in_group một mình.
Kích thước không gian làm lại của InnoDB là một trong những tùy chọn cấu hình quan trọng nhất cho khối lượng công việc cần ghi nhiều. Tuy nhiên, nó đi kèm với sự đánh đổi. Càng nhiều không gian làm lại được định cấu hình, InnoDB càng có thể tối ưu hóa I / O ghi. Tuy nhiên, việc tăng không gian làm lại cũng có nghĩa là thời gian khôi phục lâu hơn khi hệ thống mất nguồn hoặc bị treo vì các lý do khác.
3. Kích thước bộ đệm nhật ký InnoDB
Kích thước bộ đệm nhật ký InnoDB lớn hơn có nghĩa là ít I / O đĩa hơn cho các giao dịch lớn hơn. Bạn nên đặt giá trị này thành 64M trên tất cả các máy chủ.
4. Khoảng thời gian xả nhật ký InnoDB
Biến innodb_flush_log_at_trx_commit điều khiển khi quá trình xả bộ đệm nhật ký vào đĩa xảy ra. innodb_flush_log_at_trx_commit =1 (mặc định) xóa bộ đệm nhật ký vào đĩa tại mỗi lần cam kết giao dịch. Đây là tùy chọn an toàn nhất nhưng cũng kém hiệu quả nhất.
innodb_flush_log_at_trx_commit =0 xóa bộ đệm nhật ký vào đĩa mỗi giây, nhưng không có gì trong cam kết giao dịch. Có thể mất tới một giây (có thể nhiều hơn do lập lịch trình). Nếu có bất kỳ sự cố nào, MySQL hoặc máy chủ có thể mất dữ liệu. Đây là lựa chọn nhanh nhất nhưng kém an toàn nhất.
innodb_flush_log_at_trx_commit =2 ghi bộ đệm nhật ký ra tệp trên mỗi lần cam kết nhưng sẽ chuyển vào đĩa mỗi giây. Nếu bộ nhớ đệm ổ đĩa có pin dự phòng (ví dụ:bộ điều khiển đột kích bộ nhớ đệm được hỗ trợ bằng pin) thì đây thường là sự cân bằng tốt nhất về hiệu suất và an toàn. Sự cố của MySQL sẽ không làm mất dữ liệu. Sự cố máy chủ hoặc mất điện có thể mất tới một giây (có thể nhiều hơn do lên lịch quy trình). Bộ nhớ đệm được hỗ trợ bằng pin sẽ giảm khả năng này.
Chúng tôi khuyên bạn nên sử dụng tùy chọn đầu tiên để đảm bảo an toàn.
5. Dung lượng IO InnoDB
innodb_io_capacity phải được đặt thành số IOPS tối đa mà bộ nhớ cơ bản có thể xử lý.
Theo mặc định, giá trị này được đặt thành 1000. Chúng tôi khuyên bạn nên đo điểm chuẩn bộ nhớ để xác định xem bạn có thể tăng giá trị này hơn nữa hay không.
6. Kích thước bộ nhớ cache của chuỗi
Giám sát giá trị của Threads_create. Nếu nó tiếp tục tăng với hơn một vài chuỗi mỗi phút, hãy tăng giá trị của thread_cache_size.
Kích thước bộ nhớ cache của chuỗi được đặt thành 200 trong cấu hình mặc định hiện tại.
7. Bộ nhớ đệm bảng và bộ nhớ đệm định nghĩa bảng
Các biến table_open_cache và table_defintion_cache kiểm soát số lượng bảng và định nghĩa để luôn mở cho tất cả các chuỗi.
Theo dõi Open_tables, Open_table_defintitions, Opened_tables và Opened_table_definitions để xác định giá trị tốt nhất. Đề xuất chung là chỉ đặt table_open_cache (và sau đó là table_definition_cache) đủ cao để giảm tốc độ tăng của giá trị trạng thái Opened_tables (và Opened_table_definitions).
Cả table_open_cache và table_defintion_cache đều được đặt thành 2048 trong cấu hình mặc định.
8. Truy vấn Cache
Bộ nhớ đệm truy vấn là một nút thắt cổ chai nổi tiếng có thể thấy ngay cả khi đồng thời ở mức trung bình. Tùy chọn tốt nhất là vô hiệu hóa nó ngay từ ngày đầu tiên bằng cách đặt query_cache_size =0 (mặc định trong MariaDB 10) và sử dụng các cách khác để tăng tốc độ truy vấn đọc:lập chỉ mục tốt, thêm bản sao để phân tán tải đọc hoặc sử dụng bộ đệm ngoài ( chẳng hạn như memcache hoặc redis). Nếu bạn đã xây dựng ứng dụng MariaDB của mình với bộ đệm truy vấn được bật và chưa bao giờ nhận thấy bất kỳ vấn đề nào, bộ đệm truy vấn có thể có lợi cho bạn. Trong trường hợp đó, hãy thận trọng nếu bạn quyết định tắt nó.
9. Bảng tạm thời, tmp_table_size và max_heap_table_size
MySQL sử dụng giá trị thấp hơn của max_heap_table_size và tmp_table_size để giới hạn kích thước của các bảng tạm thời trong bộ nhớ. Đây là các biến cho mỗi khách hàng. Mặc dù giá trị này lớn có thể giúp giảm số lượng bảng tạm thời được tạo trên đĩa, nhưng nó cũng làm tăng nguy cơ đạt đến dung lượng bộ nhớ của máy chủ vì đây là dung lượng dành cho mỗi máy khách. Nói chung 32M đến 64M là giá trị được đề xuất để bắt đầu cho cả hai biến và điều chỉnh khi cần thiết.
Các bảng tạm thời thường được sử dụng cho các truy vấn GROUP BY, ORDER BY, DISTINCT, UNION, phụ, v.v. Lý tưởng nhất là MySQL nên tạo các bảng này trong bộ nhớ, với càng ít trên đĩa càng tốt.
Điều quan trọng cần lưu ý là các truy vấn không sử dụng các phép nối một cách thích hợp và việc tạo các bảng tạm thời lớn có thể là một lý do khiến số lượng các bảng tạm thời trên đĩa cao hơn. Một lý do khác là công cụ lưu trữ bộ nhớ sử dụng các cột có độ dài cố định và giả định tình huống xấu nhất. Nếu các cột không được định kích thước chính xác (ví dụ:VARCHAR (255) cho một chuỗi ngắn), điều này ảnh hưởng đến kích thước của bảng trong bộ nhớ và có thể khiến nó chuyển sang đĩa sớm hơn bình thường. Ngoài ra, các bảng tạm thời với các cột blob và văn bản sẽ ngay lập tức được chuyển vào đĩa, vì công cụ lưu trữ bộ nhớ không hỗ trợ chúng.
Cả hai hiện được đặt thành 64M theo mặc định.
10. Mức độ nhật ký cảnh báo
Chúng tôi khuyên bạn nên đặt mức nhật ký cảnh báo này thành log_warnings =2. Làm như vậy sẽ ghi lại thông tin về các kết nối bị hủy bỏ và lỗi bị từ chối truy cập.
11. Kết nối tối đa
Nếu bạn thường gặp phải lỗi "Quá nhiều kết nối", thì max_connections quá thấp. Thông thường, do ứng dụng không đóng các kết nối với cơ sở dữ liệu một cách chính xác, bạn cần nhiều hơn 151 kết nối mặc định. Hạn chế chính của các giá trị cao cho max_connections (giả sử, 1.000 trở lên) là máy chủ sẽ không phản hồi nếu nó phải chạy nhiều giao dịch đang hoạt động đó. Sử dụng nhóm kết nối ở cấp ứng dụng hoặc nhóm luồng ở cấp MariaDB có thể giúp ích ở đây.
12. Cách ly giao dịch
Điều tra các mức cô lập giao dịch hiện có và xác định mức cô lập giao dịch tốt nhất cho trường hợp sử dụng của máy chủ của bạn.
13. Định dạng nhật ký nhị phân
Chúng tôi khuyên bạn nên sử dụng định dạng nhật ký nhị phân ROW để sao chép tổng thể.
14. Giá trị tự động gia tăng
Để giúp giảm nguy cơ va chạm giữa hai bản gốc được ghi đồng thời, các giá trị bù tự động tăng và giá trị bù tăng tự động cần được điều chỉnh cho phù hợp.
15. Đồng bộ hóa Binlog
Theo mặc định, hệ điều hành xử lý việc chuyển binlog vào đĩa. Trong trường hợp máy chủ gặp sự cố, có thể mất các giao dịch từ nhật ký nhị phân, dẫn đến việc sao chép không đồng bộ. Đặt sync_binlog =1 làm cho tệp binlog được xóa trong mỗi lần cam kết.
Cách này chậm hơn nhưng là tùy chọn an toàn nhất.
16. Crash Safe (r) Slaves
Để giúp tránh lỗi sao chép sau sự cố nô lệ, hãy bật khôi phục và đồng bộ hóa nhật ký chuyển tiếp và đồng bộ hóa nhật ký chuyển tiếp và các tệp thông tin nhật ký chuyển tiếp vào đĩa.
17. Nhật ký cập nhật nô lệ
Để tạo bản sao theo chuỗi (master -> slave -> slave), log_slave_updates cần được bật. Điều này yêu cầu nô lệ ghi các giao dịch được sao chép vào nhật ký nhị phân của chính nó để sau đó chúng có thể được sao chép cho các nô lệ của nó.
18. Nô lệ chỉ đọc
Các nô lệ phải ở chế độ chỉ đọc để tránh dữ liệu vô tình được ghi vào chúng.
Lưu ý :Người dùng có siêu đặc quyền vẫn có thể viết khi máy chủ ở chế độ chỉ đọc.
19. Slave Net Timeout
Biến slave_net_timeout là số giây slave sẽ đợi một gói tin từ master trước khi cố gắng kết nối lại. Giá trị mặc định là 3600 (1 giờ). Điều này có nghĩa là nếu liên kết gặp sự cố và không được phát hiện, có thể mất đến một giờ trước khi nô lệ kết nối lại. Điều này có thể dẫn đến việc nô lệ đột nhiên chậm hơn chủ tới một giờ.
Chúng tôi khuyên bạn nên đặt slave_net_timeout thành giá trị hợp lý hơn, chẳng hạn như 30 hoặc 60.
20. Xem Hội thảo trên web của chúng tôi về Chuẩn bị cho Thứ Sáu Đen và Thứ Hai Điện tử
Xem hội thảo trên web theo yêu cầu của chúng tôi - Chuẩn bị cho Thứ Sáu Đen và Thứ Hai Điện tử - để tìm hiểu bốn nguyên tắc quan trọng của việc chuẩn bị cơ sở dữ liệu: các biện pháp bảo mật để bảo vệ cơ sở dữ liệu của bạn khỏi các cuộc tấn công độc hại, hãy điều chỉnh hiệu suất để đảm bảo bạn mang đến trải nghiệm người dùng mượt mà, chiến lược tính khả dụng cao để đảm bảo bạn không bỏ lỡ một lần giảm giá nào và khả năng mở rộng để chuẩn bị cho cả mức tăng trưởng dự kiến và mức tăng đột biến.
