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

Cách thay thế MySQL hoặc MariaDB Master trung gian bằng máy chủ Binlog sử dụng MaxScale

Nhật ký nhị phân (binlog) chứa các bản ghi của tất cả các thay đổi đối với cơ sở dữ liệu. Chúng cần thiết để sao chép và cũng có thể được sử dụng để khôi phục dữ liệu sau khi sao lưu. Máy chủ binlog về cơ bản là một kho lưu trữ nhật ký nhị phân. Bạn có thể nghĩ về nó giống như một máy chủ với mục đích chuyên dụng để truy xuất nhật ký nhị phân từ một máy chủ, trong khi các máy chủ phụ có thể kết nối với nó giống như chúng sẽ kết nối với một máy chủ chính.

Một số ưu điểm của việc sử dụng máy chủ binlog trên máy chủ trung gian để phân phối khối lượng công việc sao chép là:

  • Bạn có thể chuyển sang một máy chủ chính mới mà không cần nô lệ nhận thấy rằng máy chủ chính thực sự đã thay đổi. Điều này cho phép thiết lập sao chép có tính khả dụng cao hơn trong đó việc nhân rộng được ưu tiên cao.
  • Giảm tải cho trang cái bằng cách chỉ phân phát máy chủ binlog của Maxscale thay vì tất cả các máy chủ.
  • Dữ liệu trong nhật ký nhị phân của bản chính trung gian không phải là bản sao trực tiếp của dữ liệu đã nhận được từ nhật ký nhị phân của bản chính thực. Do đó, nếu sử dụng cam kết nhóm, điều này có thể làm giảm tính song song của các cam kết và giảm hiệu suất của các máy chủ phụ.
  • Máy chủ trung gian phải thực thi lại mọi câu lệnh SQL, điều này có thể gây thêm độ trễ và độ trễ cho chuỗi sao chép.

Trong bài đăng blog này, chúng ta sẽ xem xét cách thay thế một máy chủ trung gian (một máy chủ nô lệ chuyển tiếp cho các máy chủ nô lệ khác trong một chuỗi sao chép) bằng một máy chủ binlog chạy trên MaxScale để có khả năng mở rộng và hiệu suất tốt hơn .

Kiến trúc

Về cơ bản, chúng ta có thiết lập bản sao MariaDB v10.4 4 nút với một MaxScale v2.3 nằm trên đầu bản sao để phân phối các truy vấn đến. Chỉ một nô lệ được kết nối với một cái chính (cái chính trung gian) và các nô lệ khác sao chép từ cái chính trung gian để phục vụ khối lượng công việc đọc, như được minh họa trong sơ đồ sau.

Chúng tôi sẽ chuyển cấu trúc liên kết trên thành thế này:

Về cơ bản, chúng tôi sẽ xóa vai trò chính trung gian và thay thế bằng một máy chủ binlog đang chạy trên MaxScale. Chủ trung gian sẽ được chuyển đổi thành nô lệ tiêu chuẩn, giống như các máy chủ nô lệ khác. Dịch vụ binlog sẽ nghe trên cổng 5306 trên máy chủ MaxScale. Đây là cổng mà tất cả các nô lệ sẽ kết nối để nhân rộng sau này.

Định cấu hình MaxScale làm Máy chủ Binlog

Trong ví dụ này, chúng ta đã có một MaxScale nằm trên cùng của cụm sao của chúng ta hoạt động như một bộ cân bằng tải cho các ứng dụng của chúng ta. Nếu bạn không có MaxScale, bạn có thể sử dụng ClusterControl để triển khai, chỉ cần vào Cluster Actions -> Add Load Balancer -> MaxScale và điền các thông tin cần thiết như sau:

Trước khi bắt đầu, hãy xuất cấu hình MaxScale hiện tại thành tệp văn bản để sao lưu. MaxScale có một cờ gọi là --export-config cho mục đích này nhưng nó phải được thực thi với tư cách người dùng maxscale. Do đó, lệnh để xuất là:

$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscale

Trên MariaDB master, tạo một người dùng nô lệ nhân bản có tên là 'maxscale_slave' để MaxScale sử dụng và gán nó với các đặc quyền sau:

$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';

Đối với người dùng ClusterControl, hãy chuyển đến Manage -> Schemas and Users để tạo các đặc quyền cần thiết.

Trước khi chúng tôi tiến xa hơn với cấu hình, điều quan trọng là phải xem lại trạng thái hiện tại và cấu trúc liên kết của các máy chủ phụ trợ của chúng tôi:

$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address      │ Port │ Connections │ State                        │ GTID      │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0           │ Master, Running              │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0           │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running               │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running               │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘

Như chúng ta có thể thấy, cái chính hiện tại là DB_757 (192.168.0.90). Hãy lưu ý thông tin này vì chúng tôi sẽ thiết lập máy chủ binlog để sao chép từ cái này.

Mở tệp cấu hình MaxScale tại /etc/maxscale.cnf và thêm các dòng sau:

[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master

[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0

Giải thích một chút - Chúng tôi đang tạo hai thành phần - dịch vụ và trình nghe. Dịch vụ là nơi chúng tôi xác định đặc tính máy chủ binlog và cách nó sẽ chạy. Thông tin chi tiết về mọi tùy chọn có thể được tìm thấy tại đây. Trong ví dụ này, các máy chủ sao chép của chúng tôi đang chạy với tính năng sao chép bán đồng bộ, do đó chúng tôi phải sử dụng semisync =true để nó sẽ kết nối với máy chủ thông qua phương thức sao chép bán đồng bộ hóa. Trình nghe là nơi chúng tôi ánh xạ cổng nghe với dịch vụ binlogrouter bên trong MaxScale.

Khởi động lại MaxScale để tải các thay đổi:

$ systemctl restart maxscale

Xác minh rằng dịch vụ binlog đã được khởi động thông qua maxctrl (xem cột Trạng thái):

$ maxctrl show service replication-service

Xác minh rằng MaxScale hiện đang lắng nghe một cổng mới cho dịch vụ binlog:

$ netstat -tulpn | grep maxscale
tcp        0 0 0.0.0.0:3306            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 0.0.0.0:3307            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 0.0.0.0:5306            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 127.0.0.1:8989          0.0.0.0:* LISTEN   4850/maxscale

Giờ đây, chúng tôi đã sẵn sàng thiết lập liên kết sao chép giữa MaxScale và bản chính.

Kích hoạt Máy chủ Binlog

Đăng nhập vào máy chủ chính MariaDB và truy xuất tệp binlog hiện tại và vị trí:

MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 |     4204 |              |                  |
+---------------+----------+--------------+------------------+

Sử dụng hàm BINLOG_GTID_POS để nhận giá trị GTID:

MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31                             |
+----------------------------------------+

Quay lại máy chủ MaxScale, cài đặt gói ứng dụng khách MariaDB:

$ yum install -y mysql-client

Kết nối với trình xử lý máy chủ binlog trên cổng 5306 với tư cách là người dùng maxscale_slave và thiết lập liên kết sao chép tới bản chính được chỉ định. Sử dụng giá trị GTID được truy xuất từ ​​cái chính:

(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                 Slave_IO_State: Binlog Dump
                  Master_Host: 192.168.0.90
                  Master_User: maxscale_slave
                  Master_Port: 3306
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
             Master_Server_Id: 38001
             Master_Info_File: /var/lib/maxscale/binlogs/master.ini
      Slave_SQL_Running_State: Slave running
                  Gtid_IO_Pos: 0-38001-31

Lưu ý:Kết quả ở trên đã bị cắt bớt để chỉ hiển thị những dòng quan trọng.

Trỏ các Nô lệ đến Máy chủ Binlog

Bây giờ trên mariadb2 và mariadb3 (các nô lệ cuối), hãy thay đổi trang cái trỏ tới máy chủ binlog MaxScale. Vì chúng tôi đang chạy với tính năng sao chép bán đồng bộ hóa được bật, trước tiên chúng tôi phải tắt chúng đi:

(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.95
                   Master_User: maxscale_slave
                   Master_Port: 5306
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
              Master_Server_Id: 9999
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-38001-32
       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Lưu ý:Kết quả ở trên đã bị cắt bớt để chỉ hiển thị những dòng quan trọng.

Bên trong my.cnf, chúng tôi phải nhận xét các dòng sau để tắt tính năng bán đồng bộ hóa trong tương lai:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

Tại thời điểm này, bản chính trung gian (mariadb1) vẫn đang sao chép từ bản chính (mariadb0) trong khi các nô lệ khác đang sao chép từ máy chủ binlog. Cấu trúc liên kết hiện tại của chúng tôi có thể được minh họa như sơ đồ dưới đây:

Phần cuối cùng là thay đổi trỏ chính của trang cái trung gian (mariadb1 ) sau khi tất cả các nô lệ từng gắn bó với nó không còn ở đó nữa. Các bước về cơ bản giống với các nô lệ khác:

(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.95
                   Master_User: maxscale_slave
                   Master_Port: 5306
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
              Master_Server_Id: 9999
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-38001-32

Lưu ý:Kết quả ở trên đã bị cắt bớt để chỉ hiển thị những dòng quan trọng.

Đừng quên tắt tính năng sao chép bán đồng bộ hóa trong my.cnf:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

Chúng tôi có thể xác minh dịch vụ bộ định tuyến binlog hiện có nhiều kết nối hơn thông qua maxctrl CLI:

$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service             │ Router         │ Connections │ Total Connections │ Servers                           │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service          │ readwritesplit │ 1           │ 1                 │ DB_757, DB_758, DB_759, DB_760    │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service          │ readconnroute  │ 1           │ 1                 │ DB_757, DB_758, DB_759, DB_760    │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter   │ 4           │ 51                │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘

Ngoài ra, các lệnh quản trị sao chép phổ biến có thể được sử dụng bên trong máy chủ binlog MaxScale, ví dụ:chúng ta có thể xác minh các máy chủ nô lệ được kết nối bằng cách sử dụng lệnh này:

(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host         | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003     | 192.168.0.92 | 3306 | 9999      |            |
| 38002     | 192.168.0.91 | 3306 | 9999      |            |
| 38004     | 192.168.0.93 | 3306 | 9999      |            |
+-----------+--------------+------+-----------+------------+

Tại thời điểm này, cấu trúc liên kết của chúng tôi trông giống như những gì chúng tôi dự đoán:

Quá trình di chuyển của chúng tôi từ thiết lập chính trung gian sang thiết lập máy chủ binlog hiện đã hoàn tất.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Trừ Microseconds cho một giá trị ngày giờ trong MariaDB

  2. Hình ảnh Docker phổ biến cho MySQL và MariaDB Server

  3. Cách LN () hoạt động trong MariaDB

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

  5. Cách UPPER () hoạt động trong MariaDB