Galera Cluster 4.0 lần đầu tiên được phát hành như một phần của MariaDB 10.4 và có rất nhiều cải tiến đáng kể trong phiên bản này. Tính năng ấn tượng nhất trong bản phát hành này là Tính năng sao chép truyền trực tuyến được thiết kế để xử lý các vấn đề sau.
- Các vấn đề với các giao dịch dài
- Sự cố với các giao dịch lớn
- Sự cố với các điểm nóng trong bảng
Trong một blog trước, chúng tôi đã đi sâu vào tính năng Sao chép luồng mới trong blog loạt bài gồm hai phần (Phần 1 và Phần 2). Một phần của tính năng mới này trong Galera 4.0 là các bảng hệ thống mới rất hữu ích cho việc truy vấn và kiểm tra các nút Galera Cluster cũng như các bản ghi đã được xử lý trong Streaming Replication.
Cũng trong các blog trước, chúng tôi cũng đã chỉ cho bạn Cách dễ dàng để triển khai MySQL Galera Cluster trên AWS và cả cách triển khai MySQL Galera Cluster 4.0 trên Amazon AWS EC2.
Percona chưa phát hành GA cho Percona XtraDB Cluster (PXC) 8.0 của họ vì một số tính năng vẫn đang được phát triển, chẳng hạn như hàm wsrep của MySQL WSREP_SYNC_WAIT_UPTO_GTID có vẻ như chưa có (ít nhất là trên phiên bản PXC 8.0.15-5-27dev.4.2). Tuy nhiên, khi PXC 8.0 được phát hành, nó sẽ được tích hợp những tính năng tuyệt vời như ...
- Cải thiện cụm khả năng phục hồi
- Cụm thân thiện với đám mây
- cải tiến cách đóng gói
- Hỗ trợ mã hóa
- DDL nguyên tử
Trong khi chờ đợi bản phát hành PXC 8.0 GA, chúng tôi sẽ giới thiệu trong blog này cách bạn có thể tạo Nút chờ nóng trên Amazon AWS cho Galera Cluster 4.0 bằng MariaDB.
Chế độ chờ Nóng là gì?
Chế độ chờ nóng là một thuật ngữ phổ biến trong máy tính, đặc biệt là trên các hệ thống phân tán cao. Đó là một phương pháp dự phòng trong đó một hệ thống chạy đồng thời với một hệ thống chính giống hệt nhau. Khi sự cố xảy ra trên nút chính, chế độ chờ nóng sẽ ngay lập tức tiếp quản việc thay thế hệ thống chính. Dữ liệu được sao chép sang cả hai hệ thống trong thời gian thực.
Đối với hệ thống cơ sở dữ liệu, máy chủ dự phòng nóng thường là nút thứ hai sau nút chính chính đang chạy trên các tài nguyên mạnh mẽ (giống như máy chủ). Nút phụ này phải ổn định như nút chính để hoạt động chính xác.
Nó cũng đóng vai trò như một nút khôi phục dữ liệu nếu nút chính hoặc toàn bộ cụm gặp sự cố. Nút chờ nóng sẽ thay thế nút hoặc cụm bị lỗi trong khi liên tục phục vụ nhu cầu từ khách hàng.
Trong Galera Cluster, tất cả các máy chủ một phần của cụm có thể hoạt động như một nút dự phòng. Tuy nhiên, nếu khu vực hoặc toàn bộ cụm bị sụt giảm, bạn sẽ làm thế nào để đối phó với điều này? Tạo một nút chờ bên ngoài khu vực hoặc mạng cụ thể trong cụm của bạn là một tùy chọn ở đây.
Trong phần sau, chúng tôi sẽ hướng dẫn bạn cách tạo nút chờ trên AWS EC2 bằng MariaDB.
Triển khai Chế độ chờ nóng trên Amazon AWS
Trước đây, chúng tôi đã hướng dẫn bạn cách tạo Cụm Galera trên AWS. Bạn có thể muốn đọc Triển khai MySQL Galera Cluster 4.0 trên Amazon AWS EC2 trong trường hợp bạn chưa quen với Galera 4.0.
Việc triển khai nút chờ nóng của bạn có thể nằm trên một nhóm Galera Cluster khác sử dụng sao chép đồng bộ (kiểm tra blog này Zero Downtime Network Migration With MySQL Galera Cluster using Relay Node) hoặc bằng cách triển khai một nút MySQL / MariaDB không đồng bộ . Trong blog này, chúng tôi sẽ thiết lập và triển khai nút chờ nóng sao chép không đồng bộ từ một trong các nút Galera.
Thiết lập Cụm Galera
Trong thiết lập mẫu này, chúng tôi đã triển khai cụm 3 nút bằng cách sử dụng phiên bản MariaDB 10.4.8. Cụm này đang được triển khai ở khu vực Đông Hoa Kỳ (Ohio) và cấu trúc liên kết được hiển thị bên dưới:
Chúng tôi sẽ sử dụng máy chủ 172.31.26.175 làm máy chủ cho máy chủ không đồng bộ của mình sẽ đóng vai trò là nút chờ.
Thiết lập Phiên bản EC2 của bạn cho Nút chờ Nóng
Trong bảng điều khiển AWS, chuyển đến EC2 trong phần Tính toán và nhấp vào Khởi chạy phiên bản để tạo phiên bản EC2 giống như bên dưới.
Chúng tôi sẽ tạo phiên bản này ở vùng Tây Hoa Kỳ (Oregon). Đối với loại hệ điều hành của mình, bạn có thể chọn máy chủ mình thích (tôi thích Ubuntu 18.04 hơn) và chọn loại phiên bản dựa trên loại mục tiêu ưa thích của bạn. Đối với ví dụ này, tôi sẽ sử dụng t2.micro vì nó không yêu cầu bất kỳ thiết lập phức tạp nào và nó chỉ dành cho triển khai mẫu này.
Như chúng tôi đã đề cập trước đó, tốt nhất là nút chờ nóng của bạn được đặt ở một khu vực khác và không nằm chung hoặc trong cùng một khu vực. Vì vậy, trong trường hợp trung tâm dữ liệu khu vực gặp sự cố hoặc mất mạng, chế độ chờ nóng có thể trở thành mục tiêu chuyển đổi dự phòng của bạn khi mọi thứ trở nên tồi tệ.
Trước khi chúng ta tiếp tục, trong AWS, các khu vực khác nhau sẽ có Đám mây riêng ảo (VPC) và mạng riêng của vùng đó. Để giao tiếp với các nút cụm Galera, trước tiên chúng ta phải xác định một VPC Peering để các nút có thể giao tiếp trong cơ sở hạ tầng Amazon và không cần phải đi ra ngoài mạng, điều này chỉ làm tăng thêm các mối quan tâm về chi phí và bảo mật.
Trước tiên, hãy chuyển đến VPC của bạn từ nơi nút chờ nóng của bạn sẽ cư trú, sau đó đi tới Kết nối ngang hàng. Sau đó, bạn cần chỉ định VPC của nút chờ và VPC của cụm Galera. Trong ví dụ dưới đây, tôi có us-west-2 kết nối với us-west-2.
Sau khi tạo, bạn sẽ thấy một mục trong Kết nối ngang hàng của mình. Tuy nhiên, bạn cần chấp nhận yêu cầu từ VPC cụm Galera, nằm ở phía đông-2 chúng tôi trong ví dụ này. Xem bên dưới,
Sau khi được chấp nhận, đừng quên thêm CIDR vào bảng định tuyến. Xem blog bên ngoài này VPC Peering về cách thực hiện sau VPC Peering.
Bây giờ, hãy quay lại và tiếp tục tạo nút EC2. Đảm bảo Nhóm bảo mật của bạn có các quy tắc chính xác hoặc các cổng bắt buộc cần được mở. Kiểm tra hướng dẫn cài đặt tường lửa để biết thêm thông tin về điều này. Đối với thiết lập này, tôi chỉ đặt Tất cả lưu lượng truy cập được chấp nhận vì đây chỉ là một thử nghiệm. Xem bên dưới,
Đảm bảo rằng khi tạo phiên bản của mình, bạn đã đặt đúng VPC và bạn đã xác định mạng con thích hợp của bạn. Bạn có thể kiểm tra blog này trong trường hợp bạn cần một số trợ giúp về điều đó.
Thiết lập MariaDB Async Slave
Bước Một
Trước tiên, chúng ta cần thiết lập kho lưu trữ, thêm khóa kho và cập nhật danh sách gói trong bộ nhớ cache của kho lưu trữ,
$ vi /etc/apt/sources.list.d/mariadb.list
$ apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ apt updateBước Hai
Cài đặt gói MariaDB và các tệp nhị phân bắt buộc của nó
$ apt-get install mariadb-backup mariadb-client mariadb-client-10.4 libmariadb3 libdbd-mysql-perl mariadb-client-core-10.4 mariadb-common mariadb-server-10.4 mariadb-server-core-10.4 mysql-commonBước Ba
Bây giờ, hãy sao lưu bằng xbstream để chuyển các tệp vào mạng từ một trong các nút trong Cụm Galera của chúng ta.
## Xóa sạch datadir của MySQL mới được cài đặt trong nút chờ nóng của bạn.
$ systemctl stop mariadb
$ rm -rf /var/lib/mysql/*## Sau đó, trên nút chờ nóng, chạy nút này trên thiết bị đầu cuối,
$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | mbstream -x -C /var/lib/mysql## Sau đó, trên cái chính đích, tức là một trong các nút trong Cụm Galera của bạn (trong ví dụ này là nút 172.31.28.175), hãy chạy điều này trên thiết bị đầu cuối,
$ mariabackup --backup --target-dir=/tmp --stream=xbstream | socat - TCP4:172.32.31.2:9999trong đó 172.32.31.2 là IP của nút chờ máy chủ.
Bước Bốn
Chuẩn bị tệp cấu hình MySQL của bạn. Vì đây là trong Ubuntu, tôi đang chỉnh sửa tệp trong /etc/mysql/my.cnf và với my.cnf mẫu sau được lấy từ mẫu ClusterControl của chúng tôi,
[MYSQLD]
user=mysql
basedir=/usr/
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
pid_file=/var/lib/mysql/mysql.pid
port=3306
log_error=/var/log/mysql/mysqld.log
log_warnings=2
# log_output = FILE
#Slow logging
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=2
slow_query_log=OFF
log_queries_not_using_indexes=OFF
### INNODB OPTIONS
innodb_buffer_pool_size=245M
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_data_file_path = ibdata1:100M:autoextend
## You may want to tune the below depending on number of cores and disk sub
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_doublewrite=1
innodb_log_file_size=64M
innodb_log_buffer_size=16M
innodb_buffer_pool_instances=1
innodb_log_files_in_group=2
innodb_thread_concurrency=0
# innodb_file_format = barracuda
innodb_flush_method = O_DIRECT
innodb_rollback_on_timeout=ON
# innodb_locks_unsafe_for_binlog = 1
innodb_autoinc_lock_mode=2
## avoid statistics update when doing e.g show tables
innodb_stats_on_metadata=0
default_storage_engine=innodb
# CHARACTER SET
# collation_server = utf8_unicode_ci
# init_connect = 'SET NAMES utf8'
# character_set_server = utf8
# REPLICATION SPECIFIC
server_id=1002
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
report_host=172.31.29.72
gtid_ignore_duplicates=ON
gtid_strict_mode=ON
# OTHER THINGS, BUFFERS ETC
key_buffer_size = 24M
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 512M
# sort_buffer_size = 256K
# read_buffer_size = 256K
# read_rnd_buffer_size = 512K
# myisam_sort_buffer_size = 8M
skip_name_resolve
memlock=0
sysdate_is_now=1
max_connections=500
thread_cache_size=512
query_cache_type = 0
query_cache_size = 0
table_open_cache=1024
lower_case_table_names=0
# 5.6 backwards compatibility (FIXME)
# explicit_defaults_for_timestamp = 1
performance_schema = OFF
performance-schema-max-mutex-classes = 0
performance-schema-max-mutex-instances = 0
[MYSQL]
socket=/var/lib/mysql/mysql.sock
# default_character_set = utf8
[client]
socket=/var/lib/mysql/mysql.sock
# default_character_set = utf8
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
# default_character_set = utf8
[xtrabackup]
[MYSQLD_SAFE]
# log_error = /var/log/mysqld.log
basedir=/usr/
# datadir = /var/lib/mysqlTất nhiên, bạn có thể thay đổi điều này theo thiết lập và yêu cầu của mình.
Bước Năm
Chuẩn bị sao lưu từ bước # 3, tức là bản sao lưu kết thúc hiện đang ở nút chờ nóng bằng cách chạy lệnh bên dưới,
$ mariabackup --prepare --target-dir=/var/lib/mysqlBước Sáu
Đặt quyền sở hữu datadir trong nút chờ nóng,
$ chown -R mysql.mysql /var/lib/mysqlBước Bảy
Bây giờ, hãy bắt đầu phiên bản MariaDB
$ systemctl start mariadbBước 8
Cuối cùng, chúng ta cần thiết lập bản sao không đồng bộ,
## Tạo người dùng sao chép trên nút chính, tức là nút trong cụm Galera
MariaDB [(none)]> CREATE USER 'cmon_replication'@'172.32.31.2' IDENTIFIED BY 'PahqTuS1uRIWYKIN';
Query OK, 0 rows affected (0.866 sec)
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'cmon_replication'@'172.32.31.2';
Query OK, 0 rows affected (0.127 sec)## Nhận vị trí nô lệ GTID từ xtrabackup_binlog_info như sau,
$ cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000002 71131632 1000-1000-120454## Sau đó thiết lập bản sao nô lệ như sau,
MariaDB [(none)]> SET GLOBAL gtid_slave_pos='1000-1000-120454';
Query OK, 0 rows affected (0.053 sec)
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.31.28.175', MASTER_USER='cmon_replication', master_password='PahqTuS1uRIWYKIN', MASTER_USE_GTID = slave_pos;## Bây giờ, hãy kiểm tra trạng thái nô lệ,
MariaDB [(none)]> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.31.28.175
Master_User: cmon_replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File:
Read_Master_Log_Pos: 4
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 4
Relay_Log_Space: 256
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1000
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 1000-1000-120454
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 0
1 row in set (0.000 sec)Thêm nút chờ nóng của bạn vào ClusterControl
Nếu bạn đang sử dụng ClusterControl, thật dễ dàng theo dõi tình trạng máy chủ cơ sở dữ liệu của bạn. Để thêm cái này làm nô lệ, hãy chọn cụm nút Galera mà bạn có, sau đó đi tới nút chọn như hình dưới đây để Thêm Nô lệ sao chép:
Nhấp vào Add Replication Slave và chọn thêm một nô lệ hiện có giống như bên dưới,
Cấu trúc liên kết của chúng tôi có vẻ đầy hứa hẹn.
Như bạn có thể nhận thấy, nút 172.32.31.2 của chúng tôi đóng vai trò là chế độ chờ nóng của chúng tôi nút có CIDR khác có tiền tố là 172,32.% us-west-2 (Oregon) trong khi các nút khác là 172,31.% nằm ở us-west-2 (Ohio). Chúng hoàn toàn nằm trên các khu vực khác nhau, vì vậy trong trường hợp lỗi mạng xảy ra trên các nút Galera của bạn, bạn có thể chuyển đổi dự phòng sang nút chờ nóng của mình.
Kết luận
Xây dựng Chế độ chờ nóng trên Amazon AWS thật dễ dàng và đơn giản. Tất cả những gì bạn cần là xác định các yêu cầu về dung lượng và cấu trúc liên kết mạng, bảo mật và các giao thức cần được thiết lập.
Sử dụng VPC Peering giúp tăng tốc độ liên lạc giữa các khu vực khác nhau mà không cần đến Internet công cộng, do đó kết nối vẫn nằm trong cơ sở hạ tầng mạng Amazon.
Tất nhiên, sử dụng sao chép không đồng bộ với một nô lệ là chưa đủ, nhưng blog này đóng vai trò là nền tảng về cách bạn có thể bắt đầu điều này. Giờ đây, bạn có thể dễ dàng tạo một cụm khác nơi nô lệ không đồng bộ đang sao chép và tạo một chuỗi Galera Cluster khác đóng vai trò là các nút Khôi phục sau thảm họa của bạn hoặc bạn cũng có thể sử dụng biến gmcast.segment trong Galera để sao chép đồng bộ giống như những gì chúng tôi có trên blog này.
