Nội dung của công cụ lưu trữ BỘ NHỚ [trước đây gọi là HEAP] được lưu trữ trong bộ nhớ chứ không phải trên đĩa
Nó được sử dụng tốt nhất cho bộ đệm chỉ đọc dữ liệu từ các bảng khác hoặc cho các khu vực làm việc tạm thời
Vì dữ liệu được lưu trữ trong bộ nhớ nên rất dễ bị mất điện hoặc lỗi phần cứng và không phù hợp để lưu trữ dữ liệu vĩnh viễn. Trên thực tế, sau khi máy chủ khởi động lại, các bảng MEMORY
sẽ được tạo lại [vì tệp định nghĩa được lưu trên đĩa], nhưng chúng sẽ trống. Có thể điền lại chúng bằng một truy vấn bằng cách sử dụng tùy chọn khởi động máy chủ --init-file
Các loại độ dài thay đổi như VARCHAR có thể được sử dụng trong các bảng BỘ NHỚ. Các cột BLOB hoặc TEXT không được hỗ trợ cho các bảng MEMORY
Sử dụng bộ nhớ
Tổng kích thước tối đa của các bảng BỘ NHỚ không thể vượt quá biến máy chủ hệ thống. Khi một bảng được tạo, giá trị này sẽ áp dụng cho bảng đó và khi khởi động lại máy chủ, giá trị này sẽ áp dụng cho các bảng hiện có. Việc thay đổi giá trị này không ảnh hưởng đến các bảng hiện có. Tuy nhiên, thực hiện một câu lệnh ALTER TABLE .. ENGINE=MEMORY
áp dụng giá trị hiện tại của max_heap_table_size
cho bảng. Ngoài ra, có thể thay đổi giá trị phiên của max_heap_table_size
trước khi tạo bảng, để đảm bảo rằng các bảng được tạo bởi các phiên khác không bị ảnh hưởng
Tùy chọn bảng MAX_ROWS
cung cấp gợi ý về số lượng hàng bạn dự định lưu trữ trong đó. Đây không phải là giới hạn cứng không thể vượt quá và không cho phép vượt quá max_heap_table_size
. Công cụ lưu trữ sử dụng max_heap_table_size và MAX_ROWS để tính toán bộ nhớ tối đa có thể được phân bổ cho bảng
Bộ nhớ được phân bổ cho bảng MEMORY được giải phóng bằng cách chạy DROP TABLE hoặc TRUNCATE TABLE hoặc xây dựng lại bằng ALTER TABLE tbl_name ENGINE = MEMORY. Khi các hàng bị xóa, không gian sẽ không tự động được giải phóng
Loại chỉ mục
Công cụ lưu trữ BỘ NHỚ cho phép các chỉ mục là B-tree hoặc Hash. Băm là loại mặc định cho BỘ NHỚ. Xem các loại chỉ mục Công cụ lưu trữ để biết thêm về đặc điểm của chúng
Một bảng NHỚ có thể có tối đa 64 chỉ mục, 16 cột cho mỗi chỉ mục và độ dài khóa tối đa là 3072 byte
Các bảng MEMORY bị mất khi máy chủ khởi động lại. Để đạt được kết quả này trong quá trình sao chép, lần đầu tiên một bản chính sử dụng bảng BỘ NHỚ sau khi khởi động lại, nó ghi một câu lệnh XÓA cho bảng đó vào nhật ký nhị phân, để các bản sao cũng được làm trống
Thí dụ
Ví dụ sau đây cho thấy cách tạo bảng MEMORY
với kích thước tối đa nhất định, như được mô tả ở trên
Chúng ta đều biết về OOM [hết bộ nhớ], về mặt lý thuyết, đó là một quá trình mà Linux kernel employs when the system is critically low on memory.
Trong một máy chủ DB chuyên dụng, khi OOM kích hoạt, tác động trực tiếp sẽ đến quy trình mysqld vì nó sẽ là quy trình tiêu tốn nhiều bộ nhớ nhất
Trong tương lai sẽ xem xét phân tích chi tiết được thực hiện để giải quyết vấn đề OOM
môi trường cơ sở dữ liệu. -
- Dịch vụ – Cụm sao chép nhóm
- Nút cụm – 3
- Chế độ GR – Sơ cấp đơn
- Phiên bản MySQL – 5. 7. 24
- Lõi CPU – 4
- Bộ nhớ – 11G
- innodb_buffer_pool_size – 8G [72% RAM]
Phân tích. -
Chúng tôi chỉ gặp sự cố này ở nút Chính GR chứ không phải ở bất kỳ nút Phụ nào [ProxySQL đảm nhận việc cân bằng tải]. Cấp phát bộ nhớ giống nhau trên toàn cụm. Vì vậy, chúng tôi đã bắt đầu tìm hiểu sâu về việc sử dụng bộ nhớ trong nút chính. Tôi đang chia phân tích vấn đề bộ nhớ này thành 3 cấp độ
- Sử dụng bộ nhớ MySQL Engine [Innodb]
- Sử dụng bộ nhớ toàn cầu của MySQL
- Sử dụng bộ nhớ sao chép nhóm MySQL
1]. Sử dụng bộ nhớ MySQL Engine [Innodb]. -
Sao chép nhóm chỉ hỗ trợ công cụ InnoDB. Vì vậy, trong trường hợp của công cụ dựa trên giao dịch InnoDB, Bộ đệm chính là innodb_buffer_pool_size . Theo nguyên tắc thông thường, chúng ta có thể đặt nó ở mức 70-80% bộ nhớ hệ thống. Tùy thuộc vào cấu hình máy chủ, Vì vậy, ở đây chúng tôi đã đặt khoảng 70% RAM cho Nhóm bộ đệm InnoDB. [mọi quy tắc đều có ngoại lệ].
Dưới đây tôi đã chia sẻ cách sử dụng bộ nhớ của InnoDB tại Linux Kernel
$ sudo pmap -x $[pidof mysqld] | grep -i anon . . . 00007f9d7dd3a000 8543680 6168996 6129452 rw--- [ anon ] . .
mydbops@localhost:performance_schema> select [8543680/1024/1024] as 'innodb memory utilisation in GB'; +---------------------------------+ | innodb memory utilization in GB | +---------------------------------+ | 8.14788818 | +---------------------------------+
2]. Sử dụng bộ nhớ toàn cầu. -
Việc sử dụng bộ nhớ bởi tất cả các sự kiện toàn cầu trong MySQL có thể được kiểm tra bằng cách sử dụng performance_schema. Điều này bao gồm việc sử dụng bộ nhớ bởi các sự kiện MySQL bên dưới
- Các sự kiện cho việc sử dụng bộ nhớ dựa trên công cụ [InnoDB, MyISAM, bộ nhớ, hố đen, temptable và các sự kiện khác. ]
- Sự kiện cho Lớp SQL [bộ nhớ/SQL]
- Các sự kiện cho việc sử dụng bộ nhớ giao tiếp máy khách-máy chủ [bộ nhớ/máy khách]
Để có được những sự kiện này, thiết bị bộ nhớ tương ứng trong performance_schema. bảng setup_instruments đã được bật
update performance_schema.setup_instruments set ENABLED = 'YES' where NAME like 'memory/%';
Sau khi kích hoạt các công cụ, chúng tôi có thể tìm nạp mức sử dụng bộ nhớ tại tất cả các sự kiện toàn cầu. Quan sát số liệu thống kê, người ta thấy rằng trung bình các sự kiện của họ chỉ chiếm 172 MB
mydbops@localhost:performance_schema> select [sum[current_number_of_bytes_used]]/1024/1024 'Global memory usage in MB' from memory_summary_global_by_event_name; +---------------------------+ | Global memory usage in MB | +---------------------------+ | 172.50711823 | +---------------------------+
Kết hợp, công cụ MySQL [Innodb] [ 8. 14GB] và mức sử dụng bộ nhớ sự kiện MySQL toàn cầu[tổng mức sử dụng 172MB] là khoảng 8. 3GB ở cấp độ MySQL
Nhưng khi chúng tôi quan sát Nhân Linux, tổng mức sử dụng bộ nhớ của quy trình MySQL là khoảng 10 GB
$ sudo pmap -x $[pidof mysqld] | tail -n 1 total kB 10395760
Vì vậy, bây giờ câu hỏi là,
- Trường hợp còn lại 1. 7GB được sử dụng?
- Quá trình nào bên trong MySQL đang tiêu thụ bộ nhớ này?
- Chúng tôi có các sự kiện trong Lược đồ hiệu suất để đo mức rò rỉ bộ nhớ này không?
Đây là đáp án, còn lại 1. 7GB được sử dụng bởi Bộ đệm sao chép nhóm. Hãy xem làm thế nào
3]. Sử dụng bộ nhớ sao chép nhóm. -
Thông thường trong Sao chép nhóm, nút chính sẽ ghi lại các sự kiện gần đây trong bộ nhớ cache. Sử dụng bộ đệm này, các nút khác sẽ nhận được chuyển trạng thái. Trong phiên bản MySQL 5. 7, không có biến để kiểm soát việc sử dụng bộ nhớ cache này, nó tăng theo cấp số nhân và nó cũng không có bất kỳ sự kiện nào để tính toán mức sử dụng bộ nhớ,
Vì hạn chế này, chúng tôi đã phải đối mặt với OOM trong MySQL 5. 7GR
Để khắc phục vấn đề này, XCOM Cache Management đã được giới thiệu từ MySQL 8. 0. 16. Từ phiên bản này, nơi chúng tôi có thể kiểm soát bộ đệm được sử dụng bởi Sao chép nhóm bằng cách sử dụng biến. Và MySQL cũng đã giới thiệu thêm một sự kiện với tên là 'GCS_XCom. xcom_cache‘. Bằng cách lấy thông tin chi tiết từ sự kiện này trong performance_schema. memory_summary_global_by_event_name, chúng ta có thể lấy mức tiêu thụ bộ nhớ của Bộ nhớ cache sao chép nhóm