Trong phần đầu tiên của blog này, chúng tôi đã cung cấp thông tin tổng quan về tính năng sao chép luồng mới trong MySQL Galera Cluster. Trong blog này, chúng tôi sẽ hướng dẫn bạn cách kích hoạt nó và xem kết quả.
Bật tính năng Sao chép Truyền trực tuyến
Bạn nên bật tính năng Sao chép trực tuyến ở cấp phiên cho các giao dịch cụ thể tương tác với ứng dụng / khách hàng của bạn.
Như đã nêu trong blog trước, Galera ghi các bộ ghi của nó vào bảng wsrep_streaming_log trong cơ sở dữ liệu MySQL. Điều này có khả năng tạo ra tắc nghẽn hiệu suất, đặc biệt là khi cần khôi phục. Điều này không có nghĩa là bạn không thể sử dụng Streaming Replication, nó chỉ có nghĩa là bạn cần thiết kế ứng dụng khách của mình một cách hiệu quả khi sử dụng Streaming Replication để bạn có được hiệu suất tốt hơn. Tuy nhiên, tốt nhất bạn nên có Streaming Replication để xử lý và cắt giảm các giao dịch lớn.
Bật tính năng Sao chép Truyền trực tuyến yêu cầu bạn xác định đơn vị sao chép và số lượng đơn vị để sử dụng trong việc hình thành các phân đoạn giao dịch. Hai tham số kiểm soát các biến này:wsrep_trx_fragment_unit và wsrep_trx_fragment_size.
Dưới đây là ví dụ về cách đặt hai tham số này:
SET SESSION wsrep_trx_fragment_unit='statements';
SET SESSION wsrep_trx_fragment_size=3;Trong ví dụ này, phân đoạn được đặt thành ba câu lệnh. Đối với mỗi ba câu lệnh từ một giao dịch, nút sẽ tạo, sao chép và xác nhận một đoạn.
Bạn có thể chọn giữa một vài đơn vị sao chép khi tạo các đoạn:
- byte - Điều này xác định kích thước phân mảnh tính bằng byte.
- hàng - Điều này xác định kích thước phân mảnh là số hàng mà phân mảnh cập nhật.
- tuyên bố - Điều này xác định kích thước phân mảnh là số lượng câu lệnh trong một phân mảnh.
Chọn đơn vị sao chép và kích thước phân mảnh phù hợp nhất với hoạt động cụ thể mà bạn muốn chạy.
Truyền trực tuyến Nhân rộng Đang thực hiện
Như đã thảo luận trong blog khác của chúng tôi về việc xử lý các giao dịch lớn trong Mariadb 10.4, chúng tôi đã thực hiện và thử nghiệm xem tính năng Sao chép trực tuyến hoạt động như thế nào khi được bật dựa trên tiêu chí này ...
- Đường cơ sở, đặt wsrep_trx_fragment_size =0 toàn cầu;
- set global wsrep_trx_fragment_unit ='row'; đặt toàn cầu wsrep_trx_fragment_size =1;
- set global wsrep_trx_fragment_unit ='statement'; đặt toàn cầu wsrep_trx_fragment_size =1;
- set global wsrep_trx_fragment_unit ='statement'; đặt toàn cầu wsrep_trx_fragment_size =5;
Và kết quả là
Transactions: 82.91 per sec., queries: 1658.27 per sec. (100%)
Transactions: 54.72 per sec., queries: 1094.43 per sec. (66%)
Transactions: 54.76 per sec., queries: 1095.18 per sec. (66%)
Transactions: 70.93 per sec., queries: 1418.55 per sec. (86%)Đối với ví dụ này, chúng tôi đang sử dụng Percona XtraDB Cluster 8.0.15 ngay từ nhánh thử nghiệm của họ bằng cách sử dụng Percona-XtraDB-Cluster_8.0.15.5-27dev.4.2_Linux.x86_64.ssl102.tar.gz xây dựng.
Sau đó, chúng tôi đã thử một cụm Galera 3 nút với thông tin máy chủ bên dưới:
testnode11 = 192.168.10.110
testnode12 = 192.168.10.120
testnode13 = 192.168.10.130Chúng tôi đã điền trước một bảng từ cơ sở dữ liệu sysbench của mình và cố gắng xóa một hàng rất lớn.
[email protected][sbtest]#> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 12608218 |
+----------+
1 row in set (25.55 sec)Lúc đầu, chạy mà không có tính năng Sao chép Truyền trực tuyến,
[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;
+---------------------------+---------------------------+----------------------------+
| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |
+---------------------------+---------------------------+----------------------------+
| bytes | 0 | 50000 |
+---------------------------+---------------------------+----------------------------+
1 row in set (0.00 sec)Sau đó chạy,
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;Tuy nhiên, cuối cùng chúng tôi đã nhận được một lần khôi phục ...
---TRANSACTION 648910, ACTIVE 573 sec rollback
mysql tables in use 1, locked 1
ROLLING BACK 164858 lock struct(s), heap size 18637008, 12199395 row lock(s), undo log entries 11961589
MySQL thread id 183, OS thread handle 140041167468288, query id 79286 localhost 127.0.0.1 root wsrep: replicating and certifying write set(-1)
delete from sbtest1 where id >= 2000000Sử dụng Bảng điều khiển ClusterControl để thu thập tổng quan về bất kỳ dấu hiệu nào về kiểm soát luồng, vì giao dịch chỉ chạy trên nút chính (người viết hoạt động) cho đến thời điểm cam kết, không có bất kỳ dấu hiệu nào về hoạt động đối với kiểm soát luồng:
Trong trường hợp bạn đang thắc mắc, phiên bản hiện tại của ClusterControl chưa có hỗ trợ trực tiếp cho PXC 8.0 với Galera Cluster 4 (vì nó vẫn đang trong giai đoạn thử nghiệm). Tuy nhiên, bạn có thể cố gắng nhập nó ... nhưng nó cần những chỉnh sửa nhỏ để làm cho Trang tổng quan của bạn hoạt động chính xác.
Quay lại quá trình truy vấn. Nó không thành công khi nó quay trở lại!
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;
ERROR 1180 (HY000): Got error 5 - 'Transaction size exceed set threshold' during COMMITbất kể wsrep_max_ws_rows hay wsrep_max_ws_size,
[email protected][sbtest]#> select @@global.wsrep_max_ws_rows, @@global.wsrep_max_ws_size/(1024*1024*1024);
+----------------------------+---------------------------------------------+
| @@global.wsrep_max_ws_rows | @@global.wsrep_max_ws_size/(1024*1024*1024) |
+----------------------------+---------------------------------------------+
| 0 | 2.0000 |
+----------------------------+---------------------------------------------+
1 row in set (0.00 sec)Cuối cùng, nó đã đạt đến ngưỡng.
Trong thời gian này, bảng hệ thống mysql.wsrep_streaming_log trống, điều này cho biết rằng tính năng Sao chép trực tuyến đang không xảy ra hoặc được bật,
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.01 sec)
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)và điều đó được xác minh trên 2 nút khác (testnode12 và testnode13).
Bây giờ, hãy thử bật tính năng này với tính năng Sao chép trực tuyến,
[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;
+---------------------------+---------------------------+----------------------------+
| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |
+---------------------------+---------------------------+----------------------------+
| bytes | 0 | 50000 |
+---------------------------+---------------------------+----------------------------+
1 row in set (0.00 sec)
[email protected][sbtest]#> set wsrep_trx_fragment_unit='rows'; set wsrep_trx_fragment_size=100;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;
+---------------------------+---------------------------+----------------------------+
| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |
+---------------------------+---------------------------+----------------------------+
| rows | 100 | 50000 |
+---------------------------+---------------------------+----------------------------+
1 row in set (0.00 sec)Điều gì sẽ xảy ra khi Nhân rộng Truyền trực tuyến Cụm Galera được Kích hoạt?
Khi truy vấn được thực hiện trong testnode11,
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;Điều xảy ra là nó phân mảnh từng phần giao dịch tùy thuộc vào giá trị đặt của biến wsrep_trx_fragment_size. Hãy kiểm tra điều này trong các nút khác:
Máy chủ testnode12
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p''
TRANSACTIONS
------------
Trx id counter 567148
Purge done for trx's n:o < 566636 undo n:o < 0 state: running but idle
History list length 44
LIST OF TRANSACTIONS FOR EACH SESSION:
..
...
---TRANSACTION 421740651985200, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 553661, ACTIVE 190 sec
18393 lock struct(s), heap size 2089168, 1342600 row lock(s), undo log entries 1342600
MySQL thread id 898, OS thread handle 140266050008832, query id 216824 wsrep: applied write set (-1)
--------
FILE I/O
1 row in set (0.08 sec)
PAGER set to stdout
+----------------------------------+--------------+
| Variable_name | Value |
+----------------------------------+--------------+
| wsrep_flow_control_paused_ns | 211197844753 |
| wsrep_flow_control_paused | 0.133786 |
| wsrep_flow_control_sent | 633 |
| wsrep_flow_control_recv | 878 |
| wsrep_flow_control_interval | [ 173, 173 ] |
| wsrep_flow_control_interval_low | 173 |
| wsrep_flow_control_interval_high | 173 |
| wsrep_flow_control_status | OFF |
+----------------------------------+--------------+
8 rows in set (0.00 sec)
+----------+
| count(*) |
+----------+
| 13429 |
+----------+
1 row in set (0.04 sec)
Máy chủ testnode13
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p''
TRANSACTIONS
------------
Trx id counter 568523
Purge done for trx's n:o < 567824 undo n:o < 0 state: running but idle
History list length 23
LIST OF TRANSACTIONS FOR EACH SESSION:
..
...
---TRANSACTION 552701, ACTIVE 216 sec
21587 lock struct(s), heap size 2449616, 1575700 row lock(s), undo log entries 1575700
MySQL thread id 936, OS thread handle 140188019226368, query id 600980 wsrep: applied write set (-1)
--------
FILE I/O
1 row in set (0.28 sec)
PAGER set to stdout
+----------------------------------+--------------+
| Variable_name | Value |
+----------------------------------+--------------+
| wsrep_flow_control_paused_ns | 210755642443 |
| wsrep_flow_control_paused | 0.0231273 |
| wsrep_flow_control_sent | 1653 |
| wsrep_flow_control_recv | 3857 |
| wsrep_flow_control_interval | [ 173, 173 ] |
| wsrep_flow_control_interval_low | 173 |
| wsrep_flow_control_interval_high | 173 |
| wsrep_flow_control_status | OFF |
+----------------------------------+--------------+
8 rows in set (0.01 sec)
+----------+
| count(*) |
+----------+
| 15758 |
+----------+
1 row in set (0.03 sec)Đáng chú ý, điều khiển luồng vừa được khởi động!
Và hàng đợi WSREP gửi / nhận cũng đang hoạt động:
Máy chủ testnode12 (192.168.10.120) 
Máy chủ testnode13 (192.168.10.130) Bây giờ, hãy trình bày thêm về kết quả từ bảng mysql.wsrep_streaming_log,
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8; show engine innodb status\G nopager;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8'
MySQL thread id 134822, OS thread handle 140041167468288, query id 0 System lock
---TRANSACTION 649008, ACTIVE 481 sec
mysql tables in use 1, locked 1
53104 lock struct(s), heap size 6004944, 3929602 row lock(s), undo log entries 3876500
MySQL thread id 183, OS thread handle 140041167468288, query id 105367 localhost 127.0.0.1 root updating
delete from sbtest1 where id >= 2000000
--------
FILE I/O
1 row in set (0.01 sec)sau đó lấy kết quả là,
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 38899 |
+----------+
1 row in set (0.40 sec)Nó cho biết có bao nhiêu phân mảnh đã được sao chép bằng cách sử dụng tính năng Streaming Replication. Bây giờ, chúng ta hãy làm một số phép toán cơ bản:
[email protected][sbtest]#> select 3876500/38899.0;
+-----------------+
| 3876500/38899.0 |
+-----------------+
| 99.6555 |
+-----------------+
1 row in set (0.03 sec)Tôi đang hoàn tác các mục nhập nhật ký từ kết quả SHOW ENGINE INNODB STATUS \ G và sau đó chia tổng số bản ghi mysql.wsrep_streaming_log. Như tôi đã đặt trước đó, tôi đã xác định wsrep_trx_fragment_size =100. Kết quả sẽ cho bạn biết tổng số nhật ký sao chép hiện đang được Galera xử lý.
Điều quan trọng cần lưu ý là tính năng Sao chép trực tuyến đang cố gắng đạt được ... "nút chia giao dịch thành các đoạn, sau đó xác nhận và sao chép chúng trên các nô lệ trong khi giao dịch vẫn ở trong tiến độ. Sau khi được chứng nhận, phân đoạn không còn có thể bị hủy bỏ bởi các giao dịch xung đột. "
Các phân đoạn được coi là các giao dịch, đã được chuyển đến các nút còn lại trong cụm, xác nhận giao dịch bị phân mảnh, sau đó áp dụng các bộ ghi. Điều này có nghĩa là khi giao dịch lớn của bạn đã được chứng nhận hoặc được ưu tiên, tất cả các kết nối đến có thể có bế tắc sẽ cần phải đợi cho đến khi giao dịch kết thúc.
Bây giờ, phán quyết của việc xóa một bảng lớn?
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;
Query OK, 12034538 rows affected (30 min 36.96 sec)Nó kết thúc thành công mà không gặp bất kỳ lỗi nào!
Nó trông như thế nào trong các nút khác? Trong testnode12,
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8'
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421740651985200, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 553661, ACTIVE (PREPARED) 2050 sec
165631 lock struct(s), heap size 18735312, 12154883 row lock(s), undo log entries 12154883
MySQL thread id 898, OS thread handle 140266050008832, query id 341835 wsrep: preparing to commit write set(215510)
--------
FILE I/O
1 row in set (0.46 sec)
PAGER set to stdout
+----------------------------------+--------------+
| Variable_name | Value |
+----------------------------------+--------------+
| wsrep_flow_control_paused_ns | 290832524304 |
| wsrep_flow_control_paused | 0 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_flow_control_interval | [ 173, 173 ] |
| wsrep_flow_control_interval_low | 173 |
| wsrep_flow_control_interval_high | 173 |
| wsrep_flow_control_status | OFF |
+----------------------------------+--------------+
8 rows in set (0.53 sec)
+----------+
| count(*) |
+----------+
| 120345 |
+----------+
1 row in set (0.88 sec)Nó dừng lại ở tổng số 120345 mảnh và nếu chúng tôi thực hiện lại phép toán trên các mục nhập nhật ký hoàn tác đã chụp gần đây nhất (các nhật ký hoàn tác cũng giống như nhật ký chính),
[email protected][sbtest]#> select 12154883/120345.0; +-------------------+
| 12154883/120345.0 |
+-------------------+
| 101.0003 |
+-------------------+
1 row in set (0.00 sec)Vì vậy, chúng tôi có tổng cộng 120345 giao dịch bị phân mảnh để xóa 12034538 hàng.
Sau khi bạn sử dụng xong hoặc bật tính năng Sao chép luồng, đừng quên tắt tính năng này vì nó sẽ luôn ghi lại các giao dịch lớn và thêm nhiều chi phí hiệu suất vào cụm của bạn. Để tắt nó, chỉ cần chạy
[email protected][sbtest]#> set wsrep_trx_fragment_size=0;
Query OK, 0 rows affected (0.04 sec)Kết luận
Khi bật tính năng Sao chép trực tuyến, điều quan trọng là bạn có thể xác định kích thước phân mảnh của mình có thể lớn đến mức nào và bạn phải chọn đơn vị nào (byte, hàng, câu lệnh).
Điều rất quan trọng là bạn cần chạy nó ở cấp phiên và tất nhiên xác định khi nào bạn chỉ cần sử dụng Streaming Replication.
Trong khi thực hiện các bài kiểm tra này, việc xóa một số lượng lớn các hàng trong một bảng lớn có bật tính năng Streaming Replication đã gây ra mức sử dụng đĩa và CPU cao nhất. RAM ổn định hơn, nhưng điều này có thể do tuyên bố chúng tôi thực hiện không phải là một tranh chấp bộ nhớ cao.
Có thể nói rằng tính năng Sao chép trực tuyến có thể gây ra tắc nghẽn hiệu suất khi xử lý các bản ghi lớn, vì vậy việc sử dụng nó cần được thực hiện một cách thận trọng và có quyết định phù hợp.
Cuối cùng, nếu bạn đang sử dụng Streaming Replication, đừng quên luôn tắt tính năng này sau khi thực hiện xong trên phiên hiện tại đó để tránh các sự cố không mong muốn.
