Galera Cluster, với khả năng sao chép đồng bộ (hầu như), thường được sử dụng trong nhiều loại môi trường khác nhau. Mở rộng quy mô bằng cách thêm các nút mới không khó (hoặc đơn giản chỉ bằng một vài cú nhấp chuột khi bạn sử dụng ClusterControl).
Vấn đề chính của sao chép đồng bộ là, phần đồng bộ thường dẫn đến kết quả là toàn bộ cụm chỉ nhanh bằng nút chậm nhất của nó. Bất kỳ ghi nào được thực thi trên một cụm phải được sao chép tới tất cả các nút và được chứng nhận trên chúng. Nếu vì bất kỳ lý do gì, quá trình này bị chậm lại, nó có thể ảnh hưởng nghiêm trọng đến khả năng chứa các bài viết của cụm. Điều khiển luồng sau đó sẽ bắt đầu hoạt động, điều này nhằm đảm bảo rằng nút chậm nhất vẫn có thể theo kịp tải. Điều này làm cho nó khá phức tạp đối với một số tình huống phổ biến xảy ra trong môi trường thế giới thực.
Trước hết, hãy thảo luận về việc khắc phục thảm họa được phân bổ theo địa lý. Chắc chắn, bạn có thể chạy các cụm trên Mạng diện rộng, nhưng độ trễ tăng lên sẽ có tác động đáng kể đến hiệu suất của cụm. Điều này hạn chế nghiêm trọng khả năng sử dụng thiết lập như vậy, đặc biệt là trong khoảng cách xa hơn khi độ trễ cao hơn.
Một trường hợp sử dụng khá phổ biến khác - một môi trường thử nghiệm để nâng cấp phiên bản chính. Không phải là một ý kiến hay khi trộn các phiên bản khác nhau của các nút Cụm MariaDB Galera trong cùng một cụm, ngay cả khi có thể. Mặt khác, việc di chuyển sang phiên bản mới hơn yêu cầu các bài kiểm tra chi tiết. Lý tưởng nhất là cả hai lần đọc và viết đều đã được kiểm tra. Một cách để đạt được điều đó là tạo một cụm Galera riêng biệt và chạy các bài kiểm tra, nhưng bạn muốn chạy các bài kiểm tra trong một môi trường càng gần với quá trình sản xuất càng tốt. Sau khi được cấp phép, một cụm có thể được sử dụng cho các bài kiểm tra với các truy vấn trong thế giới thực nhưng sẽ khó tạo ra khối lượng công việc gần với khối lượng công việc của quá trình sản xuất. Bạn không thể di chuyển một số lưu lượng sản xuất sang hệ thống thử nghiệm như vậy, điều này là do dữ liệu không hiện tại.
Cuối cùng là sự di cư của chính nó. Một lần nữa, những gì chúng tôi đã nói trước đó, ngay cả khi có thể kết hợp các phiên bản cũ và mới của các nút Galera trong cùng một cụm, đó không phải là cách an toàn nhất để làm điều đó.
May mắn thay, giải pháp đơn giản nhất cho cả ba vấn đề đó là kết nối các cụm Galera riêng biệt với một bản sao không đồng bộ. Điều gì làm cho nó trở thành một giải pháp tốt như vậy? Chà, nó không đồng bộ nên không ảnh hưởng đến việc sao chép Galera. Không có điều khiển luồng, do đó hiệu suất của cụm “chủ” sẽ không bị ảnh hưởng bởi hiệu suất của cụm “phụ”. Như với mọi bản sao không đồng bộ, độ trễ có thể xuất hiện, nhưng miễn là nó nằm trong giới hạn chấp nhận được, nó có thể hoạt động hoàn toàn tốt. Bạn cũng phải nhớ rằng ngày nay sao chép không đồng bộ có thể được thực hiện song song (nhiều luồng có thể hoạt động cùng nhau để tăng băng thông) và giảm độ trễ sao chép hơn nữa.
Trong bài đăng trên blog này, chúng tôi sẽ thảo luận về các bước triển khai sao chép không đồng bộ giữa các cụm MariaDB Galera.
Cách định cấu hình sao chép không đồng bộ giữa các cụm MariaDB Galera?
Trước hết, chúng ta phải triển khai một cụm. Vì mục đích của chúng tôi, chúng tôi thiết lập một cụm ba nút. Chúng tôi sẽ giữ thiết lập ở mức tối thiểu, do đó chúng tôi sẽ không thảo luận về độ phức tạp của ứng dụng và lớp proxy. Lớp proxy có thể rất hữu ích để xử lý các tác vụ mà bạn muốn triển khai sao chép không đồng bộ - chuyển hướng một tập hợp con của lưu lượng truy cập chỉ đọc đến cụm kiểm tra, giúp trong tình huống khôi phục thảm họa khi cụm "chính" không khả dụng bằng cách chuyển hướng lưu lượng truy cập vào cụm DR. Có rất nhiều proxy bạn có thể thử, tùy thuộc vào sở thích của bạn - HAProxy, MaxScale hoặc ProxySQL - tất cả đều có thể được sử dụng trong các thiết lập như vậy và tùy trường hợp, một số proxy có thể giúp bạn quản lý lưu lượng truy cập của mình.
Định cấu hình Cụm nguồn
Cụm của chúng tôi bao gồm ba nút MariaDB 10.3, chúng tôi cũng đã triển khai ProxySQL để thực hiện phân tách đọc-ghi và phân phối lưu lượng trên tất cả các nút trong cụm. Đây không phải là một triển khai ở cấp độ sản xuất, vì vậy chúng tôi sẽ phải triển khai thêm các nút ProxySQL và một Keepalived ở trên chúng. Nó vẫn còn đủ cho các mục đích của chúng tôi. Để thiết lập sao chép không đồng bộ, chúng tôi sẽ phải kích hoạt nhật ký nhị phân trên cụm của chúng tôi. Ít nhất một nút nhưng tốt hơn nên bật nó trên tất cả chúng trong trường hợp nút duy nhất được bật binlog bị hỏng - khi đó bạn muốn có một nút khác trong cụm hoạt động mà bạn có thể tắt.
Khi bật nhật ký nhị phân, hãy đảm bảo rằng bạn định cấu hình xoay nhật ký nhị phân để các nhật ký cũ sẽ bị xóa tại một số điểm. Bạn sẽ sử dụng định dạng nhật ký nhị phân ROW. Bạn cũng nên đảm bảo rằng bạn đã cấu hình và sử dụng GTID - nó sẽ rất hữu ích khi bạn phải tạo lại cụm “nô lệ” của mình hoặc nếu bạn cần kích hoạt sao chép đa luồng. Vì đây là một cụm Galera, bạn muốn định cấu hình ‘wsrep_gtid_domain_id’ và bật ‘wsrep_gtid_mode’. Những cài đặt đó sẽ đảm bảo rằng GTID sẽ được tạo cho lưu lượng truy cập đến từ cụm Galera. Thông tin thêm có thể được tìm thấy trong tài liệu. Sau khi hoàn tất, bạn có thể tiếp tục thiết lập cụm thứ hai.
Thiết lập Cụm mục tiêu
Vì hiện tại không có cụm mục tiêu, chúng tôi phải bắt đầu với việc triển khai nó. Chúng tôi sẽ không trình bày chi tiết các bước đó, bạn có thể tìm thấy hướng dẫn trong tài liệu. Nói chung, quy trình bao gồm một số bước:
- Định cấu hình kho lưu trữ MariaDB
- Cài đặt gói MariaDB 10.3
- Định cấu hình các nút để tạo thành một cụm
Khi bắt đầu, chúng ta sẽ bắt đầu chỉ với một nút. Bạn có thể thiết lập tất cả chúng để tạo thành một cụm nhưng sau đó bạn nên dừng chúng lại và chỉ sử dụng một cho bước tiếp theo. Một nút đó sẽ trở thành nô lệ cho cụm ban đầu. Chúng tôi sẽ sử dụng mariabackup để cung cấp nó. Sau đó, chúng tôi sẽ cấu hình bản sao.
Đầu tiên, chúng ta phải tạo một thư mục nơi chúng ta sẽ lưu trữ bản sao lưu:
mkdir /mnt/mariabackupSau đó, chúng ta thực hiện sao lưu và tạo nó trong thư mục đã chuẩn bị ở bước trên. Hãy đảm bảo rằng bạn sử dụng đúng người dùng và mật khẩu để kết nối với cơ sở dữ liệu:
mariabackup --backup --user=root --password=pass --target-dir=/mnt/mariabackup/Tiếp theo, chúng ta phải sao chép các tệp sao lưu vào nút đầu tiên trong cụm thứ hai. Chúng tôi đã sử dụng scp cho điều đó, bạn có thể sử dụng bất kỳ thứ gì bạn thích - rsync, netcat, bất kỳ thứ gì sẽ hoạt động.
scp -r /mnt/mariabackup/* 10.0.0.104:/root/mariabackup/Sau khi sao lưu đã được sao chép, chúng tôi phải chuẩn bị nó bằng cách áp dụng các tệp nhật ký:
mariabackup --prepare --target-dir=/root/mariabackup/
mariabackup based on MariaDB server 10.3.16-MariaDB debian-linux-gnu (x86_64)
[00] 2019-06-24 08:35:39 cd to /root/mariabackup/
[00] 2019-06-24 08:35:39 This target seems to be not prepared yet.
[00] 2019-06-24 08:35:39 mariabackup: using the following InnoDB configuration for recovery:
[00] 2019-06-24 08:35:39 innodb_data_home_dir = .
[00] 2019-06-24 08:35:39 innodb_data_file_path = ibdata1:100M:autoextend
[00] 2019-06-24 08:35:39 innodb_log_group_home_dir = .
[00] 2019-06-24 08:35:39 InnoDB: Using Linux native AIO
[00] 2019-06-24 08:35:39 Starting InnoDB instance for recovery.
[00] 2019-06-24 08:35:39 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2019-06-24 8:35:39 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-06-24 8:35:39 0 [Note] InnoDB: Uses event mutexes
2019-06-24 8:35:39 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-06-24 8:35:39 0 [Note] InnoDB: Number of pools: 1
2019-06-24 8:35:39 0 [Note] InnoDB: Using SSE2 crc32 instructions
2019-06-24 8:35:39 0 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
2019-06-24 8:35:39 0 [Note] InnoDB: Completed initialization of buffer pool
2019-06-24 8:35:39 0 [Note] InnoDB: page_cleaner coordinator priority: -20
2019-06-24 8:35:39 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=3448619491
2019-06-24 8:35:40 0 [Note] InnoDB: Starting final batch to recover 759 pages from redo log.
2019-06-24 8:35:40 0 [Note] InnoDB: Last binlog file '/var/lib/mysql-binlog/binlog.000003', position 865364970
[00] 2019-06-24 08:35:40 Last binlog file /var/lib/mysql-binlog/binlog.000003, position 865364970
[00] 2019-06-24 08:35:40 mariabackup: Recovered WSREP position: e79a3494-964f-11e9-8a5c-53809a3c5017:25740
[00] 2019-06-24 08:35:41 completed OK!Trong trường hợp có bất kỳ lỗi nào, bạn có thể phải thực hiện lại bản sao lưu. Nếu mọi thứ đều ổn, chúng tôi có thể xóa dữ liệu cũ và thay thế bằng thông tin sao lưu
rm -rf /var/lib/mysql/*
mariabackup --copy-back --target-dir=/root/mariabackup/
…
[01] 2019-06-24 08:37:06 Copying ./sbtest/sbtest10.frm to /var/lib/mysql/sbtest/sbtest10.frm
[01] 2019-06-24 08:37:06 ...done
[00] 2019-06-24 08:37:06 completed OK!Chúng tôi cũng muốn đặt chủ sở hữu chính xác của tệp:
chown -R mysql.mysql /var/lib/mysql/Chúng tôi sẽ dựa vào GTID để giữ cho bản sao nhất quán, do đó chúng tôi cần xem GTID được áp dụng cuối cùng trong bản sao lưu này là gì. Thông tin đó có thể được tìm thấy trong tệp xtrabackup_info, một phần của bản sao lưu:
[email protected]:~/mariabackup# cat /var/lib/mysql/xtrabackup_info | grep binlog_pos
binlog_pos = filename 'binlog.000003', position '865364970', GTID of the last change '9999-1002-23012'Chúng tôi cũng sẽ phải đảm bảo rằng nút phụ đã bật nhật ký nhị phân cùng với ‘log_slave_updates’. Lý tưởng nhất, điều này sẽ được bật trên tất cả các nút trong cụm thứ hai - đề phòng trường hợp nút “nô lệ” bị lỗi và bạn sẽ phải thiết lập bản sao bằng cách sử dụng một nút khác trong cụm phụ.
Bước cuối cùng chúng ta cần làm trước khi có thể thiết lập bản sao là tạo một người dùng mà chúng ta sẽ sử dụng để chạy bản sao:
MariaDB [(none)]> CREATE USER 'repuser'@'10.0.0.104' IDENTIFIED BY 'reppass';
Query OK, 0 rows affected (0.077 sec)MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'repuser'@'10.0.0.104';
Query OK, 0 rows affected (0.012 sec)Đó là tất cả những gì chúng tôi cần. Bây giờ, chúng ta có thể bắt đầu nút đầu tiên trong cụm thứ hai, nút trở thành nô lệ của chúng ta:
galera_new_clusterSau khi bắt đầu, chúng tôi có thể nhập MySQL CLI và định cấu hình nó để trở thành nô lệ, sử dụng vị trí GITD mà chúng tôi đã tìm thấy trước đó vài bước:
mysql -ppassMariaDB [(none)]> SET GLOBAL gtid_slave_pos = '9999-1002-23012';
Query OK, 0 rows affected (0.026 sec)Sau khi hoàn tất, cuối cùng chúng ta có thể thiết lập bản sao và bắt đầu nó:
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_PORT=3306, MASTER_USER='repuser', MASTER_PASSWORD='reppass', MASTER_USE_GTID=slave_pos;
Query OK, 0 rows affected (0.016 sec)MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.010 sec)Tại thời điểm này, chúng ta có một Cụm Galera bao gồm một nút. Nút đó cũng là một nô lệ của cụm ban đầu (cụ thể, nút chính của nó là nút 10.0.0.101). Để tham gia các nút khác, chúng tôi sẽ sử dụng SST nhưng để làm cho nó hoạt động trước tiên chúng tôi phải đảm bảo rằng cấu hình SST là chính xác - xin lưu ý rằng chúng tôi vừa thay thế tất cả người dùng trong cụm thứ hai của chúng tôi bằng nội dung của cụm nguồn. Điều bạn phải làm bây giờ là đảm bảo rằng cấu hình ‘wsrep_sst_auth’ của cụm thứ hai khớp với cấu hình của cụm đầu tiên. Sau khi hoàn tất, bạn có thể bắt đầu từng nút còn lại và chúng sẽ tham gia vào nút hiện có (10.0.0.104), lấy dữ liệu qua SST và tạo thành cụm Galera. Cuối cùng, bạn sẽ kết thúc với hai cụm, mỗi cụm ba nút, với liên kết sao chép không đồng bộ giữa chúng (từ 10.0.0.101 đến 10.0.0.104 trong ví dụ của chúng tôi). Bạn có thể xác nhận rằng bản sao đang hoạt động bằng cách kiểm tra giá trị của:
MariaDB [(none)]> show global status like 'wsrep_last_committed';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| wsrep_last_committed | 106 |
+----------------------+-------+
1 row in set (0.001 sec)MariaDB [(none)]> show global status like 'wsrep_last_committed';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| wsrep_last_committed | 114 |
+----------------------+-------+
1 row in set (0.001 sec)Làm cách nào để định cấu hình sao chép không đồng bộ giữa các cụm MariaDB Galera bằng cách sử dụng ClusterControl?
Tính đến thời điểm của blog này, ClusterControl không có chức năng định cấu hình sao chép không đồng bộ trên nhiều cụm, chúng tôi đang làm việc trên nó khi tôi nhập điều này. Tuy nhiên, ClusterControl có thể giúp ích rất nhiều trong quá trình này - chúng tôi sẽ chỉ cho bạn cách bạn có thể tăng tốc các bước thủ công tốn kém bằng cách sử dụng tự động hóa do ClusterControl cung cấp.
Từ những gì chúng tôi đã trình bày trước đây, chúng tôi có thể kết luận rằng đó là các bước chung cần thực hiện khi thiết lập sao chép giữa hai cụm Galera:
- Triển khai một cụm Galera mới
- Cung cấp cụm mới bằng cách sử dụng dữ liệu từ cụm cũ
- Định cấu hình cụm mới (cấu hình SST, nhật ký nhị phân)
- Thiết lập bản sao giữa cụm cũ và mới
Ba điểm đầu tiên là điều bạn có thể dễ dàng thực hiện bằng ClusterControl ngay cả bây giờ. Chúng tôi sẽ hướng dẫn bạn cách thực hiện điều đó.
Triển khai và cung cấp một cụm MariaDB Galera mới bằng cách sử dụng ClusterControl
Tình huống ban đầu cũng tương tự - chúng tôi có một cụm đang hoạt động. Chúng ta phải thiết lập cái thứ hai. Một trong những tính năng gần đây hơn của ClusterControl là một tùy chọn để triển khai một cụm mới và cung cấp cho nó bằng cách sử dụng dữ liệu từ bản sao lưu. Điều này rất hữu ích để tạo môi trường thử nghiệm, nó cũng là một tùy chọn mà chúng tôi sẽ sử dụng để cung cấp cụm mới của chúng tôi cho quá trình thiết lập nhân rộng. Do đó, bước đầu tiên chúng ta sẽ thực hiện là tạo một bản sao lưu bằng mariabackup:
Ba bước trong đó chúng tôi chọn nút để xóa bản sao lưu. Nút này (10.0.0.101) sẽ trở thành một nút chính. Nó phải có nhật ký nhị phân được kích hoạt. Trong trường hợp của chúng tôi, tất cả các nút đã được kích hoạt binlog nhưng nếu chúng chưa được kích hoạt thì rất dễ dàng để kích hoạt nó từ ClusterControl - chúng tôi sẽ hiển thị các bước sau, khi chúng tôi sẽ thực hiện điều đó cho cụm thứ hai.
Sau khi hoàn tất sao lưu, nó sẽ hiển thị trên danh sách. Sau đó, chúng tôi có thể tiếp tục và khôi phục nó:
Nếu chúng tôi muốn điều đó, chúng tôi thậm chí có thể thực hiện Khôi phục điểm trong thời gian, nhưng trong trường hợp của chúng tôi, điều đó không thực sự quan trọng:khi bản sao sẽ được định cấu hình, tất cả các giao dịch bắt buộc từ binlog sẽ được áp dụng trên cụm mới.
Sau đó, chúng tôi chọn tùy chọn để tạo một cụm từ bản sao lưu. Thao tác này sẽ mở ra một hộp thoại khác:
Nó là xác nhận bản sao lưu nào sẽ được sử dụng, máy chủ lưu trữ bản sao lưu được lấy từ máy chủ nào, phương pháp nào được sử dụng để tạo nó và một số siêu dữ liệu để giúp xác minh xem bản sao lưu có hoạt động hay không.
Sau đó, về cơ bản chúng ta đi đến trình hướng dẫn triển khai thông thường, trong đó chúng ta phải xác định kết nối SSH giữa máy chủ lưu trữ ClusterControl và các nút để triển khai cụm trên (yêu cầu đối với ClusterControl) và trong bước thứ hai, nhà cung cấp, phiên bản, mật khẩu và các nút để triển khai trên:
Đó là tất cả những gì liên quan đến việc triển khai và cung cấp. ClusterControl sẽ thiết lập cụm mới và nó sẽ cung cấp cho nó bằng cách sử dụng dữ liệu từ cụm cũ.
Chúng tôi có thể theo dõi tiến trình trong tab hoạt động. Sau khi hoàn thành, cụm thứ hai sẽ hiển thị trên danh sách cụm trong ClusterControl.
Cấu hình lại cụm mới bằng ClusterControl
Bây giờ, chúng ta phải định cấu hình lại cụm - chúng ta sẽ bật nhật ký nhị phân. Trong quy trình thủ công, chúng tôi phải thực hiện các thay đổi trong cấu hình wsrep_sst_auth và cả các mục cấu hình trong phần [mysqldump] và [xtrabackup] của cấu hình. Bạn có thể tìm thấy những cài đặt đó trong tệp secret-backup.cnf. Lần này không cần thiết vì ClusterControl đã tạo mật khẩu mới cho cụm và định cấu hình các tệp một cách chính xác. Tuy nhiên, điều quan trọng cần ghi nhớ là nếu bạn thay đổi mật khẩu của người dùng 'backupuser'@'127.0.0.1' trong cụm ban đầu, bạn cũng sẽ phải thực hiện các thay đổi cấu hình trong cụm thứ hai để phản ánh điều đó dưới dạng các thay đổi trong cụm đầu tiên sẽ sao chép sang cụm thứ hai.
Nhật ký nhị phân có thể được bật từ phần Nút. Bạn phải chọn từng nút và chạy công việc “Bật ghi nhật ký nhị phân”. Bạn sẽ thấy một hộp thoại:
Tại đây, bạn có thể xác định thời gian bạn muốn giữ nhật ký, nơi chúng sẽ được lưu trữ và nếu ClusterControl nên khởi động lại nút để bạn áp dụng các thay đổi - cấu hình nhật ký nhị phân không động và MariaDB phải được khởi động lại để áp dụng những thay đổi đó.
Khi các thay đổi hoàn tất, bạn sẽ thấy tất cả các nút được đánh dấu là “chính”, có nghĩa là các nút đó đã bật nhật ký nhị phân và có thể hoạt động như chính.
Nếu chúng ta chưa tạo bản sao người dùng, chúng ta phải làm điều đó. Trong cụm đầu tiên, chúng ta phải đi tới Quản lý -> Lược đồ và Người dùng:
Ở phía bên phải, chúng tôi có một tùy chọn để tạo người dùng mới:
Điều này kết thúc cấu hình cần thiết để thiết lập bản sao.
Thiết lập sao chép giữa các cụm bằng ClusterControl
Như chúng tôi đã nêu, chúng tôi đang làm việc để tự động hóa phần này. Hiện tại nó phải được thực hiện thủ công. Như bạn có thể nhớ, chúng tôi cần vị trí GITD của bản sao lưu của chúng tôi và sau đó chạy một số lệnh bằng cách sử dụng MySQL CLI. Dữ liệu GTID có sẵn trong bản sao lưu. ClusterControl tạo bản sao lưu bằng cách sử dụng xbstream / mbstream và nó sẽ nén nó sau đó. Bản sao lưu của chúng tôi được lưu trữ trên máy chủ ClusterControl nơi chúng tôi không có quyền truy cập vào tệp nhị phân mbstream. Bạn có thể thử cài đặt nó hoặc bạn có thể sao chép tệp sao lưu vào vị trí, nơi có sẵn tệp nhị phân như vậy:
scp /root/backups/BACKUP-2/ backup-full-2019-06-24_144329.xbstream.gz 10.0.0.104:/root/mariabackup/Sau khi hoàn tất, vào ngày 10.0.0.104, chúng tôi muốn kiểm tra nội dung của tệp xtrabackup_info:
cd /root/mariabackup
zcat backup-full-2019-06-24_144329.xbstream.gz | mbstream -x
[email protected]:~/mariabackup# cat /root/mariabackup/xtrabackup_info | grep binlog_pos
binlog_pos = filename 'binlog.000007', position '379', GTID of the last change '9999-1002-846116'Cuối cùng, chúng tôi định cấu hình bản sao và khởi động nó:
MariaDB [(none)]> SET GLOBAL gtid_slave_pos ='9999-1002-846116';
Query OK, 0 rows affected (0.024 sec)MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_PORT=3306, MASTER_USER='repuser', MASTER_PASSWORD='reppass', MASTER_USE_GTID=slave_pos;
Query OK, 0 rows affected (0.024 sec)MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.010 sec)Đây là nó - chúng tôi vừa định cấu hình sao chép không đồng bộ giữa hai cụm MariaDB Galera bằng cách sử dụng ClusterControl. Như bạn có thể thấy, ClusterControl có thể tự động hóa phần lớn các bước chúng tôi phải thực hiện để thiết lập môi trường này.
