MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Cách định cấu hình sao chép cụm-thành-cụm cho Percona XtraDB Cluster hoặc MariaDB Cluster

Trong một blog trước, chúng tôi đã công bố một tính năng ClusterControl 1.7.4 mới được gọi là Cluster-to-Cluster Replication. Nó tự động hóa toàn bộ quá trình thiết lập cụm DR khỏi cụm chính của bạn, với sự sao chép ở giữa. Để biết thêm thông tin chi tiết, vui lòng tham khảo mục blog được đề cập ở trên.

Bây giờ trong blog này, chúng ta sẽ xem xét cách định cấu hình tính năng mới này cho một cụm hiện có. Đối với tác vụ này, chúng tôi sẽ giả sử bạn đã cài đặt ClusterControl và Master Cluster đã được triển khai bằng cách sử dụng nó.

Yêu cầu đối với Cụm chính

Có một số yêu cầu đối với Cụm chính để nó hoạt động:

  • Percona XtraDB Cluster phiên bản 5.6.x trở lên hoặc MariaDB Galera Cluster phiên bản 10.x trở lên.
  • Đã bật
  • GTID.
  • Đã bật tính năng ghi nhật ký nhị phân trên ít nhất một nút cơ sở dữ liệu.
  • Thông tin xác thực sao lưu phải giống nhau trên Cụm chính và Cụm nô lệ.

Chuẩn bị Cụm Chính

Cụm chính cần được chuẩn bị để sử dụng tính năng mới này. Nó yêu cầu cấu hình từ cả ClusterControl và Database.

Cấu hình ClusterControl

Trong nút cơ sở dữ liệu, hãy kiểm tra thông tin đăng nhập của người dùng sao lưu được lưu trữ trong /etc/my.cnf.d/secrets-backup.cnf (Đối với Hệ điều hành dựa trên RedHat) hoặc trong / etc / mysql / secret-backup .cnf (Dành cho HĐH dựa trên Debian).

$ cat /etc/my.cnf.d/secrets-backup.cnf

# Security credentials for backup.

[mysqldump]

user=backupuser

password=cYj0GFBEdqdreZEl



[xtrabackup]

user=backupuser

password=cYj0GFBEdqdreZEl



[mysqld]

wsrep_sst_auth=backupuser:cYj0GFBEdqdreZEl

Trong nút ClusterControl, hãy chỉnh sửa tệp cấu hình /etc/cmon.d/cmon_ID.cnf (trong đó ID là Số ID cụm) và đảm bảo rằng nó chứa cùng thông tin đăng nhập được lưu trữ trong bản sao lưu bí mật. cnf.

$ cat /etc/cmon.d/cmon_8.cnf

backup_user=backupuser

backup_user_password=cYj0GFBEdqdreZEl

basedir=/usr

cdt_path=/

cluster_id=8

...

Bất kỳ thay đổi nào trên tệp này đều yêu cầu khởi động lại dịch vụ cmon:

$ service cmon restart

Kiểm tra các thông số sao chép cơ sở dữ liệu để đảm bảo rằng bạn đã bật GTID và Ghi nhật ký nhị phân.

Cấu hình Cơ sở dữ liệu

Trong nút cơ sở dữ liệu, hãy kiểm tra tệp /etc/my.cnf (Đối với Hệ điều hành dựa trên RedHat) hoặc /etc/mysql/my.cnf (Đối với Hệ điều hành dựa trên Debian) để xem cấu hình liên quan đến quá trình nhân rộng.

Percona XtraDB:

$ cat /etc/my.cnf

# REPLICATION SPECIFIC

server_id=4002

binlog_format=ROW

log_bin = /var/lib/mysql-binlog/binlog

log_slave_updates = ON

gtid_mode = ON

enforce_gtid_consistency = true

relay_log = relay-log

expire_logs_days = 7

Cụm MariaDB Galera:

$ cat /etc/my.cnf

# REPLICATION SPECIFIC

server_id=9000

binlog_format=ROW

log_bin = /var/lib/mysql-binlog/binlog

log_slave_updates = ON

relay_log = relay-log

wsrep_gtid_domain_id=9000

wsrep_gtid_mode=ON

gtid_domain_id=9000

gtid_strict_mode=ON

gtid_ignore_duplicates=ON

expire_logs_days = 7

Đã chèn kiểm tra tệp cấu hình, bạn có thể xác minh xem tệp đó có được bật trong giao diện người dùng ClusterControl hay không. Vào ClusterControl -> Chọn Cluster -> Nodes. Ở đó, bạn sẽ có một cái gì đó như thế này:

Vai trò "Chính" được thêm vào nút đầu tiên có nghĩa là Ghi nhật ký nhị phân được bật.

Bật tính năng ghi nhật ký nhị phân

Nếu bạn chưa bật tính năng ghi nhật ký nhị phân, hãy đi tới ClusterControl -> Chọn Cụm -> Nút -> Hành động nút -> Bật ghi nhật ký nhị phân.

Sau đó, bạn phải chỉ định lưu giữ nhật ký nhị phân và đường dẫn để lưu trữ nó. Bạn cũng nên chỉ định xem bạn muốn ClusterControl khởi động lại nút cơ sở dữ liệu sau khi định cấu hình nó hay bạn muốn tự khởi động lại.

Hãy nhớ rằng Bật tính năng Ghi nhật ký nhị phân luôn yêu cầu khởi động lại dịch vụ cơ sở dữ liệu .

Tạo Cụm nô lệ từ GUI ClusterControl

Để tạo một Cụm nô lệ mới, hãy đi tới ClusterControl -> Chọn Cụm -> Hành động Cụm -> Tạo Cụm nô lệ.

Cụm Slave có thể được tạo bằng cách truyền dữ liệu từ Cụm chính hiện tại hoặc bằng cách sử dụng một bản sao lưu hiện có.

Trong phần này, bạn cũng phải chọn nút chính của cụm hiện tại từ đó dữ liệu sẽ được sao chép.

Khi chuyển sang bước tiếp theo, bạn phải chỉ định Người dùng, Khóa hoặc Mật khẩu và cổng để kết nối bằng SSH với máy chủ của bạn. Bạn cũng cần có tên cho Cụm Slave của mình và nếu bạn muốn ClusterControl cài đặt phần mềm và cấu hình tương ứng cho bạn.

Sau khi thiết lập thông tin truy cập SSH, bạn phải xác định nhà cung cấp cơ sở dữ liệu và phiên bản, datadir, cổng cơ sở dữ liệu và mật khẩu quản trị. Đảm bảo rằng bạn sử dụng cùng nhà cung cấp / phiên bản và thông tin đăng nhập như được sử dụng bởi Cụm chính. Bạn cũng có thể chỉ định kho lưu trữ nào sẽ sử dụng.

Trong bước này, bạn cần thêm máy chủ vào Cụm nô lệ mới. Đối với tác vụ này, bạn có thể nhập cả Địa chỉ IP hoặc Tên máy chủ của mỗi nút cơ sở dữ liệu.

Bạn có thể theo dõi trạng thái tạo Cụm nô lệ mới của mình từ Giám sát hoạt động ClusterControl. Sau khi tác vụ hoàn thành, bạn có thể thấy cụm trong màn hình ClusterControl chính.

Quản lý Sao chép Cụm-thành-Cụm bằng GUI ClusterControl

Bây giờ bạn đã thiết lập và chạy Bản sao theo cụm từ cụm thành cụm của mình, có các hành động khác nhau để thực hiện trên cấu trúc liên kết này bằng cách sử dụng ClusterControl.

Định cấu hình Nhóm Hoạt động-Hoạt động

Như bạn thấy, theo mặc định, Cụm nô lệ được thiết lập ở chế độ Chỉ đọc. Có thể tắt cờ Chỉ đọc trên các nút lần lượt từ Giao diện người dùng ClusterControl, nhưng hãy nhớ rằng phân nhóm Hoạt động-Hoạt động chỉ được khuyến nghị nếu các ứng dụng chỉ chạm vào các tập dữ liệu rời rạc trên một trong hai cụm vì MySQL / MariaDB không đưa ra bất kỳ Giải pháp hoặc Phát hiện Xung đột nào.

Để tắt chế độ Chỉ đọc, đi tới ClusterControl -> Chọn Nô lệ Cụm -> Nút. Trong phần này, hãy chọn từng nút và sử dụng tùy chọn Tắt chỉ đọc.

Xây dựng lại Cụm nô lệ

Để tránh mâu thuẫn, nếu bạn muốn xây dựng lại Cụm Slave, thì đây phải là cụm Chỉ Đọc, điều này có nghĩa là tất cả các nút phải ở chế độ Chỉ Đọc.

Đi tới ClusterControl -> Chọn Cụm nô lệ -> Nút -> Chọn Node được kết nối với Master Cluster -> Node Actions -> Rebuild Replication Slave.

Thay đổi cấu trúc liên kết

Nếu bạn có cấu trúc liên kết sau:

Và vì lý do nào đó, bạn muốn thay đổi nút sao chép trong Master Cụm. Có thể thay đổi nút chính được Cụm nô lệ sử dụng thành nút chính khác trong Cụm chính.

Để được coi là một nút chính, nó phải bật tính năng ghi nhật ký nhị phân .

Đi tới ClusterControl -> Chọn Cụm nô lệ -> Nút -> Chọn Nút được kết nối với Cụm chính -> Hành động của Nút -> Dừng Slave / Bắt đầu Slave.

Dừng / Bắt đầu Nô lệ sao chép

Bạn có thể dừng và bắt đầu sao chép nô lệ một cách dễ dàng bằng cách sử dụng ClusterControl.

Đi tới ClusterControl -> Chọn Cụm nô lệ -> Nút -> Chọn Nút được kết nối với Cụm chính -> Hành động của Nút -> Dừng Slave / Bắt đầu Slave.

Đặt lại Replication Slave

Sử dụng hành động này, bạn có thể đặt lại quá trình sao chép bằng cách sử dụng ĐẶT LẠI TRƯỢT hoặc ĐẶT LẠI TRƯỢT TẤT CẢ. Sự khác biệt giữa chúng là, ĐẶT LẠI SLAVE không thay đổi bất kỳ thông số sao chép nào như máy chủ chính, cổng và thông tin đăng nhập. Để xóa thông tin này, bạn phải sử dụng RESET SLAVE ALL để xóa tất cả cấu hình sao chép, do đó, sử dụng lệnh này, liên kết Cluster-to-Cluster Replication sẽ bị hủy.

Trước khi sử dụng tính năng này, bạn phải dừng quá trình sao chép (vui lòng tham khảo tính năng trước đó).

Đi tới ClusterControl -> Chọn Cụm nô lệ -> Nút -> Chọn Node được kết nối với Master Cluster -> Node Actions -> Reset Slave / Reset Slave All.

Quản lý sao chép cụm-thành-cụm bằng CLI ClusterControl

Trong phần trước, bạn đã có thể xem cách quản lý Nhân bản theo cụm-thành-cụm bằng giao diện người dùng ClusterControl. Bây giờ, hãy xem cách thực hiện bằng cách sử dụng dòng lệnh.

Lưu ý:Như chúng tôi đã đề cập ở phần đầu của blog này, chúng tôi sẽ cho rằng bạn đã cài đặt ClusterControl và Master Cluster đã được triển khai bằng cách sử dụng nó.

Tạo Cụm nô lệ

Trước tiên, hãy xem một lệnh ví dụ để tạo một Cụm nô lệ bằng cách sử dụng ClusterControl CLI:

$ s9s cluster --create --cluster-name=Galera1rep --cluster-type=galera  --provider-version=10.4 --nodes="192.168.100.166;192.168.100.167;192.168.100.168"  --os-user=root --os-key-file=/root/.ssh/id_rsa --db-admin=root --db-admin-passwd=xxxxxxxx --vendor=mariadb --remote-cluster-id=11 --log

Bây giờ bạn đã chạy quá trình tạo nô lệ của mình, hãy xem từng tham số đã sử dụng:

  • Cụm:Để liệt kê và thao tác các cụm.
  • Tạo:Tạo và cài đặt một cụm mới.
  • Cluster-name:Tên của Cụm nô lệ mới.
  • Cluster-type:Loại cụm để cài đặt.
  • Phiên bản nhà cung cấp:Phiên bản phần mềm.
  • Nút:Danh sách các nút mới trong Cụm nô lệ.
  • Os-user:Tên người dùng cho các lệnh SSH.
  • Os-key-file:Tệp khóa để sử dụng cho kết nối SSH.
  • Db-admin:Tên người dùng quản trị cơ sở dữ liệu.
  • Db-admin-passwd:Mật khẩu dành cho quản trị viên cơ sở dữ liệu.
  • Remote-cluster-id:Master Cluster ID cho bản sao Cluster-to-Cluster.
  • Nhật ký:Chờ và theo dõi thông báo công việc.

Sử dụng cờ --log, bạn sẽ có thể xem nhật ký trong thời gian thực:

Verifying job parameters.

Checking ssh/sudo on 3 hosts.

All 3 hosts are accessible by SSH.

192.168.100.166: Checking if host already exists in another cluster.

192.168.100.167: Checking if host already exists in another cluster.

192.168.100.168: Checking if host already exists in another cluster.

192.168.100.157:3306: Binary logging is enabled.

192.168.100.158:3306: Binary logging is enabled.

Creating the cluster with the following:

wsrep_cluster_address = 'gcomm://192.168.100.166,192.168.100.167,192.168.100.168'

Calling job: setupServer(192.168.100.166).

192.168.100.166: Checking OS information.

…

Caching config files.

Job finished, all the nodes have been added successfully.

Định cấu hình Nhóm Hoạt động-Hoạt động

Như bạn có thể thấy trước đó, bạn có thể tắt chế độ Chỉ đọc trong cụm mới bằng cách tắt chế độ này trong mỗi nút, vì vậy hãy xem cách thực hiện điều đó từ dòng lệnh.

$ s9s node --set-read-write --nodes="192.168.100.166" --cluster-id=16 --log

Hãy xem từng tham số:

  • Nút:Để xử lý các nút.
  • Đặt-đọc-ghi:Đặt nút ở chế độ Đọc-Ghi.
  • Nút:Nút có thể thay đổi nó.
  • Cluster-id:ID của cụm chứa nút.

Sau đó, bạn sẽ thấy:

192.168.100.166:3306: Setting read_only=OFF.

Xây dựng lại Cụm nô lệ

Bạn có thể xây dựng lại Cụm nô lệ bằng lệnh sau:

$ s9s replication --stage --master="192.168.100.157:3306" --slave="192.168.100.166:3306" --cluster-id=19 --remote-cluster-id=11 --log

Các tham số là:

  • Sao chép:Để theo dõi và kiểm soát việc sao chép dữ liệu.
  • Giai đoạn:Giai đoạn / Xây dựng lại một Slave nhân bản.
  • Master:Bản sao chính trong cụm chính.
  • Slave:Nô lệ sao chép trong cụm nô lệ.
  • Cluster-id:ID cụm nô lệ.
  • Remote-cluster-id:ID cụm chính.
  • Nhật ký:Chờ và theo dõi thông báo công việc.

Nhật ký công việc phải tương tự như sau:

Rebuild replication slave 192.168.100.166:3306 from master 192.168.100.157:3306.

Remote cluster id = 11

Shutting down Galera Cluster.

192.168.100.166:3306: Stopping node.

192.168.100.166:3306: Stopping mysqld (timeout=60, force stop after timeout=true).

192.168.100.166: Stopping MySQL service.

192.168.100.166: All processes stopped.

192.168.100.166:3306: Stopped node.

192.168.100.167:3306: Stopping node.

192.168.100.167:3306: Stopping mysqld (timeout=60, force stop after timeout=true).

192.168.100.167: Stopping MySQL service.

192.168.100.167: All processes stopped.

…

192.168.100.157:3306: Changing master to 192.168.100.166:3306.

192.168.100.157:3306: Changed master to 192.168.100.166:3306

192.168.100.157:3306: Starting slave.

192.168.100.157:3306: Collecting replication statistics.

192.168.100.157:3306: Started slave successfully.

192.168.100.166:3306: Starting node

Writing file '192.168.100.167:/etc/mysql/my.cnf'.

Writing file '192.168.100.167:/etc/mysql/secrets-backup.cnf'.

Writing file '192.168.100.168:/etc/mysql/my.cnf'.

Thay đổi cấu trúc liên kết

Bạn có thể thay đổi cấu trúc liên kết của mình bằng cách sử dụng một nút khác trong Cụm chính để sao chép dữ liệu, vì vậy, ví dụ:bạn có thể chạy:

$ s9s replication --failover --master="192.168.100.161:3306" --slave="192.168.100.163:3306" --cluster-id=10 --remote-cluster-id=9 --log

Hãy kiểm tra các thông số đã sử dụng.

  • Sao chép:Để theo dõi và kiểm soát việc sao chép dữ liệu.
  • Chuyển đổi dự phòng:Nhận vai trò chủ từ một chủ lỗi / cũ.
  • Master:Bản sao chính mới trong Cụm chính.
  • Slave:Nô lệ sao chép trong Cụm nô lệ.
  • Cluster-id:ID của Slave Cluster.
  • Remote-Cluster-id:ID của Master Cluster.
  • Nhật ký:Chờ và theo dõi thông báo công việc.

Bạn sẽ thấy nhật ký này:

192.168.100.161:3306 belongs to cluster id 9.

192.168.100.163:3306: Changing master to 192.168.100.161:3306

192.168.100.163:3306: My master is 192.168.100.160:3306.

192.168.100.161:3306: Sanity checking replication master '192.168.100.161:3306[cid:9]' to be used by '192.168.100.163[cid:139814070386698]'.

192.168.100.161:3306: Executing GRANT REPLICATION SLAVE ON *.* TO 'cmon_replication'@'192.168.100.163'.

Setting up link between  192.168.100.161:3306 and 192.168.100.163:3306

192.168.100.163:3306: Stopping slave.

192.168.100.163:3306: Successfully stopped slave.

192.168.100.163:3306: Setting up replication using MariaDB GTID: 192.168.100.161:3306->192.168.100.163:3306.

192.168.100.163:3306: Changing Master using master_use_gtid=slave_pos.

192.168.100.163:3306: Changing master to 192.168.100.161:3306.

192.168.100.163:3306: Changed master to 192.168.100.161:3306

192.168.100.163:3306: Starting slave.

192.168.100.163:3306: Collecting replication statistics.

192.168.100.163:3306: Started slave successfully.

192.168.100.160:3306: Flushing logs to update 'SHOW SLAVE HOSTS'

Dừng / Bắt đầu Nô lệ sao chép

Bạn có thể dừng để sao chép dữ liệu từ Cụm chính theo cách này:

$ s9s replication --stop --slave="192.168.100.166:3306" --cluster-id=19 --log

Bạn sẽ thấy điều này:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Stopping slave.

192.168.100.166:3306: Successfully stopped slave.

Và bây giờ, bạn có thể bắt đầu lại:

$ s9s replication --start --slave="192.168.100.166:3306" --cluster-id=19 --log

Vì vậy, bạn sẽ thấy:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Starting slave.

192.168.100.166:3306: Collecting replication statistics.

192.168.100.166:3306: Started slave successfully.

Bây giờ, hãy kiểm tra các thông số đã sử dụng.

  • Sao chép:Để theo dõi và kiểm soát việc sao chép dữ liệu.
  • Dừng / Bắt đầu:Để làm cho máy phụ dừng / bắt đầu sao chép.
  • Slave:Nút nô lệ nhân bản.
  • Cluster-id:ID của cụm chứa nút phụ.
  • Nhật ký:Chờ và theo dõi thông báo công việc.

Đặt lại Replication Slave

Sử dụng lệnh này, bạn có thể đặt lại quá trình sao chép bằng cách sử dụng ĐẶT LẠI SLAVE hoặc RESET SLAVE ALL. Để biết thêm thông tin về lệnh này, vui lòng kiểm tra cách sử dụng lệnh này trong phần Giao diện người dùng ClusterControl trước đó.

Trước khi sử dụng tính năng này, bạn phải dừng quá trình sao chép (vui lòng tham khảo lệnh trước).

ĐẶT LẠI LƯỢT:

$ s9s replication --reset  --slave="192.168.100.166:3306" --cluster-id=19 --log

Nhật ký phải như sau:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Executing 'RESET SLAVE'.

192.168.100.166:3306: Command 'RESET SLAVE' succeeded.

ĐẶT LẠI TRƯỢT TẤT CẢ:

$ s9s replication --reset --force  --slave="192.168.100.166:3306" --cluster-id=19 --log

Và nhật ký này phải là:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Executing 'RESET SLAVE /*!50500 ALL */'.

192.168.100.166:3306: Command 'RESET SLAVE /*!50500 ALL */' succeeded.

Hãy xem các thông số được sử dụng cho cả ĐẶT LẠI LƯỢT LẠI và ĐẶT LẠI LƯU TRỮ TẤT CẢ.

  • Sao chép:Để theo dõi và kiểm soát việc sao chép dữ liệu.
  • Đặt lại:Đặt lại nút phụ.
  • Buộc:Khi sử dụng cờ này, bạn sẽ sử dụng lệnh RESET SLAVE ALL trên nút phụ.
  • Slave:Nút nô lệ nhân bản.
  • Cluster-id:ID cụm nô lệ.
  • Nhật ký:Chờ và theo dõi thông báo công việc.

Kết luận

Tính năng ClusterControl mới này sẽ cho phép bạn tạo Cluster-to-Cluster Replication nhanh chóng và quản lý nó một cách dễ dàng và thân thiện. Môi trường này sẽ cải thiện cấu trúc liên kết cơ sở dữ liệu / cụm của bạn và nó sẽ hữu ích cho Kế hoạch khôi phục sau thảm họa, môi trường thử nghiệm và thậm chí nhiều tùy chọn khác được đề cập trong blog tổng quan.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách TIMEDIFF () hoạt động trong MariaDB

  2. Cách hoạt động của COMPRESS () trong MariaDB

  3. Mẹo để chuyển từ MySQL Replication sang MySQL Galera Cluster 4.0

  4. Có gì mới trong MariaDB Cluster 10.4

  5. Những gì khách hàng của chúng tôi mong muốn:Giới thiệu Tài liệu Doanh nghiệp của MariaDB