MariaDB Advance: MariaDB Replication

Replication là một tính năng cho phép nội dung của một hoặc nhiều máy chủ (được gọi là masters) được nhân đôi trên một hoặc nhiều máy chủ (được gọi là slaves).

Bạn có thể kiểm soát dữ liệu nào cần sao chép. Tất cả các cơ sở dữ liệu, một hoặc nhiều cơ sở dữ liệu hoặc các bảng trong cơ sở dữ liệu đều có thể được sao chép một cách chọn lọc.

Cơ chế chính được sử dụng trong nhân rộng là binary log . Nếu binary log được bật, tất cả các cập nhật cho cơ sở dữ liệu (thao tác dữ liệu và định nghĩa dữ liệu) được ghi vào binary log dưới dạng binlog events. Các Slaves đọc binary log từ mỗi master truy cập dữ liệu để sao chép. Một relay log được tạo ra trên slave server, sử dụng định dạng giống như các binary log, và điều này được sử dụng để thực hiện sao chép. Các tệp nhật ký chuyển tiếp cũ được gỡ bỏ khi không còn cần thiết.

Một slave server theo dõi vị trí trong binlog master’s binlog  của sự kiện cuối cùng được áp dụng trên slave. Điều này cho phép slave server kết nối lại và tiếp tục lại từ nơi nó dừng lại sau khi quá trình sao chép tạm thời bị dừng lại. Nó cũng cho phép một slave ngắt kết nối, được nhân bản và sau đó có bản sao tiếp tục slave mới từ cùng một chủ master.

Masters và slaves không cần phải liên lạc với nhau. Hoàn toàn có thể đưa máy chủ ngoại tuyến hoặc ngắt kết nối khỏi mạng và khi chúng quay trở lại, việc sao chép sẽ tiếp tục ở nơi nó dừng lại.

Khi nào thì nên dùng Replication

Replication được sử dụng trong một số tình huống phổ biến. Sử dụng bao gồm:

  • Khả năng mở rộng: Bằng cách có một hoặc nhiều máy chủ slave, việc đọc có thể được trải rộng trên nhiều máy chủ, giảm tải cho master. Kịch bản phổ biến nhất cho môi trường đọc cao, viết thấp là có một chủ, trong đó tất cả các ghi xảy ra, sao chép thành nhiều nô lệ, xử lý hầu hết các lần đọc.
  • Phân tích dữ liệu: Phân tích dữ liệu có thể có quá nhiều ảnh hưởng đến máy chủ master và điều này có thể được xử lý tương tự trên máy chủ slave, trong khi master vẫn tiếp tục không bị ảnh hưởng bởi tải thêm.
  • Hỗ trợ sao lưu: Sao lưu có thể dễ dàng chạy hơn nếu máy chủ không chủ động thay đổi dữ liệu. Một kịch bản phổ biến là sao chép dữ liệu về slave, sau đó bị ngắt kết nối với master với dữ liệu ở trạng thái ổn định. Sao lưu sau đó được thực hiện từ máy chủ này.
  • Phân phối dữ liệu: Thay vì được kết nối với một master từ xa, thay vào đó, có thể sao chép dữ liệu cục bộ và làm việc từ dữ liệu này.

Các mô hình thết lập Replication

Standard Replication

standard_replication

  • Cung cấp quy mô đọc vô hạn.
  • Cung cấp tính sẵn sàng cao bằng cách nâng cấp  slave to master.

Ring Replication

ring_replication

  • Cung cấp đọc và viết tỷ lệ.
  • Không xử lý xung đột.
  • Nếu một chủ thất bại, nhân rộng dừng lại.

Star Replication

star_replication

  • Cung cấp đọc và viết tỷ lệ.
  • Không xử lý xung đột.
  • Phải sử dụng các bộ lọc sao chép để tránh trùng lặp dữ liệu.

Multi-Source Replication

multi_source_replication

  • Cho phép bạn kết hợp dữ liệu từ các nguồn khác nhau.
  • Các miền khác nhau được thực hiện độc lập song song trên tất cả các nô lệ.

Thiết lập Replication

Chú ý là Replication nên chỉ thiết lập khi  master và slave chạy trên cùng một phiên bản hoặc phiên bản slave mới hơn phiên bản master. Trường hợp máy chủ master có phiên bản cao hơn máy chủ slave thì Replication sẽ không tương thích.

Thiết lập trên server master.

  • Cho phép ghi binary log nếu nó chưa được kích hoạt
  • Cung cấp cho chủ master server_id duy nhất . Tất cả slave cũng phải được cung cấp một server_id. Đây có thể là một số từ 1 đến 232-1 và phải là duy nhất cho mỗi máy chủ trong nhóm replicating.
  • Chỉ định một tên duy nhất cho nhật ký replication với –log-basename . Nếu điều này không được chỉ định, tên hostname máy chủ của bạn sẽ được sử dụng và sẽ có vấn đề nếu tên máy chủ thay đổi.
  • Các Slaves sẽ cần sự cho phép để kết nối và bắt đầu sao chép từ một máy chủ. Thông thường, điều này được thực hiện bằng cách tạo một người dùng slave chuyên dụng và chỉ cấp quyền cho người dùng đó để sao chép (REPLICATION SLAVE permission).

Các lệnh dưới đây  sẽ thiết lập trên máy chủ Master, trước tiên ta thêm các cấu hình sau vào file my.cnf máy chủ master

[mariadb]
log-bin
server_id=1
log-basename=master1

# cấu hình dưới đây cho phép các kết nối ngoài vào server.
skip-networking=0
skip-bind-address

Sau khi restart lại MariaDB trên máy chủ master, chúng ta truy cập MariaDB và khởi tạo user cho phép chỉ đọc để phục vụ replication.

# khởi tạo user
CREATE USER 'replication_user'@'%' IDENTIFIED BY 'Mật_khẩu';
# cấp quyền REPLICATION cho user vừa tạo ở trên
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';
#Flush quyền
FLUSH PRIVILEGES;

Có một số tùy chọn có thể ảnh hưởng hoặc phá vỡ nhân rộng. Kiểm tra các cài đặt sau để tránh các vấn đề.

  • skip-networking. Nếu skip-networking=1 . máy chủ sẽ giới hạn kết nối chỉ với localhost và ngăn tất cả các slaves từ xa kết nối.
  • bind-address. Tương tự, nếu địa chỉ máy chủ lắng nghe các kết nối TCP / IP là 127.0.0.1 (localhost), các kết nối slaves từ xa sẽ thất bại.

 

Thiết lập trên server slave

Cung cấp cho slave một server_id duy nhất. Tất cả các máy chủ, cho dù là master hay slave, đều được cung cấp server_id. Đây có thể là một số từ 1 đến 232-1 và phải là duy nhất cho mỗi máy chủ trong replication. Máy chủ sẽ cần phải được khởi động lại để thay đổi trong tùy chọn này có hiệu lực.

Thiết lập trong file my.cnf của máy chủ slave

[mariadb]
server-id = 2

Sau khi restart lại MariaDB  là chúng ta đã khởi tạo slave hoàn tất. Công việc tiếp theo là chúng ta quay trở lại máy chủ master và lấy được tạo độ của binary log .

Lấy tọa độ Binary Log của Master

Bây giờ bạn cần ngăn chặn mọi thay đổi đối với dữ liệu trong khi bạn xem vị trí binary log. Bạn sẽ sử dụng điều này để nói với slave chính xác điểm nào sẽ bắt đầu sao chép dữ liệu.

  • Trên master, flush and lock tất cả các bảng bằng cách chạy FLUSH TABLES WITH READ LOCK.
  • Lấy vị trí hiện tại trong binary log bằng cách chạy SHOW MASTER STATUS:
MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| master1-bin.000003 |      344 |              |                  |
+--------------------+----------+--------------+------------------+
1 row in set (0.001 sec)
  • Ghi lại chi tiết File và Position
  • Bây giờ, Khi vẫn đang lock tables, chúng ta sao chép dữ liệu từ master sang sang slave. Xem Sao lưu, Khôi phục để biết chi tiết về cách thực hiện việc này.
  • Lưu ý cho live database(database đang phục vụ): Bạn chỉ cần tạo một bản sao dữ liệu, bạn không cần phải lock tables cho đến khi slave đã nhập dữ liệu.
  • Khi dữ liệu đã được sao chép, bạn có thể giải phóng lock tables trên máy chủ master bằng cách chạy UNLOCK TABLES
    # nhớ chạy lệnh dưới đây sau khi database đã được import trên máy chủ slave
    UNLOCK TABLES;

     

Bắt đầu slave

Khi dữ liệu đã được import, bạn đã sẵn sàng bắt đầu replication. Bắt đầu bằng cách chạy  CHANGE MASTER TO , đảm bảo rằng MASTER_LOG_FILE khớp với tệp và MASTER_LOG_POS vị trí được trả về bởi SHOW MASTER STATUS trước đó. Ví dụ:

MariaDB [(none)]> STOP SLAVE;
MariaDB [(none)]> CHANGE MASTER TO
  MASTER_HOST='IP_server_master',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='Mật _khẩu_user_replication_đã_tạo_trước_đó',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='master1-bin.000003',
  MASTER_LOG_POS=344,
  MASTER_CONNECT_RETRY=10;

Sau khi thiết lập hoàn tất, bạn có thể start slave và kiểm tra replication

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.000 sec)

MariaDB [(none)]> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 103.130.218.7
                   Master_User: replication_user
                   Master_Port: 3306
                 Connect_Retry: 10
               Master_Log_File: master1-bin.000003
           Read_Master_Log_Pos: 477
                Relay_Log_File: slave-relay-bin.000002
                 Relay_Log_Pos: 690
         Relay_Master_Log_File: master1-bin.000003
              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: 477
               Relay_Log_Space: 999
               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: 1
                Master_SSL_Crl:
            Master_SSL_Crlpath:
                    Using_Gtid: No
                   Gtid_IO_Pos:
       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: 1
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 0
1 row in set (0.000 sec)

Nếu bạn thấy 2 dòng  running như sau thì replication đã được cấu hình hoàn tất

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

 

Related Articles