Cách sao lưu và khôi phục ClusterControl

ClusterControl 1.7.1 đã giới thiệu một tính năng mới cho phép bạn sao lưu máy chủ ClusterControl và khôi phục nó (cùng với siêu dữ liệu về cơ sở dữ liệu được quản lý của bạn) vào một máy chủ khác. Nó sao lưu ứng dụng ClusterControl cũng như tất cả dữ liệu cấu hình của nó. Di chuyển ClusterControl sang một máy chủ mới từng là một vấn đề khó khăn nhưng không còn nữa.

Bài đăng trên blog này sẽ hướng dẫn bạn về tính năng mới này.

Chúng tôi sẽ di chuyển ClusterControl từ máy chủ này sang máy chủ khác, giữ nguyên tất cả các cấu hình và cài đặt.

Chúng tôi cũng sẽ chỉ cho bạn cách chuyển quyền quản lý một cụm từ phiên bản ClusterControl này sang phiên bản ClusterControl khác.

Kiến trúc mẫu của chúng tôi bắt đầu với hai cụm sản xuất (được hiển thị trong ảnh chụp màn hình bên dưới):

• ID cụm 1:3 nút Galera (PXC) + 1 HAProxy + 1 ProxySQL (5 nút)
• ID cụm 2:1 MySQL master + 2 MySQL slave + 1 ProxySQL (4 node)

Giới thiệu

ClusterControl CLI (s9s) là một công cụ giao diện dòng lệnh để tương tác, kiểm soát và quản lý các cụm cơ sở dữ liệu bằng cách sử dụng Nền tảng ClusterControl. Bắt đầu từ phiên bản 1.4.1, tập lệnh trình cài đặt sẽ tự động cài đặt gói này trên nút ClusterControl.

Về cơ bản, có 4 tùy chọn mới được giới thiệu trong lệnh "sao lưu s9s", có thể được sử dụng để đạt được mục tiêu của chúng tôi:

Bài đăng trên blog này sẽ đề cập đến các trường hợp sử dụng ví dụ về cách sử dụng các tùy chọn đó. Hiện tại, chúng đang ở giai đoạn ứng viên phát hành và chỉ có sẵn thông qua công cụ ClusterControl CLI.

Sao lưu ClusterControl

Để thực hiện việc này, máy chủ ClusterControl ít nhất phải trên v1.7.1 trở lên. Để sao lưu bộ điều khiển ClusterControl, chỉ cần chạy lệnh sau trên nút ClusterControl với tư cách người dùng gốc (hoặc với sudo):

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

--Output-file phải là tên tệp hoặc đường dẫn vật lý (nếu bạn muốn bỏ qua cờ --backup-directory) và tệp không được tồn tại trước đó. ClusterControl sẽ không thay thế tệp đầu ra nếu nó đã tồn tại. Bằng cách chỉ định --log, nó sẽ đợi cho đến khi công việc được thực thi và nhật ký công việc sẽ được hiển thị trong thiết bị đầu cuối. Các nhật ký giống nhau có thể được truy cập thông qua giao diện người dùng ClusterControl trong Hoạt động -> Công việc -> Lưu bộ điều khiển :

Công việc 'Bộ điều khiển Lưu' về cơ bản thực hiện các quy trình sau:

1. Truy xuất cấu hình bộ điều khiển và xuất nó sang JSON
2. Xuất cơ sở dữ liệu CMON dưới dạng tệp kết xuất MySQL
3. Đối với mọi cụm cơ sở dữ liệu:
   1. Truy xuất cấu hình cụm và xuất nó sang JSON

Trong đầu ra, bạn có thể nhận thấy công việc được tìm thấy là N + 1 cụm, ví dụ "Đã tìm thấy 3 (các) cụm để lưu" mặc dù chúng tôi chỉ có hai cụm cơ sở dữ liệu. Điều này bao gồm ID cụm 0, mang ý nghĩa đặc biệt trong ClusterControl là cụm được khởi tạo toàn cục. Tuy nhiên, nó không thuộc thành phần CmonCluster, là cụm cơ sở dữ liệu trong quản lý ClusterControl.

Khôi phục ClusterControl thành một máy chủ ClusterControl mới

Giả sử ClusterControl đã được cài đặt trên máy chủ mới, chúng tôi muốn di chuyển các cụm cơ sở dữ liệu sang máy chủ mới quản lý. Sơ đồ sau minh họa bài tập di chuyển của chúng tôi:

Đầu tiên, chuyển bản sao lưu từ máy chủ cũ sang máy chủ mới:

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

Trước khi thực hiện khôi phục, chúng tôi phải thiết lập SSH không mật khẩu cho tất cả các nút từ máy chủ ClusterControl mới:

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

Sau đó, trên máy chủ mới, hãy thực hiện khôi phục:

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

Sau đó, chúng tôi phải đồng bộ hóa cụm trong giao diện người dùng bằng cách đi tới Cài đặt chung -> Đăng ký cụm -> Đồng bộ hóa cụm . Sau đó, nếu bạn quay lại trang tổng quan chính của ClusterControl, bạn sẽ thấy như sau:

Không hoảng loạn. Giao diện người dùng ClusterControl mới không thể truy xuất dữ liệu giám sát và quản lý do mã thông báo API RPC không chính xác. Chúng tôi chỉ cần cập nhật nó cho phù hợp. Đầu tiên, truy xuất giá trị rpc_key cho các cụm tương ứng:

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

Trong giao diện người dùng, nhấp vào liên kết "tại đây" ở sau dòng "Thay đổi mã thông báo API RPC tại đây". Nó sẽ bật lên hộp thoại sau:

Dán giá trị rpc_key tương ứng vào trường văn bản và nhấp vào Lưu. Lặp lại cho cụm tiếp theo. Chờ trong giây lát và danh sách cụm sẽ được tự động làm mới.

Bước cuối cùng là sửa các đặc quyền của người dùng cmon MySQL đối với các thay đổi địa chỉ IP ClusterControl mới, 192.168.0.190. Đăng nhập vào một trong các nút PXC và chạy như sau:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Thay thế bằng mật khẩu MySQL cmon giống hệt như trong giá trị mysql_password bên trong /etc/cmon.cnf. Lặp lại bước tương tự trên cụm thứ hai, bản sao MySQL nhưng chỉ thực thi nó một lần trên nút chính.

Khi đặc quyền được thiết lập, bạn sẽ thấy danh sách cụm có màu xanh lục, tương tự như danh sách cũ:

Điều đáng nói là theo mặc định, ClusterControl sẽ vô hiệu hóa tính năng khôi phục tự động của cụm (như bạn có thể thấy biểu tượng màu đỏ bên cạnh từ 'Cluster') để tránh tình trạng chạy đua với phiên bản ClusterControl khác. Bạn nên bật tính năng này (bằng cách nhấp vào biểu tượng chuyển sang màu xanh lục) sau khi máy chủ cũ ngừng hoạt động.

Quá trình di chuyển của chúng tôi đã hoàn tất. Tất cả các cấu hình và cài đặt từ máy chủ cũ được giữ nguyên và chuyển sang máy chủ mới.

Di chuyển quản lý một cụm sang một máy chủ điều khiển cụm khác

Sao lưu thông tin cụm

Đây là về việc sao lưu siêu dữ liệu cụm và thông tin để chúng tôi có thể chuyển nó sang một máy chủ ClusterControl khác, còn được gọi là sao lưu một phần. Nếu không, chúng tôi phải thực hiện "Nhập máy chủ / cụm hiện có" để nhập lại chúng vào ClusterControl mới, điều đó có nghĩa là bạn sẽ mất dữ liệu giám sát từ máy chủ cũ. Nếu bạn có bộ cân bằng tải hoặc bản sao nô lệ không đồng bộ, điều này sẽ phải được nhập khi cụm được nhập, mỗi lần một nút. Vì vậy, sẽ hơi rắc rối nếu bạn có một bộ thiết lập sản xuất hoàn chỉnh.

Bài tập di chuyển "trình quản lý" cụm được minh họa trong sơ đồ sau:

Về cơ bản, chúng tôi muốn di chuyển Bản sao MySQL của mình (ID cụm:2) để được quản lý bởi một phiên bản ClusterControl khác. Chúng tôi sẽ sử dụng các tùy chọn --save-cluster-info và --restore-cluster-info cho cái này. Tùy chọn --save-cluster-info sẽ xuất thông tin cụm tương ứng để lưu ở một nơi khác. Hãy xuất Cụm nhân bản MySQL của chúng tôi (ID cụm:2). Trên máy chủ ClusterControl hiện tại, hãy thực hiện:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

Bạn sẽ thấy một loạt các dòng mới được in trong thiết bị đầu cuối, cho biết công việc sao lưu đang chạy (đầu ra cũng có thể truy cập thông qua ClusterControl -> Hoạt động -> Công việc ):

Nếu bạn xem kỹ nhật ký công việc, bạn sẽ nhận thấy công việc đang cố gắng xuất tất cả thông tin liên quan và siêu dữ liệu cho ID cụm 2. Đầu ra được lưu trữ dưới dạng tệp nén và nằm trong đường dẫn mà chúng tôi đã chỉ định bằng cách sử dụng --backup cờ thư mục. Nếu cờ này bị bỏ qua, ClusterControl sẽ lưu đầu ra vào thư mục sao lưu mặc định là thư mục chính của người dùng SSH, trong $ HOME / backup.

Khôi phục thông tin cụm

Các bước được giải thích ở đây tương tự với các bước khôi phục cho sao lưu đầy đủ ClusterControl. Chuyển bản sao lưu từ máy chủ hiện tại sang máy chủ ClusterControl khác:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

Trước khi thực hiện khôi phục, chúng tôi phải thiết lập SSH không mật khẩu cho tất cả các nút từ máy chủ ClusterControl mới:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

Sau đó, trên máy chủ mới, hãy thực hiện khôi phục thông tin cụm cho Bản sao MySQL của chúng tôi:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

Bạn có thể xác minh tiến trình trong Hoạt động -> Công việc -> Khôi phục cụm :

Nếu bạn xem xét kỹ các thông báo công việc, bạn có thể thấy rằng ClusterControl tự động gán lại ID cụm thành 1 trên phiên bản mới này (đó là ID cụm 2 trên phiên bản cũ).

Sau đó, đồng bộ hóa cụm trong giao diện người dùng bằng cách đi tới Cài đặt chung -> Đăng ký cụm -> Đồng bộ hóa cụm . Nếu bạn quay lại bảng điều khiển chính của ClusterControl, bạn sẽ thấy như sau:

Lỗi có nghĩa là giao diện người dùng ClusterControl mới không thể truy xuất dữ liệu giám sát và quản lý do mã thông báo API RPC không chính xác. Chúng tôi chỉ cần cập nhật nó cho phù hợp. Đầu tiên, truy xuất giá trị rpc_key cho ID cụm 1 của chúng tôi:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

Trong giao diện người dùng, nhấp vào liên kết "tại đây" ở sau dòng "Thay đổi mã thông báo API RPC tại đây". Nó sẽ bật lên hộp thoại sau:

Dán giá trị rpc_key tương ứng vào trường văn bản và nhấp vào Lưu. Chờ trong giây lát và danh sách cụm sẽ được tự động làm mới.

Bước cuối cùng là sửa các đặc quyền của người dùng cmon MySQL đối với các thay đổi địa chỉ IP ClusterControl mới, 192.168.0.190. Đăng nhập vào nút chính (192.168.0.31) và chạy câu lệnh sau:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Thay thế bằng mật khẩu MySQL cmon giống hệt như trong giá trị mysql_password bên trong /etc/cmon.cnf.

Bạn cũng có thể thu hồi các đặc quyền của người dùng cũ (thu hồi sẽ không xóa người dùng) hoặc chỉ cần loại bỏ người dùng cũ:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

Sau khi đặc quyền được thiết lập, bạn sẽ thấy mọi thứ có màu xanh lục:

Tại thời điểm này, kiến ​​trúc của chúng tôi trông giống như sau:

Bài tập di chuyển của chúng tôi hiện đã hoàn tất.

Lời kết

Giờ đây, có thể thực hiện sao lưu toàn bộ và một phần các phiên bản ClusterControl của bạn và các cụm mà chúng quản lý, cho phép bạn di chuyển chúng tự do giữa các máy chủ mà không cần cố gắng nhiều. Đề xuất và phản hồi được hoan nghênh.