Trong các blog trước đây của chúng tôi, chúng tôi đã giải thích lý do tại sao bạn cần chuyển đổi dự phòng cơ sở dữ liệu và đã giải thích cách hoạt động của cơ chế chuyển đổi dự phòng. Tôi chia sẻ điều này trong trường hợp bạn có câu hỏi về lý do tại sao bạn nên thiết lập cơ chế chuyển đổi dự phòng cho cơ sở dữ liệu MySQL của mình. Nếu bạn làm vậy, vui lòng đọc các bài đăng trên blog trước đây của chúng tôi.
Cách Thiết lập Chuyển đổi Dự phòng Tự động
Lợi thế của việc sử dụng MySQL hoặc MariaDB để tự động quản lý chuyển đổi dự phòng của bạn là có các công cụ có sẵn mà bạn có thể sử dụng và triển khai trong môi trường của mình. Từ các giải pháp nguồn mở đến các giải pháp cấp doanh nghiệp. Hầu hết các công cụ không chỉ có khả năng chuyển đổi dự phòng, còn có các tính năng khác như chuyển đổi, giám sát và các tính năng nâng cao có thể cung cấp nhiều khả năng quản lý hơn cho cụm cơ sở dữ liệu MySQL của bạn. Dưới đây, chúng tôi sẽ xem xét những cái phổ biến nhất mà bạn có thể sử dụng.
Sử dụng MHA (Tính khả dụng cao chính)
Chúng tôi đã thực hiện chủ đề này với MHA với các vấn đề phổ biến nhất và cách khắc phục chúng. Chúng tôi cũng đã so sánh MHA với MRM hoặc với MaxScale.
Thiết lập với MHA để có tính khả dụng cao có thể không dễ dàng nhưng sử dụng hiệu quả và linh hoạt vì bạn có thể xác định các tham số có thể điều chỉnh để tùy chỉnh chuyển đổi dự phòng của mình. MHA đã được thử nghiệm và sử dụng. Nhưng khi công nghệ tiến bộ, MHA đã bị tụt hậu vì nó không hỗ trợ GTID cho MariaDB và nó đã không thúc đẩy bất kỳ bản cập nhật nào trong 2 hoặc 3 năm qua.
Bằng cách chạy tập lệnh masterha_manager,
masterha_manager --conf=/etc/app1.cnfTrong đó mẫu /etc/app1.cnf sẽ giống như sau,
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1Các tham số như no_master và application_master sẽ rất quan trọng khi bạn đặt các nút mong muốn trong danh sách cho phép làm nút chính mục tiêu của mình và các nút mà bạn không muốn trở thành nút chính.
Sau khi thiết lập, bạn đã sẵn sàng chuyển đổi dự phòng cho cơ sở dữ liệu MySQL của mình trong trường hợp xảy ra lỗi trên chính hoặc chính. Tập lệnh masterha_manager quản lý chuyển đổi dự phòng (tự động hoặc thủ công), đưa ra quyết định về thời gian và địa điểm cần chuyển đổi dự phòng và quản lý việc khôi phục nô lệ trong quá trình quảng bá chủ ứng viên để áp dụng nhật ký chuyển tiếp khác biệt. Nếu cơ sở dữ liệu chính bị chết, MHA Manager sẽ phối hợp với tác nhân MHA Node vì nó áp dụng nhật ký chuyển tiếp khác biệt cho các nô lệ không có các sự kiện binlog mới nhất từ chính.
Kiểm tra tác nhân MHA Node làm gì và các tập lệnh của nó có liên quan. Về cơ bản, đó là tập lệnh mà Trình quản lý MHA sẽ gọi khi chuyển đổi dự phòng xảy ra. Nó sẽ đợi sự ủy quyền của MHA Manager khi nó tìm kiếm nô lệ mới nhất có chứa các sự kiện binlog và sao chép các sự kiện còn thiếu từ nô lệ bằng cách sử dụng scp và áp dụng chúng cho chính nó. Như đã đề cập, nó áp dụng nhật ký chuyển tiếp, xóa nhật ký chuyển tiếp hoặc lưu nhật ký nhị phân.
Nếu bạn muốn biết thêm về các tham số có thể điều chỉnh và cách tùy chỉnh quản lý chuyển đổi dự phòng, hãy xem trang wiki Tham số cho MHA.
Sử dụng Orchestrator
Orchestrator là một công cụ quản lý nhân rộng và tính sẵn sàng cao của MySQL và MariaDB. Nó được phát hành bởi Shlomi Noach theo các điều khoản của Giấy phép Apache, phiên bản 2.0. Đây là một phần mềm mã nguồn mở và xử lý chuyển đổi dự phòng tự động nhưng có rất nhiều thứ bạn có thể tùy chỉnh hoặc làm để quản lý cơ sở dữ liệu MySQL / MariaDB của mình ngoài việc khôi phục hoặc chuyển đổi dự phòng tự động.
Cài đặt Orchestrator có thể dễ dàng hoặc đơn giản. Khi bạn đã tải xuống các gói cụ thể cần thiết cho môi trường mục tiêu của mình, bạn đã sẵn sàng đăng ký cụm và nút của mình để Orchestrator giám sát. Nó cung cấp giao diện người dùng rất dễ quản lý nhưng có rất nhiều tham số có thể điều chỉnh hoặc tập hợp lệnh mà bạn có thể sử dụng để quản lý chuyển đổi dự phòng của mình.
Hãy xem xét rằng cuối cùng bạn đã thiết lập và việc đăng ký cụm bằng cách thêm nút chính hoặc nút chính của chúng tôi có thể được thực hiện bằng lệnh bên dưới,
$ orchestrator -c discover -i pupnode21:3306
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: pupnode21
2021-01-07 12:32:31 DEBUG Cache hostname resolve pupnode21 as pupnode21
2021-01-07 12:32:31 DEBUG Connected to orchestrator backend: orchestrator:[email protected](127.0.0.1:3306)/orchestrator?timeout=1s
2021-01-07 12:32:31 DEBUG Orchestrator pool SetMaxOpenConns: 128
2021-01-07 12:32:31 DEBUG Initializing orchestrator
2021-01-07 12:32:31 INFO Connecting to backend 127.0.0.1:3306: maxConnections: 128, maxIdleConns: 32
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.222
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.222 as 192.168.40.222
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.223
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.223 as 192.168.40.223
pupnode21:3306Bây giờ, chúng tôi đã thêm cụm của mình.
Nếu một nút chính bị lỗi (lỗi phần cứng hoặc gặp sự cố), Orchestrator sẽ phát hiện và tìm nút nâng cao nhất để được thăng cấp làm nút chính hoặc nút chính.
Bây giờ, chúng ta còn lại hai nút trong cụm khi nút chính bị hỏng .
$ orchestrator-client -c topology -i pupnode21:3306
pupnode21:3306 [unknown,invalid,10.3.27-MariaDB-log,rw,ROW,>>,downtimed]
$ orchestrator-client -c topology -i pupnode22:3306
pupnode22:3306 [0s,ok,10.3.27-MariaDB-log,rw,ROW,>>]
+ pupnode23:3306 [0s,ok,10.3.27-MariaDB-log,ro,ROW,>>,GTID]Sử dụng MaxScale
MariaDB MaxScale đã được hỗ trợ làm bộ cân bằng tải cơ sở dữ liệu. Trong những năm qua, MaxScale đã phát triển và trưởng thành, được mở rộng với một số tính năng phong phú và bao gồm chuyển đổi dự phòng tự động. Kể từ khi MariaDB MaxScale 2.2 được phát hành, nó giới thiệu một số tính năng mới bao gồm quản lý chuyển đổi dự phòng cụm sao chép. Bạn có thể đọc blog trước của chúng tôi về cơ chế chuyển đổi dự phòng MaxScale.
Sử dụng MaxScale theo BSL mặc dù phần mềm được cung cấp miễn phí nhưng yêu cầu bạn ít nhất phải mua dịch vụ với MariaDB. Nó có thể không phù hợp nhưng trong trường hợp bạn đã mua các dịch vụ doanh nghiệp của MariaDB, thì đây có thể là một lợi thế lớn nếu bạn yêu cầu quản lý chuyển đổi dự phòng và các tính năng khác của nó.
Cài đặt MaxScale rất dễ dàng nhưng việc thiết lập cấu hình yêu cầu và xác định các thông số của nó thì không, và nó đòi hỏi bạn phải hiểu phần mềm. Bạn có thể tham khảo hướng dẫn cấu hình của họ.
Để triển khai nhanh chóng và nhanh chóng, bạn có thể sử dụng ClusterControl để cài đặt MaxScale cho bạn trong môi trường MySQL / MariaDB hiện có của bạn.
Sau khi được cài đặt, việc thiết lập cơ sở dữ liệu Moodle của bạn có thể được thực hiện bằng cách trỏ máy chủ của bạn tới IP MaxScale hoặc tên máy chủ và cổng đọc-ghi. Ví dụ,
Cổng 4008 là cổng đọc-ghi cho trình nghe dịch vụ của bạn. Ví dụ:đây là cấu hình dịch vụ và trình nghe sau cho MaxScale của tôi.
$ cat maxscale.cnf.d/rw-listener.cnf
[rw-listener]
type=listener
protocol=mariadbclient
service=rw-service
address=0.0.0.0
port=4008
authenticator=MySQLAuth
$ cat maxscale.cnf.d/rw-service.cnf
[rw-service]
type=service
servers=DB_123,DB_122,DB_124
router=readwritesplit
user=maxscale_adm
password=42BBD2A4DC1BF9BE05C41A71DEEBDB70
max_slave_connections=100%
max_sescmd_history=15000000
causal_reads=true
causal_reads_timeout=10
transaction_replay=true
transaction_replay_max_size=32Mi
delayed_retry=true
master_reconnection=true
max_connections=0
connection_timeout=0
use_sql_variables_in=master
master_accept_reads=true
disable_sescmd_history=falseKhi đang ở trong cấu hình màn hình, bạn không được quên bật chuyển đổi dự phòng tự động hoặc cũng có thể bật tự động tham gia lại nếu bạn muốn bản chính trước đó không tự động tham gia lại khi trực tuyến trở lại. Nó diễn ra như thế này,
$ egrep -r 'auto|^\[' maxscale.cnf.d/replication_monitor.cnf
[replication_monitor]
auto_failover=true
auto_rejoin=1Hãy lưu ý rằng các biến tôi đã nêu không dành cho mục đích sử dụng sản xuất mà chỉ dành cho mục đích thử nghiệm và bài đăng trên blog này. Điều tốt với MaxScale, một khi bậc thầy chính hoặc bậc thầy đi xuống, MaxScale đủ thông minh để thúc đẩy ứng cử viên lý tưởng hoặc tốt nhất đảm nhận vai trò của bậc thầy. Do đó, không cần thay đổi IP và cổng của bạn vì chúng tôi đã sử dụng máy chủ / IP của nút MaxScale của chúng tôi và cổng của nó làm điểm cuối của chúng tôi khi nút chính gặp sự cố. Ví dụ,
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘Nút DB_123 trỏ đến 192.168.40.221 là nút chính hiện tại. Việc kết thúc nút DB_123 sẽ kích hoạt MaxScale thực hiện chuyển đổi dự phòng và nó sẽ giống như thế này,
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Down │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘Trong khi đó, cơ sở dữ liệu Moodle của chúng tôi vẫn đang hoạt động khi MaxScale của chúng tôi trỏ đến trang cái mới nhất đã được thăng cấp.
$ mysql -hmaxscale.local.domain -umoodleuser -pmoodlepassword -P4008
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.3.27-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> select @@hostname;
+------------+
| @@hostname |
+------------+
| 192.168.40.222 |
+------------+
1 row in set (0.001 sec)Sử dụng ClusterControl
ClusterControl có thể được tải xuống miễn phí và cung cấp giấy phép cho Community, Advance và Enterprise. Chuyển đổi dự phòng tự động chỉ khả dụng trên Advance và Enterprise. Tự động chuyển đổi dự phòng được đề cập trong tính năng Tự động khôi phục của chúng tôi, tính năng này cố gắng khôi phục một cụm bị lỗi hoặc một nút bị lỗi. Nếu bạn muốn biết thêm chi tiết về cách thực hiện việc này, hãy xem bài đăng trước của chúng tôi Cách ClusterControl thực hiện khôi phục cơ sở dữ liệu tự động và chuyển đổi dự phòng. Nó cung cấp các thông số có thể điều chỉnh rất thuận tiện và dễ sử dụng. Vui lòng đọc thêm bài đăng trước của chúng tôi về Cách tự động chuyển đổi dự phòng cơ sở dữ liệu với ClusterControl.
Việc quản lý chuyển đổi dự phòng tự động cho cơ sở dữ liệu Moodle của bạn ít nhất phải yêu cầu một IP ảo (VIP) làm điểm cuối cho ứng dụng khách Moodle của bạn giao tiếp với phần phụ trợ cơ sở dữ liệu của bạn. Để làm điều này, bạn có thể triển khai Keepalived với HAProxy (hoặc ProxySQL - tùy thuộc vào lựa chọn cân bằng tải của bạn) trên đó. Trong trường hợp này, điểm cuối cơ sở dữ liệu Moodle của bạn sẽ trỏ đến IP ảo, về cơ bản được Keepalived chỉ định sau khi bạn triển khai nó, giống như cách chúng tôi đã chỉ cho bạn trước đó khi thiết lập MaxScale. Bạn cũng có thể xem blog này để biết cách thực hiện.
Như đã đề cập ở trên, các tham số có thể điều chỉnh có sẵn mà bạn có thể đặt qua /etc/cmon.d/cmon_
- replication_check_binlog_filtration_bf_failover
- replication_check_external_bf_failover
- replication_failed_reslave_failover_script
- replication_failover_blacklist
- replication_failover_events
- replication_failover_wait_to_apply_timeout
- replication_failover_whitelist
- replication_onfail_failover_script
- Replication_post_failover_script
- replication_post_unsuccessful_failover_script
- replication_pre_failover_script
- replication_skip_apply_missing_txs
- replication_stop_on_error
ClusterControl rất linh hoạt khi quản lý chuyển đổi dự phòng, do đó bạn có thể thực hiện một số tác vụ chuyển đổi dự phòng trước hoặc sau chuyển đổi dự phòng.
Kết luận
Có những lựa chọn tuyệt vời khác khi thiết lập và tự động quản lý chuyển đổi dự phòng cho cơ sở dữ liệu MySQL của bạn cho Moodle. Nó phụ thuộc vào ngân sách của bạn và những gì bạn có thể phải chi tiền cho. Việc sử dụng các mã nguồn mở đòi hỏi kiến thức chuyên môn và yêu cầu nhiều lần thử nghiệm để làm quen vì không có hỗ trợ nào bạn có thể chạy khi cần trợ giúp ngoài cộng đồng. Với các giải pháp doanh nghiệp, nó đi kèm với một mức giá nhưng cung cấp cho bạn sự hỗ trợ và dễ dàng vì công việc tiêu tốn thời gian có thể được giảm bớt. Lưu ý rằng nếu sử dụng nhầm chuyển đổi dự phòng, nó có thể gây thiệt hại cho cơ sở dữ liệu của bạn nếu không được xử lý và quản lý đúng cách. Tập trung vào điều gì quan trọng hơn và khả năng của bạn đối với các giải pháp bạn đang sử dụng để quản lý chuyển đổi dự phòng cơ sở dữ liệu Moodle của mình như thế nào.
