Nhiều nô lệ sao chép bị trì hoãn để khôi phục thảm họa với RTO thấp

Sao chép chậm trễ cho phép một nô lệ nhân bản cố tình tụt hậu so với bản chính ít nhất trong một khoảng thời gian nhất định. Trước khi thực hiện một sự kiện, trước tiên, nô lệ sẽ đợi, nếu cần, cho đến khi thời gian nhất định trôi qua kể từ khi sự kiện được tạo trên chủ. Kết quả là nô lệ sẽ phản ánh trạng thái của chủ một thời gian trở về quá khứ. Tính năng này được hỗ trợ kể từ MySQL 5.6 và MariaDB 10.2.3. Nó có thể hữu ích trong trường hợp vô tình xóa dữ liệu và phải là một phần của kế hoạch khôi phục thảm họa của bạn.

Vấn đề khi thiết lập một nô lệ sao chép bị trì hoãn là chúng ta nên đặt bao nhiêu độ trễ. Quá ngắn thời gian và bạn có nguy cơ truy vấn không tốt đến với nô lệ bị trì hoãn của bạn trước khi bạn có thể truy cập nó, do đó lãng phí điểm của việc có nô lệ bị trì hoãn. Theo tùy chọn, bạn có thể có thời gian trì hoãn dài đến mức phải mất hàng giờ để nô lệ bị trì hoãn của bạn bắt kịp vị trí của chủ tại thời điểm xảy ra lỗi.

May mắn thay với Docker, cô lập quy trình là thế mạnh của nó. Chạy nhiều phiên bản MySQL khá thuận tiện với Docker. Nó cho phép chúng tôi có nhiều nô lệ bị trì hoãn trong một máy chủ vật lý để cải thiện thời gian khôi phục và tiết kiệm tài nguyên phần cứng. Nếu bạn cho rằng thời gian trễ 15 phút là quá ngắn, chúng tôi có thể có một trường hợp khác với độ trễ 1 giờ hoặc 6 giờ cho ảnh chụp nhanh cơ sở dữ liệu của chúng tôi thậm chí còn cũ hơn.

Trong bài đăng trên blog này, chúng tôi sẽ triển khai nhiều nô lệ bị trì hoãn MySQL trên một máy chủ vật lý duy nhất với Docker và hiển thị một số tình huống khôi phục. Sơ đồ sau minh họa kiến ​​trúc cuối cùng mà chúng tôi muốn xây dựng:

Kiến trúc của chúng tôi bao gồm Bản sao MySQL 2 nút đã được triển khai chạy trên các máy chủ vật lý (màu xanh lam) và chúng tôi muốn thiết lập ba nô lệ MySQL khác (màu xanh lá cây) với hành vi sau:

• Chậm trễ 15 phút
• Chậm 1 giờ
• Chậm trễ 6 giờ

Hãy lưu ý rằng chúng ta sẽ có 3 bản sao của cùng một dữ liệu chính xác trên cùng một máy chủ vật lý. Đảm bảo máy chủ lưu trữ Docker của chúng tôi có dung lượng lưu trữ cần thiết, vì vậy hãy phân bổ đủ dung lượng đĩa trước đó.

Chuẩn bị cho MySQL Master

Đầu tiên, đăng nhập vào máy chủ chính và tạo người dùng sao chép:

mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]'%' IDENTIFIED BY 'YlgSH6bLLy';

Sau đó, tạo một bản sao lưu tương thích với PITR trên bản chính:

$ mysqldump -uroot -p --flush-privileges --hex-blob --opt --master-data=1 --single-transaction --skip-lock-tables --skip-lock-tables --triggers --routines --events --all-databases | gzip -6 -c > mysqldump_complete.sql.gz

Nếu bạn đang sử dụng ClusterControl, bạn có thể tạo một bản sao lưu tương thích với PITR một cách dễ dàng. Đi tới Sao lưu -> Tạo Bản sao lưu và chọn "Hoàn thành tương thích với PITR" trong trình đơn thả xuống "Loại kết xuất":

Cuối cùng, chuyển bản sao lưu này sang máy chủ Docker:

$ scp mysqldump_complete.sql.gz [email protected]:~

Tệp sao lưu này sẽ được sử dụng bởi các vùng chứa nô lệ MySQL trong quá trình khởi động nô lệ, như được hiển thị trong phần tiếp theo.

Triển khai nô lệ bị trì hoãn

Chuẩn bị các thư mục vùng chứa Docker của chúng tôi. Tạo 3 thư mục (mysql.conf.d, datadir và sql) cho mọi vùng chứa MySQL mà chúng tôi sẽ khởi chạy (bạn có thể sử dụng vòng lặp để đơn giản hóa các lệnh bên dưới):

$ mkdir -p /storage/mysql-slave-15m/mysql.conf.d
$ mkdir -p /storage/mysql-slave-15m/datadir
$ mkdir -p /storage/mysql-slave-15m/sql
$ mkdir -p /storage/mysql-slave-1h/mysql.conf.d
$ mkdir -p /storage/mysql-slave-1h/datadir
$ mkdir -p /storage/mysql-slave-1h/sql
$ mkdir -p /storage/mysql-slave-6h/mysql.conf.d
$ mkdir -p /storage/mysql-slave-6h/datadir
$ mkdir -p /storage/mysql-slave-6h/sql

Thư mục "mysql.conf.d" sẽ lưu trữ tệp cấu hình MySQL tùy chỉnh của chúng tôi và sẽ được ánh xạ vào vùng chứa dưới /etc/mysql.conf.d. "datadir" là nơi chúng tôi muốn Docker lưu trữ thư mục dữ liệu MySQL, thư mục này ánh xạ tới / var / lib / mysql của vùng chứa và thư mục "sql" lưu trữ các tệp SQL của chúng tôi - các tệp sao lưu ở định dạng .sql hoặc .sql.gz vào giai đoạn nô lệ trước khi sao chép và cả các tệp .sql để tự động hóa cấu hình sao chép và khởi động.

Nô lệ bị hoãn 15 phút

Chuẩn bị tệp cấu hình MySQL cho nô lệ bị trì hoãn 15 phút của chúng tôi:

$ vim /storage/mysql-slave-15m/mysql.conf.d/my.cnf

Và thêm các dòng sau:

[mysqld]
server_id=10015
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON

** Giá trị id máy chủ mà chúng tôi sử dụng cho máy chủ này là 10015.

Tiếp theo, trong thư mục / storage / mysql-slave-15m / sql, tạo hai tệp SQL, một tệp để ĐẶT LẠI MASTER (1reset_master.sql) và một tệp khác để thiết lập liên kết sao chép bằng cách sử dụng câu lệnh CHANGE MASTER (3setup_slave.sql).

Tạo tệp văn bản 1reset_master.sql và thêm dòng sau:

RESET MASTER;

Tạo tệp văn bản 3setup_slave.sql và thêm các dòng sau:

CHANGE MASTER TO MASTER_HOST = '192.168.55.171', MASTER_USER = 'rpl_user', MASTER_PASSWORD = 'YlgSH6bLLy', MASTER_AUTO_POSITION = 1, MASTER_DELAY=900;
START SLAVE;

MASTER_DELAY =900 tương đương với 15 phút (tính bằng giây). Sau đó, sao chép tệp sao lưu được lấy từ tệp chính của chúng tôi (đã được chuyển vào máy chủ Docker của chúng tôi) vào thư mục "sql" và đổi tên nó thành 2mysqldump_complete.sql.gz:

$ cp ~/mysqldump_complete.tar.gz /storage/mysql-slave-15m/sql/2mysqldump_complete.tar.gz

Giao diện cuối cùng của thư mục "sql" của chúng tôi sẽ giống như sau:

$ pwd
/storage/mysql-slave-15m/sql
$ ls -1
1reset_master.sql
2mysqldump_complete.sql.gz
3setup_slave.sql

Hãy lưu ý rằng chúng tôi đặt tiền tố tên tệp SQL bằng một số nguyên để xác định thứ tự thực thi khi Docker khởi tạo vùng chứa MySQL.

Khi mọi thứ đã sẵn sàng, hãy chạy vùng chứa MySQL cho nô lệ bị trì hoãn 15 phút của chúng tôi:

$ docker run -d \
--name mysql-slave-15m \
-e MYSQL_ROOT_PASSWORD=password \
--mount type=bind,source=/storage/mysql-slave-15m/datadir,target=/var/lib/mysql \
--mount type=bind,source=/storage/mysql-slave-15m/mysql.conf.d,target=/etc/mysql/mysql.conf.d \
--mount type=bind,source=/storage/mysql-slave-15m/sql,target=/docker-entrypoint-initdb.d \
mysql:5.7

** Giá trị MYSQL_ROOT_PASSWORD phải giống với mật khẩu gốc MySQL trên chính.

Những dòng sau đây là những gì chúng tôi đang tìm kiếm để xác minh xem MySQL có đang chạy chính xác hay không và được kết nối như một nô lệ cho chủ của chúng tôi (192.168.55.171):

$ docker logs -f mysql-slave-15m
...
2018-12-04T04:05:24.890244Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-12-04T04:05:25.010032Z 2 [Note] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 4

Sau đó, bạn có thể xác minh trạng thái sao chép bằng câu lệnh sau:

$ docker exec -it mysql-slave-15m mysql -uroot -p -e 'show slave status\G'
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 900
                Auto_Position: 1
...

Tại thời điểm này, vùng chứa nô lệ bị trì hoãn 15 phút của chúng tôi đang sao chép chính xác và kiến ​​trúc của chúng tôi trông giống như sau:

Nô lệ bị trì hoãn 1 giờ

Chuẩn bị tệp cấu hình MySQL cho nô lệ bị trì hoãn 1 giờ của chúng tôi:

$ vim /storage/mysql-slave-1h/mysql.conf.d/my.cnf

Và thêm các dòng sau:

[mysqld]
server_id=10060
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON

** Giá trị id máy chủ mà chúng tôi sử dụng cho máy chủ này là 10060.

Tiếp theo, trong thư mục / storage / mysql-slave-1h / sql, tạo hai tệp SQL, một tệp để ĐẶT LẠI MASTER (1reset_master.sql) và một tệp khác để thiết lập liên kết sao chép bằng cách sử dụng câu lệnh CHANGE MASTER (3setup_slave.sql).

Tạo tệp văn bản 1reset_master.sql và thêm dòng sau:

RESET MASTER;

Tạo tệp văn bản 3setup_slave.sql và thêm các dòng sau:

CHANGE MASTER TO MASTER_HOST = '192.168.55.171', MASTER_USER = 'rpl_user', MASTER_PASSWORD = 'YlgSH6bLLy', MASTER_AUTO_POSITION = 1, MASTER_DELAY=3600;
START SLAVE;

MASTER_DELAY =3600 tương đương với 1 giờ (tính bằng giây). Sau đó, sao chép tệp sao lưu được lấy từ tệp chính của chúng tôi (đã được chuyển vào máy chủ Docker của chúng tôi) vào thư mục "sql" và đổi tên nó thành 2mysqldump_complete.sql.gz:

$ cp ~/mysqldump_complete.tar.gz /storage/mysql-slave-1h/sql/2mysqldump_complete.tar.gz

Giao diện cuối cùng của thư mục "sql" của chúng tôi sẽ giống như sau:

$ pwd
/storage/mysql-slave-1h/sql
$ ls -1
1reset_master.sql
2mysqldump_complete.sql.gz
3setup_slave.sql

Hãy lưu ý rằng chúng tôi đặt tiền tố tên tệp SQL bằng một số nguyên để xác định thứ tự thực thi khi Docker khởi tạo vùng chứa MySQL.

Khi mọi thứ đã sẵn sàng, hãy chạy vùng chứa MySQL cho nô lệ bị trì hoãn 1 giờ của chúng tôi:

$ docker run -d \
--name mysql-slave-1h \
-e MYSQL_ROOT_PASSWORD=password \
--mount type=bind,source=/storage/mysql-slave-1h/datadir,target=/var/lib/mysql \
--mount type=bind,source=/storage/mysql-slave-1h/mysql.conf.d,target=/etc/mysql/mysql.conf.d \
--mount type=bind,source=/storage/mysql-slave-1h/sql,target=/docker-entrypoint-initdb.d \
mysql:5.7

** Giá trị MYSQL_ROOT_PASSWORD phải giống với mật khẩu gốc MySQL trên chính.

Những dòng sau đây là những gì chúng tôi đang tìm kiếm để xác minh xem MySQL có đang chạy chính xác hay không và được kết nối như một nô lệ cho chủ của chúng tôi (192.168.55.171):

$ docker logs -f mysql-slave-1h
...
2018-12-04T04:05:24.890244Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-12-04T04:05:25.010032Z 2 [Note] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 4

Sau đó, bạn có thể xác minh trạng thái sao chép bằng câu lệnh sau:

$ docker exec -it mysql-slave-1h mysql -uroot -p -e 'show slave status\G'
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 3600
                Auto_Position: 1
...

Tại thời điểm này, các vùng chứa nô lệ bị trì hoãn trong 15 phút và 1 giờ MySQL của chúng tôi đang sao chép từ cái chính và kiến ​​trúc của chúng tôi trông giống như sau:

Nô lệ bị trì hoãn 6 giờ

Chuẩn bị tệp cấu hình MySQL cho nô lệ bị trì hoãn 6 giờ của chúng tôi:

$ vim /storage/mysql-slave-15m/mysql.conf.d/my.cnf

Và thêm các dòng sau:

[mysqld]
server_id=10006
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON

** Giá trị id máy chủ mà chúng tôi đã sử dụng cho máy chủ này là 10006.

Tiếp theo, trong thư mục / storage / mysql-slave-6h / sql, tạo hai tệp SQL, một tệp để ĐẶT LẠI MASTER (1reset_master.sql) và một tệp khác để thiết lập liên kết sao chép bằng cách sử dụng câu lệnh CHANGE MASTER (3setup_slave.sql).

Tạo tệp văn bản 1reset_master.sql và thêm dòng sau:

RESET MASTER;

Tạo tệp văn bản 3setup_slave.sql và thêm các dòng sau:

CHANGE MASTER TO MASTER_HOST = '192.168.55.171', MASTER_USER = 'rpl_user', MASTER_PASSWORD = 'YlgSH6bLLy', MASTER_AUTO_POSITION = 1, MASTER_DELAY=21600;
START SLAVE;

MASTER_DELAY =21600 tương đương với 6 giờ (tính bằng giây). Sau đó, sao chép tệp sao lưu được lấy từ tệp chính của chúng tôi (đã được chuyển vào máy chủ Docker của chúng tôi) vào thư mục "sql" và đổi tên nó thành 2mysqldump_complete.sql.gz:

$ cp ~/mysqldump_complete.tar.gz /storage/mysql-slave-6h/sql/2mysqldump_complete.tar.gz

Giao diện cuối cùng của thư mục "sql" của chúng tôi sẽ giống như sau:

$ pwd
/storage/mysql-slave-6h/sql
$ ls -1
1reset_master.sql
2mysqldump_complete.sql.gz
3setup_slave.sql

Hãy lưu ý rằng chúng tôi đặt tiền tố tên tệp SQL bằng một số nguyên để xác định thứ tự thực thi khi Docker khởi tạo vùng chứa MySQL.

Khi mọi thứ đã sẵn sàng, hãy chạy vùng chứa MySQL cho nô lệ bị trì hoãn 6 giờ của chúng tôi:

$ docker run -d \
--name mysql-slave-6h \
-e MYSQL_ROOT_PASSWORD=password \
--mount type=bind,source=/storage/mysql-slave-6h/datadir,target=/var/lib/mysql \
--mount type=bind,source=/storage/mysql-slave-6h/mysql.conf.d,target=/etc/mysql/mysql.conf.d \
--mount type=bind,source=/storage/mysql-slave-6h/sql,target=/docker-entrypoint-initdb.d \
mysql:5.7

** Giá trị MYSQL_ROOT_PASSWORD phải giống với mật khẩu gốc MySQL trên chính.

Những dòng sau đây là những gì chúng tôi đang tìm kiếm để xác minh xem MySQL có đang chạy chính xác hay không và được kết nối như một nô lệ cho chủ của chúng tôi (192.168.55.171):

$ docker logs -f mysql-slave-6h
...
2018-12-04T04:05:24.890244Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-12-04T04:05:25.010032Z 2 [Note] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 4

Sau đó, bạn có thể xác minh trạng thái sao chép bằng câu lệnh sau:

$ docker exec -it mysql-slave-6h mysql -uroot -p -e 'show slave status\G'
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 21600
                Auto_Position: 1
...

Tại thời điểm này, các vùng chứa nô lệ bị trễ 5 phút, 1 giờ và 6 giờ của chúng tôi đang sao chép chính xác và kiến ​​trúc của chúng tôi trông giống như sau:

Kịch bản khôi phục sau thảm họa

Giả sử một người dùng đã vô tình làm rơi sai một cột trên một bảng lớn. Hãy xem xét câu lệnh sau đã được thực thi trên cái chính:

mysql> USE shop;
mysql> ALTER TABLE settings DROP COLUMN status;

Nếu bạn đủ may mắn để nhận ra điều đó ngay lập tức, bạn có thể sử dụng nô lệ bị trì hoãn 15 phút để bắt kịp thời điểm trước khi thảm họa xảy ra và thăng cấp nó trở thành chủ hoặc xuất dữ liệu bị thiếu ra ngoài và khôi phục nó trên chủ.

Đầu tiên, chúng ta phải tìm vị trí bản ghi nhị phân trước khi thảm họa xảy ra. Nắm bắt thời gian ngay bây giờ () trên chính cái:

mysql> SELECT now();
+---------------------+
| now()               |
+---------------------+
| 2018-12-04 14:55:41 |
+---------------------+

Sau đó, lấy tệp nhật ký nhị phân đang hoạt động trên trang cái:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                                                                                                                     |
+---------------+----------+--------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| binlog.000004 | 20260658 |              |                  | 1560665e-ed2b-11e8-93fa-000c29b7f985:1-12031,
1b235f7a-d37b-11e8-9c3e-000c29bafe8f:1-62519,
1d8dc60a-e817-11e8-82ff-000c29bafe8f:1-326575,
791748b3-d37a-11e8-b03a-000c29b7f985:1-374 |
+---------------+----------+--------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Sử dụng cùng một định dạng ngày tháng, trích xuất thông tin mà chúng tôi muốn từ nhật ký nhị phân, binlog.000004. Chúng tôi ước tính thời gian bắt đầu đọc từ binlog khoảng 20 phút trước (2018-12-04 14:35:00) và lọc đầu ra để hiển thị 25 dòng trước câu lệnh "drop column":

$ mysqlbinlog --start-datetime="2018-12-04 14:35:00" --stop-datetime="2018-12-04 14:55:41" /var/lib/mysql/binlog.000004 | grep -i -B 25 "drop column"
'/*!*/;
# at 19379172
#181204 14:54:45 server id 1  end_log_pos 19379232 CRC32 0x0716e7a2     Table_map: `shop`.`settings` mapped to number 766
# at 19379232
#181204 14:54:45 server id 1  end_log_pos 19379460 CRC32 0xa6187edd     Write_rows: table id 766 flags: STMT_END_F

BINLOG '
tSQGXBMBAAAAPAAAACC0JwEAAP4CAAAAAAEABnNidGVzdAAHc2J0ZXN0MgAFAwP+/gME/nj+PBCi
5xYH
tSQGXB4BAAAA5AAAAAS1JwEAAP4CAAAAAAEAAgAF/+AYwwAAysYAAHc0ODYyMjI0NjI5OC0zNDE2
OTY3MjY5OS02MDQ1NTQwOTY1Ny01MjY2MDQ0MDcwOC05NDA0NzQzOTUwMS00OTA2MTAxNzgwNC05
OTIyMzM3NzEwOS05NzIwMzc5NTA4OC0yODAzOTU2NjQ2MC0zNzY0ODg3MTYzOTswMTM0MjAwNTcw
Ni02Mjk1ODMzMzExNi00NzQ1MjMxODA1OS0zODk4MDQwMjk5MS03OTc4MTA3OTkwNQEAAADdfhim
'/*!*/;
# at 19379460
#181204 14:54:45 server id 1  end_log_pos 19379491 CRC32 0x71f00e63     Xid = 622405
COMMIT/*!*/;
# at 19379491
#181204 14:54:46 server id 1  end_log_pos 19379556 CRC32 0x62b78c9e     GTID    last_committed=11507    sequence_number=11508   rbr_only=no
SET @@SESSION.GTID_NEXT= '1560665e-ed2b-11e8-93fa-000c29b7f985:11508'/*!*/;
# at 19379556
#181204 14:54:46 server id 1  end_log_pos 19379672 CRC32 0xc222542a     Query   thread_id=3162  exec_time=1     error_code=0
SET TIMESTAMP=1543906486/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
ALTER TABLE settings DROP COLUMN status

Trong vài dòng dưới cùng của đầu ra mysqlbinlog, bạn sẽ có lệnh sai được thực thi ở vị trí 19379556. Vị trí mà chúng ta nên khôi phục là một bước trước đó, ở vị trí 19379491. Đây là vị trí binlog mà chúng tôi muốn nô lệ bị trì hoãn để được cập nhật.

Sau đó, trên nô lệ bị trì hoãn đã chọn, dừng nô lệ sao chép bị trì hoãn và bắt đầu lại nô lệ đến một vị trí cuối cố định mà chúng tôi đã tìm hiểu ở trên:

$ docker exec -it mysql-slave-15m mysql -uroot -p
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE = 'binlog.000004', MASTER_LOG_POS = 19379491;

Theo dõi trạng thái sao chép và đợi cho đến khi Exec_Master_Log_Pos bằng giá trị Until_Log_Pos. Điều này có thể mất một thời gian. Sau khi bắt kịp, bạn sẽ thấy những điều sau:

$ docker exec -it mysql-slave-15m mysql -uroot -p -e 'SHOW SLAVE STATUS\G'
... 
          Exec_Master_Log_Pos: 19379491
              Relay_Log_Space: 50552186
              Until_Condition: Master
               Until_Log_File: binlog.000004
                Until_Log_Pos: 19379491
...

Cuối cùng xác minh xem dữ liệu bị thiếu mà chúng tôi đang tìm kiếm có ở đó không (cột "trạng thái" vẫn tồn tại):

mysql> DESCRIBE shop.settings;
+--------+------------------+------+-----+---------+----------------+
| Field  | Type             | Null | Key | Default | Extra          |
+--------+------------------+------+-----+---------+----------------+
| id     | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| sid    | int(10) unsigned | NO   | MUL | 0       |                |
| param  | varchar(100)     | NO   |     |         |                |
| value  | varchar(255)     | NO   |     |         |                |
| status | int(11)          | YES  |     | 1       |                |
+--------+------------------+------+-----+---------+----------------+

Sau đó, xuất bảng từ vùng chứa phụ của chúng tôi và chuyển nó đến máy chủ chính:

$ docker exec -it mysql-slave-1h mysqldump -uroot -ppassword --single-transaction shop settings > shop_settings.sql

Thả bảng có vấn đề và khôi phục lại bảng chính:

$ mysql -uroot -p -e 'DROP TABLE shop.settings'
$ mysqldump -uroot -p -e shop < shop_setttings.sql

Bây giờ chúng tôi đã khôi phục bàn của mình trở lại trạng thái ban đầu trước khi sự kiện thảm khốc xảy ra. Tóm lại, sao chép chậm có thể được sử dụng cho một số mục đích:

• Để bảo vệ khỏi những sai lầm của người dùng trên trang cái. DBA có thể khôi phục một nô lệ bị trì hoãn về thời điểm ngay trước khi thảm họa xảy ra.
• Để kiểm tra cách hệ thống hoạt động khi có độ trễ. Ví dụ:trong một ứng dụng, độ trễ có thể do tải nặng trên máy chủ. Tuy nhiên, có thể khó tạo ra mức tải này. Sao chép trễ có thể mô phỏng độ trễ mà không cần phải mô phỏng tải. Nó cũng có thể được sử dụng để gỡ lỗi các điều kiện liên quan đến một nô lệ bị trễ.
• Để kiểm tra cơ sở dữ liệu trông như thế nào trước đây mà không cần phải tải lại bản sao lưu. Ví dụ:nếu độ trễ là một tuần và DBA cần xem cơ sở dữ liệu trông như thế nào trước khi phát triển trong vài ngày qua, thì có thể kiểm tra nô lệ bị trì hoãn.

Lời kết

Với Docker, việc chạy nhiều phiên bản MySQL trên cùng một máy chủ vật lý có thể được thực hiện một cách hiệu quả. Bạn có thể sử dụng các công cụ điều phối Docker như Docker Compose và Swarm để đơn giản hóa việc triển khai nhiều vùng chứa thay vì các bước được hiển thị trong bài đăng blog này.