State Snapshot Transfer (SST) là một trong hai cách được Galera sử dụng để thực hiện đồng bộ hóa ban đầu khi một nút đang tham gia một cụm, cho đến khi nút được khai báo là đã đồng bộ hóa và là một phần của “thành phần chính”. Tùy thuộc vào kích thước tập dữ liệu và khối lượng công việc, SST có thể nhanh như chớp hoặc một hoạt động tốn kém sẽ khiến dịch vụ cơ sở dữ liệu của bạn không hoạt động.
SST có thể được thực hiện bằng 3 phương pháp khác nhau:
- mysqldump
- rsync (hoặc rsync_wan)
- xtrabackup (hoặc xtrabackup-v2, mariabackup)
Hầu hết thời gian, xtrabackup-v2 và mariabackup là những lựa chọn ưu tiên. Chúng tôi hiếm khi thấy mọi người chạy trên rsync hoặc mysqldump trong các cụm sản xuất.
Vấn đề
Khi SST được bắt đầu, có một số quy trình được kích hoạt trên nút kết hợp, được thực thi bởi người dùng "mysql":
$ ps -fu mysql
UID PID PPID C STIME TTY TIME CMD
mysql 117814 129515 0 13:06 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.173:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir
mysql 120036 117814 15 13:06 ? 00:00:06 innobackupex --no-version-check --tmpdir=/tmp/tmp.pMmzIlZJwa --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-inf
mysql 120037 117814 19 13:06 ? 00:00:07 socat -u stdio TCP:192.168.55.173:4444
mysql 129515 1 1 Oct27 ? 01:11:46 /usr/sbin/mysqld --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:4949331Trong khi ở nút nhà tài trợ:
mysql 43733 1 14 Oct16 ? 03:28:47 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:272891
mysql 87092 43733 0 14:53 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.172:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir /var/lib/mysql/ --gtid 7ce0e31f-aa46-11e7-abda-56d6a5318485:2883115 --gtid-domain-id 0
mysql 88826 87092 30 14:53 ? 00:00:05 innobackupex --no-version-check --tmpdir=/tmp/tmp.LDdWzbHkkW --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-info --stream=xbstream /tmp/tmp.oXDumYf392
mysql 88827 87092 30 14:53 ? 00:00:05 socat -u stdio TCP:192.168.55.172:4444SST đối với một tập dữ liệu lớn (hàng trăm GByte) không phải là điều thú vị. Tùy thuộc vào phần cứng, mạng và khối lượng công việc, có thể mất hàng giờ để hoàn thành. Tài nguyên máy chủ có thể bị bão hòa trong quá trình hoạt động. Mặc dù điều chỉnh được hỗ trợ trong SST (chỉ dành cho xtrabackup và mariabackup) bằng cách sử dụng các tùy chọn --rlimit và --use-memory, chúng tôi vẫn gặp phải một cụm bị suy giảm khi bạn sử dụng hết phần lớn các nút đang hoạt động. Ví dụ, nếu bạn không may mắn thấy mình chỉ có một trong ba nút đang chạy. Do đó, bạn nên thực hiện SST trong những giờ yên tĩnh. Tuy nhiên, bạn có thể tránh SST bằng cách thực hiện một số bước thủ công, như được mô tả trong bài đăng trên blog này.
Dừng SST
Việc dừng một SST cần phải được thực hiện trên cả nút của nhà tài trợ và nút kết hợp. Trình kết hợp kích hoạt SST sau khi xác định khoảng cách chênh lệch lớn như thế nào khi so sánh seqno Galera cục bộ với seqno của cụm. Nó thực thi wsrep_sst_ {wsrep_sst_method} yêu cầu. Điều này sẽ được chọn bởi nhà tài trợ đã chọn, điều này sẽ bắt đầu truyền dữ liệu đến trình kết hợp. Nút nhà tài trợ không có khả năng từ chối phân phát chuyển ảnh chụp nhanh, sau khi được lựa chọn bởi liên lạc nhóm Galera hoặc theo giá trị được xác định trong wsrep_sst_donor Biến đổi. Khi quá trình đồng bộ hóa đã bắt đầu và bạn muốn hoàn nguyên quyết định, không có lệnh nào để dừng hoạt động.
Nguyên tắc cơ bản khi dừng SST là:
- Làm cho người tham gia trông giống như chết từ quan điểm giao tiếp của nhóm Galera (tắt, hàng rào, chặn, đặt lại, rút cáp, danh sách đen, v.v.)
- Loại bỏ các quy trình SST đối với nhà tài trợ
Người ta sẽ nghĩ rằng việc giết quá trình innobackupex (kill -9 {innobackupex PID}) trên người hiến tặng là đủ, nhưng không phải vậy. Nếu bạn hủy các quy trình SST trên nhà tài trợ (hoặc trình tham gia) mà không rào cản trình kết hợp, Galera vẫn có thể thấy trình kết hợp đang hoạt động và sẽ đánh dấu quy trình SST là chưa hoàn thành, do đó sẽ tạo lại một tập hợp quy trình mới để tiếp tục hoặc bắt đầu lại. Bạn sẽ trở lại hình vuông một. Đây là hành vi dự kiến của tập lệnh / usr / bin / wsrep_sst_ {method} để bảo vệ hoạt động SST dễ bị hết thời gian chờ (ví dụ:nếu nó hoạt động lâu dài và tốn nhiều tài nguyên).
Hãy xem một ví dụ. Chúng tôi có một nút kết hợp bị lỗi mà chúng tôi muốn tham gia lại vào cụm. Chúng tôi sẽ bắt đầu bằng cách chạy lệnh sau trên trình kết hợp:
$ systemctl start mysql # or service mysql startMột phút sau, chúng tôi phát hiện ra rằng hoạt động quá nặng vào thời điểm cụ thể đó và quyết định hoãn lại sau trong giờ giao thông thấp. Cách đơn giản nhất để dừng phương pháp SST dựa trên xtrabackup là chỉ cần tắt nút kết hợp và hủy các quy trình liên quan đến SST trên nút của nhà tài trợ. Ngoài ra, bạn cũng có thể chặn các cổng đến trên trình kết hợp bằng cách chạy lệnh iptables sau trên trình kết hợp:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPSau đó, trên nhà tài trợ, truy xuất PID của các quy trình SST (liệt kê các quy trình do người dùng "mysql" sở hữu):
$ ps -u mysql
PID TTY TIME CMD
117814 ? 00:00:00 wsrep_sst_xtrab
120036 ? 00:00:06 innobackupex
120037 ? 00:00:07 socat
129515 ? 01:11:47 mysqldCuối cùng, giết tất cả chúng ngoại trừ tiến trình mysqld (bạn phải cực kỳ cẩn thận để KHÔNG giết tiến trình mysqld đối với người hiến tặng!):
$ kill -9 117814 120036 120037Sau đó, trên nhật ký lỗi MySQL của nhà tài trợ, bạn sẽ nhận thấy dòng sau xuất hiện sau ~ 100 giây:
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: Could not find peer: 42b85e82-bd32-11e7-87ae-eff2b8dd2ea0
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: 1.0 (192.168.55.172): State transfer to -1.-1 (left the group) failed: -32 (Broken pipe)Tại thời điểm này, nhà tài trợ sẽ trở lại trạng thái "đã đồng bộ hóa" như được báo cáo bởi wsrep_local_state_comment và quá trình SST hoàn toàn bị dừng lại. Nhà tài trợ đã trở lại trạng thái hoạt động và có thể phục vụ khách hàng hết công suất.
Đối với quá trình dọn dẹp trên trình kết hợp, bạn có thể chỉ cần xóa chuỗi iptables:
$ iptables -FHoặc chỉ cần xóa các quy tắc với cờ -D:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPCách tiếp cận tương tự có thể được sử dụng với các phương pháp SST khác như rsync, mariabackup và mysqldump.
Điều chỉnh một SST (chỉ phương pháp xtrabackup)
Tùy thuộc vào mức độ bận rộn của nhà tài trợ, đó là một cách tiếp cận tốt để điều chỉnh quy trình thuế TTĐB để nó không ảnh hưởng đáng kể đến nhà tài trợ. Chúng tôi đã thấy một số trường hợp trong đó, trong những lần thất bại thảm hại, người dùng đã cố gắng mang lại một cụm bị lỗi dưới dạng một nút khởi động duy nhất và để các thành viên còn lại bắt kịp sau. Nỗ lực này làm giảm thời gian chết từ phía ứng dụng, tuy nhiên, nó tạo thêm gánh nặng cho “cụm một nút” này, trong khi các thành viên còn lại vẫn đang ngừng hoạt động hoặc đang phục hồi.
Xtrabackup có thể được điều chỉnh bằng --throttle =
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Thêm chi tiết trên trang tài liệu Percona Xtrabackup SST.
Tuy nhiên, có một nhược điểm. Quá trình này có thể chậm đến mức nó sẽ không bao giờ bắt kịp nhật ký giao dịch mà InnoDB đang viết, vì vậy SST có thể không bao giờ hoàn thành. Nói chung, tình huống này rất hiếm gặp, trừ khi bạn thực sự có một khối lượng công việc cần viết rất nhiều hoặc bạn phân bổ các nguồn lực rất hạn chế cho SST.
Kết luận
SST là quan trọng nhưng nặng và có thể là một hoạt động lâu dài tùy thuộc vào kích thước tập dữ liệu và thông lượng mạng giữa các nút. Bất kể hậu quả là gì, vẫn có khả năng dừng hoạt động để chúng tôi có thể có kế hoạch khôi phục tốt hơn vào thời điểm tốt hơn.
