Kể từ khi MySQL ban đầu được chia nhỏ để tạo thành MariaDB, nó đã được hỗ trợ rộng rãi và nhanh chóng được chấp nhận bởi một lượng lớn người dùng trong cộng đồng cơ sở dữ liệu mã nguồn mở. Ban đầu là một sự thay thế thả xuống, MariaDB đã bắt đầu tạo ra sự khác biệt so với MySQL, đặc biệt là với việc phát hành MariaDB 10.2.
Tuy nhiên, mặc dù vậy, vẫn không có sự khác biệt thực sự giữa MariaDB và MySQL, vì cả hai đều có các công cụ tương thích và có thể chạy nguyên bản với nhau. Vì vậy, đừng ngạc nhiên nếu việc điều chỉnh thiết lập MariaDB của bạn có cách tiếp cận tương tự như một cách điều chỉnh MySQL.
Blog này sẽ thảo luận về việc điều chỉnh MariaDB, cụ thể là những hệ thống chạy trong môi trường Linux.
Tối ưu hóa Hệ thống và Phần cứng MariaDB
MariaDB khuyên bạn nên cải thiện phần cứng của mình theo thứ tự ưu tiên sau ...
Bộ nhớ
Bộ nhớ là yếu tố quan trọng nhất đối với cơ sở dữ liệu vì nó cho phép bạn điều chỉnh các Biến Hệ thống Máy chủ. Nhiều bộ nhớ hơn có nghĩa là bộ nhớ đệm của khóa và bảng lớn hơn, được lưu trữ trong bộ nhớ để các đĩa có thể truy cập, thứ tự cường độ chậm hơn, sau đó sẽ giảm xuống.
Tuy nhiên, hãy lưu ý rằng chỉ cần thêm nhiều bộ nhớ hơn có thể không dẫn đến cải thiện mạnh mẽ nếu các biến máy chủ không được đặt để tận dụng bộ nhớ có sẵn.
Sử dụng nhiều khe cắm RAM trên bo mạch chủ sẽ làm tăng tần số bus và sẽ có nhiều độ trễ giữa RAM và CPU. Điều này có nghĩa là bạn nên sử dụng kích thước RAM cao nhất trên mỗi khe cắm.
Đĩa
Truy cập đĩa nhanh là rất quan trọng, vì cuối cùng đó là nơi chứa dữ liệu. Con số quan trọng là thời gian tìm kiếm đĩa (một phép đo tốc độ đĩa vật lý có thể di chuyển để truy cập dữ liệu), vì vậy hãy chọn các đĩa có thời gian tìm kiếm càng thấp càng tốt. Bạn cũng có thể thêm các đĩa chuyên dụng cho các tệp tạm thời và nhật ký giao dịch.
Fast Ethernet
Với các yêu cầu thích hợp cho băng thông internet của bạn, ethernet nhanh có nghĩa là nó có thể có phản hồi nhanh hơn đối với các yêu cầu của khách hàng, thời gian phản hồi sao chép để đọc nhật ký nhị phân trên các nô lệ, thời gian phản hồi nhanh hơn cũng rất quan trọng, đặc biệt là trên Galera các cụm dựa trên.
CPU
Mặc dù tắc nghẽn phần cứng thường xảy ra ở những nơi khác, nhưng bộ xử lý nhanh hơn cho phép thực hiện các phép tính nhanh hơn và kết quả được gửi trở lại máy khách nhanh hơn. Bên cạnh tốc độ bộ xử lý, tốc độ bus của bộ xử lý và kích thước bộ nhớ cache cũng là những yếu tố quan trọng cần xem xét.
Đặt Bộ lập lịch I / O Đĩa của bạn
Bộ lập lịch I / O tồn tại như một cách để tối ưu hóa các yêu cầu truy cập đĩa. Nó kết hợp các yêu cầu I / O với các vị trí tương tự trên đĩa. Điều này có nghĩa là ổ đĩa không cần phải tìm kiếm thường xuyên và cải thiện thời gian phản hồi tổng thể rất lớn và tiết kiệm các hoạt động của đĩa. Các giá trị được đề xuất cho hiệu suất I / O là noop và deadline.
noop hữu ích để kiểm tra xem các quyết định lập lịch I / O phức tạp của các bộ lập lịch khác có gây ra hồi quy hiệu suất I / O hay không. Trong một số trường hợp, nó có thể hữu ích đối với các thiết bị tự lên lịch I / O, làm bộ lưu trữ thông minh hoặc các thiết bị không phụ thuộc vào chuyển động cơ học, như SSD. Thông thường, bộ lập lịch I / O DEADLINE là lựa chọn tốt hơn cho các thiết bị này, nhưng do NOOP ít chi phí hơn có thể tạo ra hiệu suất tốt hơn trên một số khối lượng công việc nhất định.
Đối với thời hạn, nó là bộ lập lịch I / O hướng vào độ trễ. Mỗi yêu cầu I / O đều có thời hạn được ấn định. Thông thường, các yêu cầu được lưu trữ trong các hàng đợi (đọc và ghi) được sắp xếp theo số ngành. Thuật toán DEADLINE duy trì hai hàng đợi bổ sung (đọc và ghi) nơi các yêu cầu được sắp xếp theo thời hạn. Miễn là không có yêu cầu nào hết thời gian chờ, hàng đợi "sector" sẽ được sử dụng. Nếu hết thời gian chờ xảy ra, các yêu cầu từ hàng đợi "thời hạn cuối cùng" sẽ được phục vụ cho đến khi không còn yêu cầu nào hết hạn nữa. Nói chung, thuật toán thích đọc hơn ghi.
Đối với thiết bị PCIe (ổ SSD NVMe), chúng có hàng đợi nội bộ lớn cùng với dịch vụ nhanh chóng và không yêu cầu hoặc không được hưởng lợi từ việc đặt bộ lập lịch I / O. Bạn nên không có thông số cấu hình chế độ lập lịch rõ ràng.
Bạn có thể kiểm tra cài đặt bộ lập lịch của mình bằng:
cat /sys/block/${DEVICE}/queue/schedulerVí dụ:đầu ra sẽ giống như sau:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqĐể đặt nó là vĩnh viễn, hãy chỉnh sửa / etc / default / grub tệp cấu hình, tìm biến GRUB_CMDLINE_LINUX và thêm thang máy giống như bên dưới:
GRUB_CMDLINE_LINUX="elevator=noop"Tăng Giới hạn Tệp Mở
Để đảm bảo máy chủ hoạt động tốt, tổng số kết nối máy khách, tệp cơ sở dữ liệu và tệp nhật ký không được vượt quá giới hạn bộ mô tả tệp tối đa trên hệ điều hành (ulimit-n). Hệ thống Linux giới hạn số lượng bộ mô tả tệp mà bất kỳ quy trình nào có thể mở là 1.024 cho mỗi quy trình. Trên các máy chủ cơ sở dữ liệu đang hoạt động (đặc biệt là các máy chủ sản xuất), nó có thể dễ dàng đạt đến giới hạn hệ thống mặc định.
Để tăng điều này, hãy chỉnh sửa /etc/security/limits.conf và chỉ định hoặc thêm phần sau:
mysql soft nofile 65535
mysql hard nofile 65535Thao tác này yêu cầu khởi động lại hệ thống. Sau đó, bạn có thể xác nhận bằng cách chạy như sau:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Theo tùy chọn, bạn có thể đặt điều này qua mysqld_safe nếu bạn đang bắt đầu quy trình mysqld thông qua mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295hoặc nếu bạn đang sử dụng systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadĐặt Swappiness trên Linux cho MariaDB
Linux Swap đóng một vai trò lớn trong hệ thống cơ sở dữ liệu. Nó hoạt động giống như chiếc lốp dự phòng trên xe của bạn, khi bộ nhớ bị rò rỉ khó chịu làm ảnh hưởng đến công việc của bạn, máy sẽ chạy chậm lại ... nhưng trong hầu hết các trường hợp vẫn sử dụng được để hoàn thành nhiệm vụ được giao.
Để áp dụng các thay đổi đối với vẻ đẹp của bạn, chỉ cần chạy,
sysctl -w vm.swappiness=1Điều này xảy ra tự động, không cần khởi động lại máy chủ. Để làm cho nó ổn định, hãy chỉnh sửa /etc/sysctl.conf và thêm dòng,
vm.swappiness=1Việc đặt swappiness =0 khá phổ biến, nhưng kể từ khi phát hành các nhân mới (tức là nhân> 2.6.32-303), các thay đổi đã được thực hiện nên bạn cần đặt vm.swappiness =1.
Tối ưu hóa Hệ thống Tệp cho MariaDB
Hệ thống tệp phổ biến nhất được sử dụng trong môi trường Linux chạy MariaDB là ext4 và XFS. Cũng có một số thiết lập nhất định có sẵn để triển khai một kiến trúc sử dụng ZFS và BRTFS (như được tham chiếu trong tài liệu MariaDB).
Ngoài ra, hầu hết các thiết lập cơ sở dữ liệu không cần ghi lại thời gian truy cập tệp. Bạn có thể muốn tắt tính năng này khi gắn ổ đĩa vào hệ thống. Để thực hiện việc này, hãy chỉnh sửa tệp / etc / fstab của bạn. Ví dụ:trên một ổ đĩa có tên / dev / md2, nó trông như thế này:
/dev/md2 / ext4 defaults,noatime 0 0Tạo Phiên bản MariaDB Tối ưu
Lưu trữ dữ liệu trên một ổ đĩa riêng biệt
Luôn luôn lý tưởng để tách dữ liệu cơ sở dữ liệu của bạn trên một ổ đĩa riêng biệt. Ổ đĩa này dành riêng cho những loại ổ lưu trữ nhanh như SSD, NVMe hoặc thẻ PCIe. Ví dụ:nếu toàn bộ khối lượng hệ thống của bạn bị lỗi, bạn sẽ có khối lượng cơ sở dữ liệu của mình an toàn và yên tâm không bị ảnh hưởng trong trường hợp phần cứng lưu trữ của bạn bị lỗi.
Chỉnh sửa MariaDB để sử dụng bộ nhớ hiệu quả
innodb_buffer_pool_size
Giá trị chính để điều chỉnh trên máy chủ cơ sở dữ liệu với các bảng XtraDB / InnoDB hoàn toàn / chủ yếu, có thể được thiết lập lên đến 80% tổng bộ nhớ trong các môi trường này. Nếu được đặt thành 2 GB trở lên, có thể bạn cũng sẽ muốn điều chỉnh innodb_buffer_pool_instances. Bạn có thể đặt động này nếu bạn đang sử dụng phiên bản MariaDB> =10.2.2. Nếu không, nó yêu cầu khởi động lại máy chủ.
tmp_memory_table_size / max_heap_table_size
Đối với tmp_memory_table_size (tmp_table_size), nếu bạn đang xử lý các bảng tạm thời lớn, việc đặt giá trị này cao hơn sẽ tăng hiệu suất vì nó sẽ được lưu trữ trong bộ nhớ. Điều này thường xảy ra trên các truy vấn sử dụng nhiều GROUP BY, UNION hoặc truy vấn phụ. Mặc dù nếu max_heap_table_size nhỏ hơn, giới hạn thấp hơn sẽ được áp dụng. Nếu một bảng vượt quá giới hạn, MariaDB sẽ chuyển nó thành bảng MyISAM hoặc Aria. Bạn có thể xem liệu nó có cần thiết phải tăng hay không bằng cách so sánh các biến trạng thái Created_tmp_disk_tables và Created_tmp_tables để xem có bao nhiêu bảng tạm thời trong tổng số bảng đã tạo cần được chuyển đổi sang đĩa. Các truy vấn GROUP BY thường phức tạp có trách nhiệm vượt quá giới hạn.
Trong khi max_heap_table_size, đây là kích thước tối đa cho các bảng MEMORY do người dùng tạo. Giá trị được đặt trên biến này chỉ có thể áp dụng cho các bảng mới được tạo hoặc được tạo lại chứ không phải các bảng hiện có. Kích thước max_heap_table_size và tmp_table_size nhỏ hơn cũng giới hạn các bảng trong bộ nhớ nội bộ. Khi đạt đến kích thước tối đa, bất kỳ nỗ lực nào khác để chèn dữ liệu sẽ nhận được lỗi "bảng ... đã đầy". Các bảng tạm thời được tạo bằng CREATE TEMPORARY sẽ không được chuyển đổi thành Aria, như xảy ra với các bảng tạm thời nội bộ, nhưng cũng sẽ nhận được lỗi đầy đủ của bảng.
innodb_log_file_size
Bộ nhớ lớn với tốc độ xử lý cao và đĩa I / O nhanh không phải là mới và có mức giá hợp lý như nó đề xuất. Nếu bạn muốn tăng hiệu suất nhiều hơn, đặc biệt là trong quá trình xử lý và xử lý các giao dịch InnoDB của mình, việc đặt biến innodb_log_file_size thành giá trị lớn hơn như 5Gib hoặc thậm chí 10GiB là hợp lý. Tăng lên có nghĩa là các giao dịch lớn hơn có thể chạy mà không cần thực hiện I / O đĩa trước khi cam kết.
join_buffer_size
Trong một số trường hợp, các truy vấn của bạn có xu hướng thiếu tính năng lập chỉ mục thích hợp hoặc đơn giản, có những trường hợp bạn cần truy vấn này để chạy. Không trừ khi nó sẽ được gọi hoặc gọi nhiều từ góc độ khách hàng, việc đặt biến này là tốt nhất ở cấp phiên. Hãy tăng nó để có được các phép tham gia đầy đủ nhanh hơn khi không thể thêm chỉ mục, mặc dù hãy lưu ý các vấn đề về bộ nhớ, vì các phép nối sẽ luôn phân bổ kích thước tối thiểu.
Đặt max_allowed_packet của bạn
MariaDB có cùng bản chất với MySQL khi xử lý gói tin. Nó chia dữ liệu thành các gói và khách hàng phải biết giá trị biến max_allowed_packet. Máy chủ sẽ có một bộ đệm để lưu phần thân với kích thước tối đa tương ứng với giá trị max_allowed_packet này. Nếu máy khách gửi nhiều dữ liệu hơn kích thước max_allowed_packet, ổ cắm sẽ bị đóng. Chỉ thị max_allowed_packet xác định kích thước tối đa của gói có thể được gửi.
Đặt giá trị này quá thấp có thể khiến truy vấn dừng và đóng kết nối máy khách của nó, điều này khá phổ biến để nhận các lỗi như ER_NET_PACKET_TOO_LARGE hoặc Mất kết nối với máy chủ MySQL trong khi truy vấn. Tốt nhất, đặc biệt là đối với hầu hết các nhu cầu ứng dụng ngày nay, bạn có thể bắt đầu cài đặt này thành 512MiB. Nếu đó là loại ứng dụng có nhu cầu thấp, chỉ cần sử dụng giá trị mặc định và chỉ đặt biến này qua phiên khi cần thiết nếu dữ liệu được gửi hoặc nhận quá lớn so với giá trị mặc định (16MiB kể từ MariaDB 10.2.4). Trong một số khối lượng công việc nhất định yêu cầu xử lý các gói lớn, khi đó bạn cần phải điều chỉnh mức cao hơn theo nhu cầu của mình, đặc biệt là khi nhân rộng. Nếu max_allowed_packet trên máy phụ quá nhỏ, điều này cũng khiến máy phụ dừng luồng I / O.
Sử dụng Threadpool
Trong một số trường hợp, việc điều chỉnh này có thể không cần thiết hoặc được khuyến nghị cho bạn. Threadpools hiệu quả nhất trong các tình huống mà các truy vấn tương đối ngắn và tải bị ràng buộc bởi CPU (khối lượng công việc OLTP). Nếu khối lượng công việc không bị ràng buộc bởi CPU, bạn có thể vẫn muốn giới hạn số luồng để tiết kiệm bộ nhớ cho bộ đệm bộ nhớ cơ sở dữ liệu.
Sử dụng threadpool là một giải pháp lý tưởng, đặc biệt nếu hệ thống của bạn đang trải qua quá trình chuyển đổi ngữ cảnh và bạn đang tìm cách giảm thiểu điều này và duy trì số lượng luồng thấp hơn số lượng máy khách. Tuy nhiên, con số này cũng không nên quá thấp, vì chúng tôi cũng muốn tận dụng tối đa các CPU có sẵn. Do đó, lý tưởng là nên có một luồng hoạt động duy nhất cho mỗi CPU trên máy.
Bạn có thể đặt thread_pool_max_threads, thread_pool_min_threads cho số lượng tối đa và tối thiểu của chủ đề. Không giống như MySQL, điều này chỉ có trong MariaDB.
Đặt biến thread_handling xác định cách máy chủ xử lý các luồng cho các kết nối máy khách. Ngoài các luồng dành cho kết nối máy khách, điều này cũng áp dụng cho các luồng máy chủ nội bộ nhất định, chẳng hạn như các luồng nô lệ Galera.
Điều chỉnh Bộ nhớ cache trong Bảng của bạn + max_connections
Nếu bạn đang gặp phải các trường hợp không thường xuyên xảy ra trong danh sách xử lý về trạng thái Mở bảng và Đóng bảng, thì điều đó có thể cho thấy rằng bạn cần tăng bộ nhớ cache cho bảng của mình. Bạn cũng có thể theo dõi điều này thông qua lời nhắc máy khách mysql bằng cách chạy HIỂN THỊ TÌNH TRẠNG TOÀN CẦU NHƯ 'Open% table%'; và giám sát các biến trạng thái.
Đối với max_connections, nếu ứng dụng của bạn yêu cầu nhiều kết nối đồng thời, bạn có thể bắt đầu đặt giá trị này thành 500.
Đối với table_open_cache, nó sẽ là tổng số bảng của bạn nhưng tốt nhất bạn nên thêm nhiều hơn tùy thuộc vào loại truy vấn bạn phục vụ vì các bảng tạm thời cũng sẽ được lưu vào bộ nhớ đệm. Ví dụ:nếu bạn có 500 bảng, sẽ là hợp lý khi bạn bắt đầu với 1500.
Trong khi table_open_cache_instances của bạn, hãy bắt đầu đặt nó thành 8. Điều này có thể cải thiện khả năng mở rộng bằng cách giảm sự tranh chấp giữa các phiên, bộ nhớ đệm các bảng đang mở có thể được phân chia thành một số phiên bản cache nhỏ hơn có kích thước table_open_cache / table_open_cache_instances.
Đối với InnoDB, table_definition_cache hoạt động như một giới hạn mềm đối với số lượng phiên bản bảng đang mở trong bộ đệm từ điển dữ liệu InnoDB. Giá trị được xác định sẽ thiết lập số lượng định nghĩa bảng có thể được lưu trữ trong bộ đệm ẩn định nghĩa. Nếu bạn sử dụng một số lượng lớn bảng, bạn có thể tạo một bộ đệm ẩn định nghĩa bảng lớn để tăng tốc độ mở bảng. Bộ đệm ẩn định nghĩa bảng chiếm ít dung lượng hơn và không sử dụng bộ mô tả tệp, không giống như bộ đệm ẩn bảng thông thường. Giá trị tối thiểu là 400. Giá trị mặc định dựa trên công thức sau, được giới hạn ở giới hạn 2000:
MIN(400 + table_open_cache / 2, 2000)Nếu số lượng phiên bản bảng đang mở vượt quá cài đặt table_definition_cache, cơ chế LRU bắt đầu đánh dấu các phiên bản bảng để loại bỏ và cuối cùng xóa chúng khỏi bộ đệm từ điển dữ liệu. Giới hạn này giúp giải quyết các tình huống trong đó lượng bộ nhớ đáng kể sẽ được sử dụng để lưu vào bộ đệm các phiên bản bảng hiếm khi được sử dụng cho đến khi máy chủ tiếp theo khởi động lại. Số lượng các phiên bản bảng có siêu dữ liệu được lưu trong bộ nhớ đệm có thể cao hơn giới hạn được xác định bởi table_definition_cache, vì các phiên bản bảng mẹ và con có mối quan hệ khóa ngoại không được đặt trong danh sách LRU và không bị loại bỏ khỏi bộ nhớ.
Không giống như table_open_cache, table_definition_cache không sử dụng bộ mô tả tệp và nhỏ hơn nhiều.
Xử lý bộ nhớ cache truy vấn
Tốt hơn là chúng tôi khuyên bạn nên tắt bộ nhớ cache truy vấn trong tất cả thiết lập MariaDB của mình. Bạn cần đảm bảo rằng query_cache_type =OFF và query_cache_size =0 để hoàn thành việc vô hiệu hóa bộ đệm truy vấn. Không giống như MySQL, MariaDB vẫn đang hỗ trợ hoàn toàn bộ đệm truy vấn và không có bất kỳ kế hoạch nào về việc rút hỗ trợ của mình để sử dụng bộ đệm truy vấn. Có một số người tuyên bố rằng bộ nhớ cache truy vấn vẫn mang lại lợi ích về hiệu suất cho họ. Tuy nhiên, bài đăng này từ Percona Bộ đệm truy vấn MySQL:Kẻ thù tồi tệ nhất hoặc người bạn tốt nhất tiết lộ rằng bộ đệm truy vấn, nếu được bật, dẫn đến có chi phí cao và cho thấy có hiệu suất máy chủ kém.
Nếu bạn định sử dụng bộ đệm truy vấn, hãy đảm bảo rằng bạn theo dõi bộ đệm truy vấn của mình bằng cách chạy HIỂN THỊ TRẠNG THÁI TOÀN CẦU 'Qcache%';. Qcache_inserts chứa số lượng truy vấn được thêm vào bộ đệm truy vấn, Qcache_hits chứa số lượng truy vấn đã sử dụng bộ đệm truy vấn, trong khi Qcache_lowmem_prunes chứa số lượng truy vấn đã bị xóa khỏi bộ đệm do thiếu bộ nhớ. Trong khi đến hạn, việc sử dụng và bật bộ nhớ cache truy vấn có thể bị phân mảnh. Qcache_free_blocks cao so với Qcache_total_blocks có thể chỉ ra sự phân mảnh. Để chống phân mảnh nó, hãy chạy FLUSH QUERY CACHE. Điều này sẽ chống phân mảnh bộ nhớ cache truy vấn mà không bỏ bất kỳ truy vấn nào.
Luôn theo dõi Máy chủ của bạn
Điều quan trọng là bạn phải theo dõi đúng các nút MariaDB của mình. Các công cụ giám sát phổ biến hiện có (như Nagios, Zabbix hoặc PMM) đều có sẵn nếu bạn có xu hướng thích các công cụ miễn phí và mã nguồn mở. Đối với các công cụ dành cho doanh nghiệp và được đóng gói đầy đủ, chúng tôi khuyên bạn nên dùng thử ClusterControl, vì nó không chỉ cung cấp khả năng giám sát mà còn cung cấp các cố vấn hiệu suất, cảnh báo và cảnh báo giúp bạn cải thiện hiệu suất hệ thống và luôn cập nhật các xu hướng khi bạn tham gia với Nhóm hỗ trợ. Giám sát cơ sở dữ liệu với ClusterControl miễn phí và là một phần của Phiên bản Cộng đồng.
Kết luận
Điều chỉnh thiết lập MariaDB của bạn gần giống như cách tiếp cận của MySQL, nhưng có một số điểm khác biệt, vì nó khác nhau ở một số cách tiếp cận và phiên bản mà nó hỗ trợ. MariaDB hiện là một thực thể khác trong thế giới cơ sở dữ liệu và đã nhanh chóng nhận được sự tin tưởng của cộng đồng mà không cần bất kỳ FUD nào. Họ có lý do riêng tại sao nó phải được triển khai theo cách này, vì vậy điều rất quan trọng là chúng tôi phải biết cách điều chỉnh điều này và tối ưu hóa (các) máy chủ MariaDB của bạn.
