tiểu luận replication in MySQL

Giới thiệu chung về Replication Là nền tảng cho các ứng dụng lớn, tốc độ xử lý cao, sử dụng "kiến trúc tăng trưởng"  Cho phép cấu hình 1 hoặc nhiều server như 1 bản sao của bản gốc, gi

Replication in MySQLREADING TOPIC 3 – NHÓM 4

1 Giới thiệu chung về Replication

1 Giới thiệu chung về Replication

 Là nền tảng cho các ứng dụng lớn, tốc độ xử lý cao, sử dụng "kiến trúc tăng trưởng"

 Cho phép cấu hình 1 hoặc nhiều server như 1 bản sao của bản gốc, giữ sự đồng bộ dữ liệu giữa 2 server

 Hiệu quả với ứng dụng cần hiệu năng cao, tinh sẵn sàng cao, có tính khôi phục thảm họa

 Đồng bộ hóa server gốc - những replica, 1 server - nhiều rep

 MySQL hỗ trợ 2 loại rep: Statement-based và row-based replication

 Replication không có tính tương thích ngược

 Không tăng nhiều gánh nặng cho master nhưng đòi hỏi tính năng binery-logging

 Scaling reads tốt nhưng scaling writes thì không

 Rất hao phí tài nguyên với nhiều replica do sự trùng lặp data

1 Giới thiệu chung về Replication

 1.1 - Những vấn đề Replication giải quyết

 Data distribution

 Load balancing

 High availibility ailover

 Testing MySQL upgrades

1 Giới thiệu chung về Replication

1.2 - Cách hoạt động của Replication

Gồm 3 phần chính:

 Master ghi lại thay đổi của data

trong binary log(những record này

được gọi là binary log events)

 Rep copy BLE của master vào log

của chính nó

 Rep chạy lại các event trong log và

update vào data của chính nó

2 Setting up Replication

2 Setting up Replication

 Có nhiều biến thể về các bước tùy vào tình huống Tình huống cơ bản nhất là master và rep mới được cài đặt Bao gồm 3 bước:

- Set up các tài khoản replication ở mỗi server

- Cấu hình master và rep

- Lập trình cho rep kết nối và sao chép từ master

 Master và rep có cùng 1 database

2 Setting up Replication

 2.1 Creating replication accounts

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* -> TO repl@'192.168.0' IDENTIFIED BY 'p4ssword',;

 2 2 Configuring Master and Replica

- Enable binary logging và đặt ra 1 server ID

log_bin = mysql-bin

server_id = 10

- kiểm tra, chạy SHOW MASTER STATUS

- Cấu hình rep trong my.cnf cũng phải giống với master

2 Setting up Replication

 2.3 Starting the replica

- Cấu hình rep kết nối với master và bắt đầu replay binary log

- Bắt đầu replication: mysql> START SLAVE

- Check slave status:

- Kiểm tra kết nối từ slave với

SHOW SLAVE STATUS

- Xem kết nối bên server master

- Xem kết nối bên server master

2 Setting up Replication

 2.4 Initializing a replica from another server

- Thực tế, master sẽ chạy được 1 thời gian và ta cần đồng bộ data của rep và master mặc dù rep

chưa có data của master

- Trước hết cần đồng bộ rep và master,cần 3 bước:

• 1 snapshot từ data của master ở 1 thời điểm nhất định

• FIle log hiện tại của master,số byte mặc định trong log vào thời điểm chụp snapshot

• Những file binary log của master từ thời điểm snapshot đến hiên tại

- Một số cách clone rep từ server khác:

. with a cold copy . with a warm copy . using mysqldump

. using snapshot or backup . with Percorna XTraBackup . from another replica

2 Setting up Replication

 2.5 Recommended Replication configuration

- Cấu hình rep có rất nhiều tham số đầu vào, mỗi cái đều có ảnh hưởng đến an toàn dữ liệu

và hiệu năng Sau đây là cấu hình rep an toàn đề nghị:

• sync_binlog = 1

• Khuyến khích dùng InnoDB nếu không muốn các bảng bị hỏng sau crash

• Những tính năng mặc định có ở MySQL 5.0 trở lên Khuyến khích đặt tên cho binary log thay vì để mặc định theo tên server, việc này sẽ gây rắc rối cho quá trình copy data, clone reps và backup

2 Setting up Replication

• Đưa ra đường dẫn tuyệt đối để tránh 1 số bug

trong 1 số phiên bản MySQL khiến relay log

được tạo ở 1 vị trí khác Skip_slave_start khiến

rep không tự động chạy lại sau crash, khiến ta

có thể sửa lỗi trên server, nếu rep tự động bắt

đầu sau crash, nó có thể sinh ra thêm lỗi

Read_only ngăn không cho users thay đổi các

3 REPLICATION

UNDER THE HOOD

3 REPLICATION UNDER THE HOOD

Statement-based replication

 Statement-based replication(SBR) hoạt động

bằng cách ghi lại truy vấn đã thay đổi dữ liệu

trên cơ sở dữ liệu gốc (master) Khi cơ sở dữ

liệu bản sao (replicas) đọc sự kiện từ nhật kí

chuyển tiếp (relay log) và thực thi, nó sẽ chạy

lại câu truy vấn SQL mà cơ sở dữ liệu gốc chạy

Row-based replication

 MySQL 5.1 thêm hỗ trợ cho RBR, ghi lại sự thay đổi dữ liệu trong binary log và thực hiện tạo bản sao ( Phương thức RBR, binary log lưu trữ bản ghi mức độ thay đổi xảy ra với bảng cơ sở dữ liệu của máy chủ gốc Bản sao sẽ đọc dữ liệu này và điều chỉnh bản ghi của nó theo bản ghi của cơ sở

dữ liệu gốc)

 3.1 Statement-based (logical) replication và Row-based replication

3 REPLICATION UNDER THE HOOD

Lợi ích việc sửu dụng SBR

3 REPLICATION UNDER THE HOOD

 Statement-based replication

advantages:

 Logical replication hoạt động trên các

trường hợp sơ đồ trên bản gốc và

bản sao khác nhau

 Mọi sự thay đổi trên máy chủ diễn ra

thông qua cơ chế dễ hiểu, và dễ giám

sát, xác định những gì hoạt động và

không hoạt động như mong đợi

 Statement-based replication disadvantages:

 Danh sách thứ không thể sao chép chính xác thông qua statement-based logging rất lớn

 Đồng thời cũng có rất nhiều lỗi với bảng tạm thời, cấu trúc SQL đặc biệt,

…

 3.2 Statement-Based or Row-Based: Which Is Better?

3 REPLICATION UNDER THE HOOD

 Row-based replication advantages:

 RBR hoạt động tốt với tất cả các cấu trúc SQL, trigger,

stored procedure

 Nó cũng tạo ra cơ hội để giảm locking

 RBR hoạt động dựa vào việc ghi lại dữ liệu đã thay

đổi, binary log là bản ghi những gì thay đổi trên

master

 RBR có thể ít tốn CPU hơn trong nhiều trường hợp,

do không cần lập kế hoạch và thực hiện các truy vấn

theo cùng một cách mà SBR làm

 RBR có thể giúp bạn tìm và giải quyết sự không nhất

quán của dữ liệu nhanh hơn trong một số trường hợp

 Row-based replication disadvantages:

 RBR có thể giúp bạn tìm và giải quyết sự không nhất quán của dữ liệu nhanh hơn trong một số trường hợp

 Trên thực tế, quá trình áp dụng các thay đổi dựa trên hàng (row-based changes) là hộp đen không

có khả năng hiển thị về những gì máy chủ đang làm

và nó không được ghi chép hoặc giải thích đầy đủ

 RBR không thể xử lý một số việc mà ghi nhật ký dựa trên câu lệnh (statement-based logging) có thể, chẳng hạn như các thay đổi giản đồ(schema) trên các bản sao

3.4 Sending Replication

Events to Other Replicas

- Tùy chọn log_slave_updates cho phép bạn sử dụng một bản sao làm bản sao chính của các bản sao khác Nó hướng dẫn MySQL viết các

sự kiện mà luồng SQL sao chép thực thi vào binary log của chính nó, mà các bản sao của chính nó sau đó có thể truy xuất và thực thi

- Cấu hình này có nghĩa là các thay đổi trên bản gốc ban đầu có thể truyền sang các bản sao không được gắn trực tiếp với nó Việc đặt log _slave_updates theo mặc định cho phép bạn kết nối bản sao mà không cần phải khởi động lại máy chủ

3 REPLICATION UNDER THE HOOD

Có hai loại bộ lọc sao chép: loại lọc các sự kiện ra khỏi binary log

trên master và bộ lọc các sự kiện đến từ relay log trên bản sao

Trên bản sao(replica), các tùy chọn replicate_ * lọc các sự kiện khi

luồng SQL sao chép đọc chúng từ relay log Bạn có thể sao chép

hoặc bỏ qua một hoặc nhiều cơ sở dữ liệu, viết lại một cơ sở dữ

liệu này sang cơ sở dữ liệu khác và sao chép hoặc bỏ qua các bảng

mysql> USE test;

mysql> DELETE FROM sakila.film

các tham số * _do_db và * _ignore_db sẽ lọc câu lệnh DELETE trên

test, không lọc trên sakila Đây thường không phải là điều bạn

muốn và nó có thể khiến các câu lệnh sai bị sao chép hoặc bị bỏ

qua

 3.5 Relication Filters

4 Replication Topologies

4 Replication Topologies

Bạn có thể thiết lập tạo bản saoMySQL cho hầu hết mọi cấu hình của bản chính(master)

và bản sao(replica), với giới hạn là một bản sao MySQL nhất định chỉ có thể có một bản chính Có thể có nhiều cấu trúc liên kết phức tạp, nhưng ngay cả những cấu trúc liên kết đơn giản cũng có thể rất linh hoạt

 Một số qui tắc cơ bản cần nhớ:

- Một bản sao(replica) chỉ có 1 bản gốc(master)

- Mỗi bản sao cần có ID server riêng biệt

- Một master có nhiều bản sao(replicas)

- Một bản sao có thể truyền các thay đổi từ bản gốc của nó và là bản gốc của các bản sao khác, nếu bạn bật log_slave_updates

Master and Multiple Replicas

Cấu hình này hữu ích nhất khi bạn ghi ít và đọc nhiều Bạn có thể thiết lập nhiều bản sao cùng một lúc

hoặc thêm các bản sao khi bạn cần

Master-Master in Active-Active Mode

Sao chép master - master (còn được gọi là nhân bản hai chiều) liên quan đến hai server, mỗi server được cấu hình vừa là máy chủ vừa là bản sao của server kia

Master-Master in Active-Passive Mode

Cấu hình này cho phép bạn hoán đổi vai trò máy chủ active và passive qua lại rất dễ dàng, vì cấu hình của máy chủ là đối xứng Điều này giúp cho việc chuyển đổi dự phòng và sao lưu dự phòng trở nên dễ dàng Nó cũng cho phép bạn thực hiện bảo trì, tối ưu hóa bảng, nâng cấp hệ điều hành (hoặc ứng dụng hoặc phần cứng) và thực hiện các tác vụ khác mà không mất thời gian

Master-Master with Replicas

Ưu điểm của cấu hình này là có thêm khả năng dự phòng

Có thể thăng cấp một trong các bản sao để thay thế bản

chính bị lỗi, mặc dù nó phức tạp hơn một chút

Ring Replication

Sao chép liên kết vòng không có một số lợi ích chính của thiết lập master-master, chẳng hạn như cấu hình đối xứng và chuyển đổi dự phòng dễ dàng Nói chung, liên kết vòng dễ lỗi và tốt nhất nên tránh, cho dù bạn có khéo léo đến đâu.

Master, Distribution Master, and Replicas

Nếu có nhiều bản sao và có một sự kiện

binary log đặc biệt lớn Master thậm chí

 Emulating multisource replication

 Creating a log server

5 Replication and Capacity planning

5 Replication and Capacity planning

Việc ghi luôn được ví như là cái nút cổ chai đối với việc sao lưu, nó rất khó để mở rộng phạm vi ghi bằng replication Cần phải tính toán chính xác khi hoạch định công suất của các bản sao sẽ được thêm vào hệ thống

 5.1 When will replication begin to lag?

 Để ý đến sự thay đổi thất thường trong độ trễ

 Để dự đoán điều sẽ xảy ra trong một vài thời điểm ,

tạm thời dừng bản sao và xem nó có thể bắt kíp trở lại

với tốc độ ra sao

 Sử dụng Percona Server và MariaDB để tính toán trực tiếp

5 Replication and Capacity planning

 5.2 Plan to Underutilize

 Chủ đích sử dụng server dưới công suất tối đa có thể là một cách làm thông

minh và tiết kiệm chi phí để xây dựng những ứng dụng lớn, đặc biệt là khi sử

dụng replication

 Cố gắng hạn chế replication pelnaty bằng cách ghi lên cả 2 phía trong giao thức ngang hàng là không phù hợp về mặt chi phí Cần phải chạy cả 2 dưới 50% đối với các câu lệnh đọc bởi nếu không, trong trường hợp 1 server xảy ra sự cố thì thì sẽ không đủ không gian để chạy tiếp

 Xây dựng hệ thống có công suất vượt quá công suất cần thiết cũng là một trong những cách tốt nhất để đạt được tính sẵn sàng cao

6 Replication

Administration and Maintenance

6 Replication Administration and Maintenance

 6.1 Monitoring Replication

 Dùng câu truy vấn ‘SHOW MASTER STATUS’ để xem

vị trí và cấu hình của các file binary log trên bản gốc

 Dùng câu truy vấn “SHOW MASTER LOGS” để xem

được các file binary log nào đang tồn tại trên ổ đĩa

 Xem các sự kiện sao lưu có trong binary log

bằng câu lệnh

6 Replication Administration and Maintenance

 6.2 Measuring Replication Lag

 Một trong những điều mà ta cần để ý tới là bản sao chạy chậm hơn bản gốc bao lâu Dù cho ở cột Second_behind_master trong SHOW SLAVE STATUS trên lý thuyết có thể cho ta thấy điều này, thực tế nó không phải lúc nào cũng chính xác vì 1 vài lí do:

 Bản sao không thể tự report khi nó thực thi câu truy vấn

 Bản sao luôn report là NULL nếu tiến trình sao lưu không hoạt động

 Một vài lỗi xảy ra (vd: mạng không ổn định, )

 Đôi khi không thể tính toán độ trễ ngay cả khi tiến trình sao lưu đang chạy

 Thực thi trong khoảng thời gian dài sẽ khiến việc report bị sai lệch

 Giải pháp là heart-beat record – update các tem thời gian liên tục trên bản gốc Độ trễ được tính toán bằng cách trừ heartbeat trong tem thời gian hiện tại cho cái có trên bản sao

6 Replication Administration and Maintenance

 6.3 Determining whether replicas are Consistent with the master

 Việc kiểm tra bản sao có đồng nhất với bản chính hay không là việc làm cần thực hiện thường xuyên đặc biệt là khi sử dụng Replication cho việc backup

 MySQL ko tích hợp các phương pháp để kiểm tra sự đồng nhất mà chỉ cung cấp các khối được xây dựng từ bảng kiểm và dữ liệu, ví dụ CHECKSUM TABLE

 Pt-table-checksum là 1 công cụ có thể giải quyết các vấn đề trên – Hoạt động bằng cách

sử dụng câu lệnh INSERT…SELECT trên bản gốc

 Hoặc dung:

 $pt-table-checksum replicate=test.checksum <master_host>

6 Replication Administration and Maintenance

 6.4 Resyncing a replica from the master

 Hai phương pháp truyền thống:

 Dừng và tải lại từ bản gốc

 Dừng và xóa bỏ (áp dụng với các vấn đề nghiêm trọng), sau đó tải lại bản sao hoặc restore từ file backup

 Nhược điểm: - Bất tiện đặc biệt là khi xử lí với khối lượng dữ liệu lớn

 Nếu sự bất đồng bộ được phát hiện ko quá nghiêm trọng, có thể chỉ cần đồng bộ lại với các dữ liệu bị ảnh

6 Replication Administration and Maintenance

6 Replication Administration and Maintenance

6.5.1 Planned Promotion

1 Nhìn chung thì sẽ có 4 bước cơ bản sau:

2 Dừng việc ghi trên bản gốc cũ

3 Để bản sao hoàn thành việc sao lưu

4 Cấu hình bản sao thành bản gốc mới

5 Kết nối các bản sao khác và các lệnh ghi đến bản gốc mới, thiết lập lệnh ghi trên đó

*Các bước có thể khác đi tùy thuộc vào giao thức khác nhau

6.5.2 Unplanned promotions

Xảy ra khi bản gốc bị crash khiến cho các bản sao mang khối lượng dữ liệu khác nhau gây khó khan trong việc xác định bản sao nào sẽ trở thành bản gốc mới

Các bước để đưa bản sao lên thành bản bản gốc mới trong giao thức phân cấp

6 Xác định bản sao nào được cập nhật đầy đủ nhất bằng cách kiểm tra đầu ra của SHOW SLAVE STATUS trên mỗi bản sao

7 Để các bản sao hoàn thành việc chạy file rely log được mang về từ bản gốc cũ trước khi bị crash

8 Thực hiện bước 5-7 như trên

9 So sánh vị trí file Master_Log_File/Read_Master_Log_Pos của mỗi bản sao với với các file trên bản gốc mới

10 Thực hiện bước 10-12 như trên

6 Replication Administration and Maintenance

6.5.3 Locate the desired log positions

 Cần tìm vị trí file binary log của bản gốc tương ứng

với sự kiện cuối cùng mà bản sao thực thi nếu như bản

sao không nằm đúng vị trí như trên bản gốc

 Việc tìm kiếm trên có thể sẽ chậm và nhàm chán

nhưng không khó

 Nếu cần khôi phục các sự kiện bị mất từ bản gốc

cũ, nên làm điều đó sau khi tạo được bản gốc mới

nhưng trước khi kết nối với client

6 Replication Administration and Maintenance

6.6 Switching roles in a Master-Master Configuration

Đặc điểm của việc sao lưu ngang hàng là có thể đổi vai trò của các server 1 cách dễ

dàng bởi cấu hình đối xứng của nó

Các bước thực hiện đổi vai trò mà không xảy ra xung đột:

1 Dừng các bản ghi trên active server

2 Thực thi SET GLOBAL read_only = 1 trên active server và thiết lập read-only trên cấu hình của

nó

3 Thực thi MASTER_STATUS trên active server để lưu lại vị trí của file binary_log

4 Thực thi SELECT MASTER_ROS_WAIT() trên vị trí của file binary log của active server

5 Thực thi SET GLOBAL read_only = 0 trên passive server, theo đó biến nó thành active server

6 Cấu hình lại ứng dụng để ghi trên active server mới