Cơ sở dữ liệu có thể bị lỗi mà không có cảnh báo - có thể do sự cố do lỗi phần mềm hoặc các thành phần phần cứng bên dưới. Đám mây mang đến một khía cạnh khác cho vấn đề, vì bản chất phù du của tài nguyên máy tính và lưu trữ. Để cách ly cơ sở hạ tầng cơ sở dữ liệu của chúng tôi khỏi những lỗi này, chúng tôi xây dựng dự phòng vào hệ thống của mình. Nếu một phiên bản không khả dụng, một hệ thống dự phòng sẽ có thể tiếp nhận khối lượng công việc và tiếp tục từ đó. Sao chép là một phương pháp nổi tiếng và được áp dụng rộng rãi để tạo các bản sao dự phòng của cơ sở dữ liệu chính.
Trong bài đăng này, chúng tôi sẽ so sánh chức năng sao chép trong hai hệ thống cơ sở dữ liệu phổ biến nhất trên hành tinh (theo db-engine) - Oracle và MySQL. Chúng tôi sẽ xem xét cụ thể bản sao lôgic Oracle 12c và MySQL 5.7. Cả hai công nghệ đều cung cấp các hệ thống dự phòng đáng tin cậy để giảm tải khối lượng công việc sản xuất và trợ giúp trong trường hợp thiên tai. Chúng ta sẽ xem xét các kiến trúc khác nhau của chúng, phân tích ưu và nhược điểm và đi qua các bước về cách thiết lập sao chép với Oracle và MySQL.
Kiến trúc bảo vệ dữ liệu của Oracle - Cách hoạt động
Oracle Data Guard đảm bảo tính khả dụng cao, bảo vệ dữ liệu và khôi phục dữ liệu của bạn sau thảm họa. Đây có lẽ là lựa chọn đầu tiên của Oracle DBA để sao chép dữ liệu. Công nghệ này được giới thiệu vào năm 1990 (phiên bản 7.0) với một ứng dụng thiết yếu là lưu trữ nhật ký trên cơ sở dữ liệu dự phòng. Data Guard đã phát triển qua nhiều năm và hiện cung cấp một bộ dịch vụ toàn diện để tạo, duy trì, quản lý và giám sát cơ sở dữ liệu dự phòng.
Data Guard duy trì cơ sở dữ liệu dự phòng dưới dạng bản sao của cơ sở dữ liệu sản xuất. Nếu cơ sở dữ liệu chính ngừng phản hồi, Data Guard có thể chuyển bất kỳ chế độ chờ nào sang vai trò sản xuất, do đó thời gian ngừng hoạt động. Data Guard có thể được sử dụng để sao lưu, khôi phục và các kỹ thuật cụm để cung cấp mức độ bảo vệ dữ liệu cao và tính sẵn sàng của dữ liệu.
Data Guard là công nghệ Ship Redo / Apply Redo, "redo" là thông tin cần thiết để khôi phục các giao dịch. Cơ sở dữ liệu sản xuất được gọi là cơ sở dữ liệu chính phát sóng làm lại đến một hoặc nhiều bản sao được gọi là cơ sở dữ liệu dự phòng. Khi thực hiện chèn hoặc cập nhật vào bảng, người viết nhật ký sẽ ghi lại thay đổi này vào nhật ký lưu trữ và sao chép sang hệ thống chờ. Cơ sở dữ liệu dự phòng đang trong giai đoạn phục hồi liên tục, xác minh và áp dụng làm lại để duy trì đồng bộ hóa với cơ sở dữ liệu chính. Cơ sở dữ liệu dự phòng cũng sẽ tự động đồng bộ hóa lại nếu nó tạm thời bị ngắt kết nối với cơ sở dữ liệu chính do mất điện, sự cố mạng, v.v.
Oracle Data Guard Net Services Data Guard Redo Transport Services quy định việc truyền dữ liệu làm lại từ cơ sở dữ liệu chính đến cơ sở dữ liệu dự phòng. Quy trình LGWR (ghi nhật ký) gửi dữ liệu làm lại đến một hoặc nhiều quy trình máy chủ mạng (LNS1, LSN2, LSN3, ... LSNn). LNS đang đọc từ bộ đệm làm lại trong SGA (Khu vực toàn cầu được chia sẻ) và chuyển làm lại đến Oracle Net Services để truyền đến cơ sở dữ liệu dự phòng. Bạn có thể chọn các thuộc tính LGWR:chế độ đồng bộ (LogXptMode ='SYNC') hoặc chế độ không đồng bộ (LogXptMode ='ASYNC'). Với kiến trúc như vậy, có thể cung cấp dữ liệu làm lại đến một số cơ sở dữ liệu dự phòng hoặc sử dụng nó với Oracle RAC (Real Application Cluster). Quá trình Máy chủ Tệp Từ xa (RFS) nhận quá trình làm lại từ LNS và ghi nó vào một tệp thông thường được gọi là tệp nhật ký làm lại ở chế độ chờ (SRL).
Có hai loại Oracle Data Guard chính. Áp dụng vật lý với áp dụng lại và áp dụng cơ sở dữ liệu dự phòng logic với SQL.
Kiến trúc sao chép lôgic dữ liệu Oracle Dataguard SQL áp dụng yêu cầu xử lý nhiều hơn so với áp dụng làm lại, trước tiên quy trình đọc SRL và "khai thác" quá trình làm lại bằng cách chuyển đổi nó thành các bản ghi thay đổi logic, sau đó xây dựng các giao dịch SQL trước khi áp dụng SQL vào cơ sở dữ liệu dự phòng. Có nhiều bộ phận chuyển động hơn nên nó yêu cầu nhiều CPU, bộ nhớ và I / O hơn, sau đó áp dụng lại.
Lợi ích chính của "SQL apply" là cơ sở dữ liệu được mở để đọc-ghi, trong khi quá trình áp dụng đang hoạt động.
Bạn thậm chí có thể tạo chế độ xem và chỉ mục cục bộ. Điều này làm cho nó trở nên lý tưởng cho các công cụ báo cáo. Cơ sở dữ liệu dự phòng không nhất thiết phải là bản sao 1-1 của cơ sở dữ liệu chính của bạn và do đó có thể không phải là ứng cử viên tốt nhất cho các mục đích DR.
Các tính năng chính của giải pháp này là:
- Cơ sở dữ liệu dự phòng được mở để đọc-ghi trong khi áp dụng SQL đang hoạt động
- Áp dụng khóa sửa đổi có thể có của dữ liệu đang được SQL duy trì
- Có thể thực hiện nâng cấp cơ sở dữ liệu luân phiên
Có những mặt hạn chế. Oracle sử dụng ghi nhật ký bổ sung khóa chính hoặc duy nhất-ràng buộc / chỉ mục để nhận ra một cách hợp lý một hàng đã sửa đổi trong cơ sở dữ liệu dự phòng hợp lý. Khi bật tính năng ghi nhật ký bổ sung khóa chính và ràng buộc / chỉ mục duy nhất trên toàn cơ sở dữ liệu, mỗi câu lệnh CẬP NHẬT cũng ghi các giá trị cột cần thiết vào nhật ký làm lại để xác định duy nhất hàng đã sửa đổi trong cơ sở dữ liệu dự phòng logic. Oracle Data Guard hỗ trợ sao chép theo chuỗi, ở đây được gọi là "thác nước", tuy nhiên, nó không điển hình do sự phức tạp của thiết lập.
Oracle khuyến nghị bạn nên thêm khóa chính hoặc chỉ mục duy nhất không rỗng vào các bảng trong cơ sở dữ liệu chính, bất cứ khi nào có thể, để đảm bảo rằng SQL Apply có thể áp dụng hiệu quả các bản cập nhật dữ liệu làm lại cho cơ sở dữ liệu dự phòng hợp lý. Điều này có nghĩa là nó không hoạt động trên bất kỳ thiết lập nào, bạn có thể cần phải sửa đổi ứng dụng của mình.
Kiến trúc Cổng vàng Oracle - Cách thức hoạt động
Với Data Guard, khi các khối được thay đổi trong cơ sở dữ liệu, các bản ghi sẽ được thêm vào nhật ký làm lại. Sau đó, dựa trên chế độ sao chép mà bạn đang chạy, các bản ghi nhật ký này sẽ được sao chép ngay lập tức sang chế độ chờ hoặc được khai thác cho các lệnh SQL và được áp dụng. Golden Gate hoạt động theo một cách khác.
Golden Gate chỉ sao chép các thay đổi sau khi giao dịch được cam kết, vì vậy nếu bạn có một giao dịch đang hoạt động lâu dài, có thể mất một lúc để sao chép. Golden Gate "quy trình trích xuất" lưu giữ các thay đổi giao dịch trong bộ nhớ.
Một điểm khác biệt lớn nữa là Oracle Golden Gate cho phép trao đổi và thao tác dữ liệu ở cấp độ giao dịch giữa nhiều nền tảng không đồng nhất. Bạn không chỉ bị giới hạn trong cơ sở dữ liệu Oracle. Nó cung cấp cho bạn sự linh hoạt để trích xuất và sao chép các bản ghi dữ liệu đã chọn, các thay đổi giao dịch và các thay đổi đối với DDL (ngôn ngữ định nghĩa dữ liệu) trên nhiều cấu trúc liên kết khác nhau.
Kiến trúc Oracle Golden Gate Luồng Golden Gate điển hình hiển thị dữ liệu cơ sở dữ liệu mới và thay đổi được thu thập từ cơ sở dữ liệu nguồn. Dữ liệu thu được được ghi vào một tệp được gọi là đường mòn nguồn. Sau đó, đường mòn được đọc bởi một máy bơm dữ liệu, được gửi qua mạng và được ghi vào tệp đường mòn từ xa bằng quy trình Người thu thập. Chức năng phân phối đọc đường mòn từ xa và cập nhật cơ sở dữ liệu mục tiêu. Mỗi thành phần được quản lý bởi quy trình Manager.
MySQL Logical replication - Cách hoạt động
Nhân rộng trong MySQL đã có từ lâu và đang phát triển trong những năm qua. Có nhiều cách khác nhau để kích hoạt sao chép MySQL, bao gồm Nhân bản nhóm, Cụm Galera, "Master to Slave" không đồng bộ. Để so sánh kiến trúc Oracle và MySQL, chúng tôi sẽ tập trung vào các định dạng sao chép vì nó là cơ sở cho tất cả các kiểu sao chép khác nhau.
Trước hết, các định dạng sao chép khác nhau tương ứng với định dạng ghi nhật ký nhị phân được chỉ định trong tệp cấu hình my.cnf. Bất kể định dạng nào, nhật ký luôn được lưu trữ theo cách nhị phân, không thể xem được bằng trình chỉnh sửa thông thường. Có ba loại định dạng:dựa trên hàng, dựa trên câu lệnh và hỗn hợp. Hỗn hợp là sự kết hợp của hai đầu tiên. Chúng tôi sẽ xem xét câu lệnh và hàng dựa trên.
Dựa trên câu lệnh - trong trường hợp này, đây là những câu truy vấn được viết sẵn. Không phải tất cả các câu lệnh sửa đổi dữ liệu (chẳng hạn như câu lệnh CHÈN XÓA, CẬP NHẬT và THAY THẾ) đều có thể được sao chép bằng cách sử dụng sao chép dựa trên câu lệnh. LOAD_FILE (), UUID (), UUID_SHORT (), USER (), FOUND_ROWS (), v.v. sẽ không được sao chép.
Dựa trên hàng - trong trường hợp này, đây là những thay đổi đối với bản ghi. Tất cả các thay đổi có thể được nhân rộng. Đây là hình thức sao chép an toàn nhất. Kể từ 5.7.7, đây là tùy chọn mặc định.
Bây giờ chúng ta hãy xem điều gì đang xảy ra khi tính năng sao chép được kích hoạt.
Kiến trúc sao chép MySQL Trước hết, cơ sở dữ liệu chủ ghi các thay đổi vào một tệp được gọi là bản ghi nhị phân hoặc binlog. Việc ghi vào nhật ký nhị phân thường là một hoạt động nhẹ vì các lần ghi được lưu vào bộ đệm và tuần tự. Tệp nhật ký nhị phân lưu trữ dữ liệu mà một nô lệ sao chép sẽ xử lý sau này, hoạt động chính không phụ thuộc vào chúng. Khi bắt đầu sao chép, mysql sẽ kích hoạt ba luồng. Một về chủ, hai về nô lệ. Cái chính có một chuỗi, được gọi là chuỗi kết xuất, đọc nhật ký nhị phân của cái chính và gửi nó đến máy chủ.
Trên nô lệ, một tiến trình được gọi là luồng IO kết nối với chủ, đọc các sự kiện nhật ký nhị phân từ chủ khi chúng đến và sao chép chúng vào một tệp nhật ký cục bộ được gọi là nhật ký chuyển tiếp. Quy trình phụ thứ hai - chuỗi SQL - đọc các sự kiện từ nhật ký chuyển tiếp được lưu trữ cục bộ trên nô lệ nhân bản và sau đó sử dụng chúng.
MySQL hỗ trợ sao chép theo chuỗi, rất dễ thiết lập. Các nô lệ cũng là bản chính phải đang chạy với các tham số --log-bin và --log-slave-update.
Để kiểm tra trạng thái của bản sao và nhận thông tin về các luồng, bạn chạy trên nô lệ:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
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: 339
Relay_Log_Space: 938
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: Current_Pos
Gtid_IO_Pos: 0-1-8
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
1 row in set (0.00 sec)Thiết lập sao chép lôgic bảo vệ dữ liệu trong Oracle
-
Tạo cơ sở dữ liệu ở chế độ chờ vật lý
Để tạo cơ sở dữ liệu dự phòng hợp lý, trước tiên bạn phải tạo cơ sở dữ liệu dự phòng vật lý và sau đó chuyển nó sang cơ sở dữ liệu dự phòng hợp lý.
-
Dừng làm lại áp dụng trên Cơ sở dữ liệu ở chế độ chờ vật lý
Việc dừng Áp dụng lại là cần thiết để tránh áp dụng các thay đổi.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Chuẩn bị cơ sở dữ liệu chính để hỗ trợ cơ sở dữ liệu dự phòng logic
Thay đổi thuộc tính VALID_FOR trong LOG_ARCHIVE_DEST_1 ban đầu và thêm LOG_ARCHIVE_DEST_3 cho cơ sở dữ liệu logic.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLEXây dựng từ điển trong dữ liệu làm lại
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Chuyển đổi sang cơ sở dữ liệu dự phòng logic
Để tiếp tục áp dụng dữ liệu làm lại cho cơ sở dữ liệu dự phòng vật lý cho đến khi nó sẵn sàng chuyển đổi sang cơ sở dữ liệu dự phòng logic, hãy phát hành câu lệnh SQL sau:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Điều chỉnh các tham số khởi tạo cho cơ sở dữ liệu dự phòng logic
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Mở Cơ sở dữ liệu Logical Standby
SQL> ALTER DATABASE OPEN RESETLOGS;Xác minh Cơ sở dữ liệu dự phòng logic đang hoạt động đúng cách
v $ data_guard_stats xem
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalv $ logstdby_process xem
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Đây là các bước cần thiết để tạo bản sao lôgic của Oracle Data Guard. Các thao tác sẽ hơi khác nếu bạn thực hiện thao tác này với bộ tương thích không mặc định hoặc cơ sở dữ liệu chạy trong môi trường Oracle RAC.
Thiết lập bản sao MySQL
-
Cấu hình cơ sở dữ liệu Master. Đặt server_id duy nhất, chỉ định các bản ghi sao chép khác nhau –log-basename (MariaDB), kích hoạt bản ghi nhị phân. Sửa đổi tệp my.cnf với thông tin bên dưới.
log-bin server_id=1 log-basename=master1Đăng nhập vào cơ sở dữ liệu chính và cấp quyền cho người dùng sao chép để truy cập dữ liệu chính.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Khởi động cả hai máy chủ với GTID được bật.
gtid_mode=ON enforce-gtid-consistency=true -
Định cấu hình máy chủ để sử dụng định vị tự động dựa trên GTID.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Nếu bạn muốn thêm slave vào master cùng với dữ liệu, thì bạn cần phải sao lưu và khôi phục nó trên máy chủ slave.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlĐăng nhập vào cơ sở dữ liệu nô lệ và thực thi:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
