Trong “Trạng thái của Thị trường DBMS nguồn mở, 2018”, Gartner dự đoán rằng vào năm 2022, 70% các ứng dụng nội bộ mới sẽ được phát triển trên cơ sở dữ liệu nguồn mở. Và 50% cơ sở dữ liệu thương mại hiện có sẽ được chuyển đổi. Vì vậy, Oracle DBAs, hãy sẵn sàng để bắt đầu triển khai và quản lý cơ sở dữ liệu nguồn mở mới - cùng với các phiên bản Oracle kế thừa của bạn. Trừ khi bạn đang làm điều đó.
Vậy làm thế nào để sao chép MySQL hoặc MariaDB chống lại Oracle Data Guard? Trong blog này, chúng tôi sẽ so sánh cả hai từ quan điểm của một giải pháp cơ sở dữ liệu có tính khả dụng cao.
Tìm gì
Kiến trúc sao chép dữ liệu hiện đại được xây dựng dựa trên các thiết kế linh hoạt cho phép sao chép dữ liệu một chiều và hai chiều, cũng như chuyển đổi dự phòng nhanh chóng, tự động sang cơ sở dữ liệu thứ cấp trong trường hợp dịch vụ không có kế hoạch. Chuyển đổi dự phòng cũng phải dễ thực hiện và đáng tin cậy để không có giao dịch đã cam kết nào bị mất. Hơn nữa, việc chuyển đổi hoặc chuyển đổi dự phòng lý tưởng là phải trong suốt đối với các ứng dụng.
Các giải pháp sao chép dữ liệu phải có khả năng sao chép dữ liệu với độ trễ rất thấp để tránh tắc nghẽn xử lý và đảm bảo truy cập dữ liệu theo thời gian thực. Các bản sao thời gian thực có thể được triển khai trên một cơ sở dữ liệu khác chạy trên phần cứng giá rẻ.
Khi được sử dụng để khắc phục thảm họa, hệ thống phải được xác thực để đảm bảo ứng dụng truy cập vào hệ thống thứ cấp với mức gián đoạn dịch vụ tối thiểu. Giải pháp lý tưởng nên cho phép kiểm tra thường xuyên quá trình khôi phục sau thảm họa.
Các Chủ đề So sánh Chính
- Tính khả dụng và nhất quán của dữ liệu
- Gtid, scm
- Đề cập đến việc sao chép sang nhiều mô hình chờ, không đồng bộ + đồng bộ hóa
- Cách ly chế độ chờ khỏi lỗi sản xuất (ví dụ:sao chép chậm cho mysql)
- Tránh mất dữ liệu (sao chép đồng bộ hóa)
- Sử dụng hệ thống dự phòng
- Cách sử dụng chế độ chờ
- Chuyển đổi dự phòng, Chuyển đổi và khôi phục tự động
- Chuyển đổi dự phòng cơ sở dữ liệu
- Chuyển đổi dự phòng ứng dụng minh bạch (TAF so với ProxySQL, MaxScale)
- Bảo mật
- Dễ sử dụng và quản lý (quản lý thống nhất các thành phần được tích hợp trước)
Tính nhất quán và sẵn có của dữ liệu
MySQL GTID
Bản sao MySQL 5.5 dựa trên các sự kiện nhật ký nhị phân, trong đó tất cả những gì một nô lệ biết là sự kiện chính xác và vị trí chính xác mà nó vừa đọc được từ bản chính. Bất kỳ giao dịch đơn lẻ nào từ một chủ có thể đã kết thúc trong nhiều nhật ký nhị phân khác nhau từ các nô lệ khác nhau và giao dịch thường sẽ có các vị trí khác nhau trong các nhật ký này. Đó là một giải pháp đơn giản nhưng có những hạn chế, các thay đổi về cấu trúc liên kết có thể yêu cầu quản trị viên ngừng sao chép trên các phiên bản có liên quan. Những thay đổi này có thể gây ra một số vấn đề khác, ví dụ:không thể di chuyển nô lệ xuống chuỗi sao chép mà không mất thời gian xây dựng lại. Việc sửa một liên kết sao chép bị hỏng sẽ yêu cầu xác định thủ công tệp nhật ký nhị phân mới và vị trí của giao dịch cuối cùng được thực hiện trên nô lệ và tiếp tục từ đó hoặc xây dựng lại toàn bộ. Tất cả chúng tôi đã phải giải quyết những hạn chế này trong khi mơ về một số nhận dạng giao dịch toàn cầu.
MySQL phiên bản 5.6 (và MariaDB phiên bản 10.0.2) đã giới thiệu một cơ chế để giải quyết vấn đề này. GTID (Mã định danh giao dịch toàn cầu) cung cấp ánh xạ giao dịch tốt hơn giữa các nút.
Với GTID, nô lệ có thể thấy một giao dịch duy nhất đến từ một số chủ và điều này có thể dễ dàng được ánh xạ vào danh sách thực thi nô lệ nếu nó cần khởi động lại hoặc tiếp tục sao chép. Vì vậy, lời khuyên là hãy luôn sử dụng GTID. Lưu ý rằng MySQL và MariaDB có các triển khai GTID khác nhau.
Oracle SCN
Năm 1992 với bản phát hành 7.3 Oracle đã giới thiệu một giải pháp để giữ một bản sao đồng bộ của cơ sở dữ liệu ở chế độ chờ, được gọi là Data Guard từ phiên bản 9i phiên bản 2. Cấu hình Data Guard bao gồm hai thành phần chính, một cơ sở dữ liệu chính duy nhất và một cơ sở dữ liệu dự phòng. (lên đến 30). Các thay đổi trên cơ sở dữ liệu chính được chuyển qua cơ sở dữ liệu dự phòng và những thay đổi này được áp dụng cho cơ sở dữ liệu dự phòng để giữ cho nó được đồng bộ hóa.
Oracle Data Guard ban đầu được tạo từ một bản sao lưu của cơ sở dữ liệu chính. Data Guard tự động đồng bộ hóa cơ sở dữ liệu chính và tất cả cơ sở dữ liệu dự phòng bằng cách truyền tải dữ liệu chính làm lại - thông tin được sử dụng bởi mọi Cơ sở dữ liệu Oracle để bảo vệ các giao dịch - và áp dụng nó vào cơ sở dữ liệu dự phòng. Oracle sử dụng một cơ chế nội bộ được gọi là SCN (System Change Number). Số thay đổi hệ thống (SCN) là đồng hồ của Oracle, mỗi khi chúng tôi cam kết, đồng hồ sẽ tăng lên. SCN đánh dấu một thời điểm nhất quán trong cơ sở dữ liệu là một điểm kiểm tra là hành động ghi các khối bẩn (các khối đã sửa đổi từ bộ đệm cache vào đĩa). Chúng ta có thể so sánh nó với GTID trong MySQL.
Các dịch vụ truyền tải của Data Guard xử lý tất cả các khía cạnh của việc truyền tải lại từ cơ sở dữ liệu chính đến cơ sở dữ liệu dự phòng. Khi người dùng thực hiện các giao dịch trên bản ghi chính, các bản ghi làm lại được tạo và ghi vào tệp nhật ký trực tuyến cục bộ. Các dịch vụ truyền tải Data Guard đồng thời truyền cùng một quá trình làm lại trực tiếp từ bộ đệm nhật ký cơ sở dữ liệu chính (bộ nhớ được phân bổ trong khu vực toàn cầu của hệ thống) đến (các) cơ sở dữ liệu dự phòng nơi nó được ghi vào tệp nhật ký làm lại dự phòng.
Có một số khác biệt chính giữa bản sao MySQL và Data Guard. Truyền trực tiếp từ bộ nhớ của Data Guard sẽ tránh được phí I / O của đĩa trên cơ sở dữ liệu chính. Nó khác với cách MySQL hoạt động - đọc dữ liệu từ bộ nhớ làm giảm I / O trên cơ sở dữ liệu chính.
Data Guard chỉ truyền cơ sở dữ liệu làm lại. Nó hoàn toàn trái ngược với sao chép từ xa trong bộ nhớ phải truyền mọi khối đã thay đổi trong mọi tệp để duy trì đồng bộ hóa theo thời gian thực.
Mô hình Async + Sync
Oracle Data Guard cung cấp ba mô hình khác nhau để áp dụng làm lại. Các mô hình thích ứng phụ thuộc vào phần cứng, quy trình có sẵn và cuối cùng là nhu cầu kinh doanh.
- Hiệu suất Tối đa - chế độ hoạt động mặc định, cho phép một giao dịch cam kết ngay khi dữ liệu làm lại cần thiết để khôi phục giao dịch đó được ghi vào nhật ký làm lại cục bộ trên bản chính.
- Bảo vệ tối đa - không mất dữ liệu và mức bảo vệ tối đa. Dữ liệu làm lại cần thiết để cải thiện từng thao tác phải được ghi vào cả nhật ký làm lại trực tuyến cục bộ trên chính và nhật ký làm lại dự phòng trên ít nhất một cơ sở dữ liệu dự phòng trước khi thực hiện giao dịch (Oracle khuyến nghị ít nhất hai dự phòng). Cơ sở dữ liệu chính sẽ ngừng hoạt động nếu lỗi chặn nó ghi luồng làm lại vào ít nhất một cơ sở dữ liệu dự phòng được đồng bộ hóa.
- Tính khả dụng tối đa - tương tự như Bảo vệ tối đa nhưng cơ sở dữ liệu chính sẽ không tắt nếu có lỗi khiến nó không thể ghi luồng làm lại của mình.
Khi nói đến việc chọn thiết lập sao chép MySQL của bạn, bạn có sự lựa chọn giữa sao chép không đồng bộ hoặc sao chép bán đồng bộ.
- Áp dụng binlog không đồng bộ là phương pháp mặc định để sao chép MySQL. Master ghi các sự kiện vào nhật ký nhị phân của nó và các nô lệ yêu cầu chúng khi chúng sẵn sàng. Không có gì đảm bảo rằng bất kỳ sự kiện nào cũng sẽ đến tay bất kỳ nô lệ nào.
- Cam kết bán đồng bộ trên chính bị trì hoãn cho đến khi cái chính nhận được xác nhận từ bộ phụ bán đồng bộ rằng dữ liệu được nhận và ghi bởi bộ phụ. Xin lưu ý rằng sao chép bán đồng bộ yêu cầu cài đặt thêm một plugin.
Sử dụng hệ thống dự phòng
MySQL nổi tiếng về tính đơn giản và tính linh hoạt trong sao chép của nó. Theo mặc định, bạn có thể đọc hoặc thậm chí ghi vào máy chủ chờ / máy chủ nô lệ của mình. May mắn thay, MySQL 5.6 và 5.7 đã mang lại nhiều cải tiến đáng kể cho Replication, bao gồm ID giao dịch toàn cầu, tổng kiểm tra sự kiện, nô lệ đa luồng và nô lệ / chủ an toàn khi gặp sự cố để làm cho nó thậm chí còn tốt hơn. Các DBA đã quen với việc đọc và ghi sao chép MySQL sẽ mong đợi một giải pháp tương tự hoặc thậm chí đơn giản hơn từ người anh lớn hơn của nó, Oracle. Rất tiếc, không phải theo mặc định.
Việc triển khai chế độ chờ vật lý tiêu chuẩn cho Oracle được đóng lại đối với bất kỳ hoạt động đọc-ghi nào. Trên thực tế, Oracle cung cấp các biến thể logic nhưng nó có nhiều hạn chế và nó không được thiết kế cho HA. Giải pháp cho vấn đề này là một tính năng trả phí bổ sung được gọi là Active Data Guard, bạn có thể sử dụng tính năng này để đọc dữ liệu từ chế độ chờ trong khi áp dụng các bản ghi làm lại.
Active Data Guard là giải pháp bổ trợ trả phí cho phần mềm khôi phục sau thảm họa Data Guard miễn phí của Oracle chỉ dành cho Oracle Database Enterprise Edition (giấy phép có giá cao nhất). Nó cung cấp quyền truy cập chỉ đọc, đồng thời liên tục áp dụng các thay đổi được gửi từ cơ sở dữ liệu chính. Là một cơ sở dữ liệu dự phòng hoạt động, nó giúp giảm tải các truy vấn đọc, báo cáo và sao lưu gia tăng từ cơ sở dữ liệu chính. Kiến trúc của sản phẩm được thiết kế để cho phép cơ sở dữ liệu dự phòng được cách ly khỏi các lỗi có thể xảy ra ở cơ sở dữ liệu chính.
Một tính năng thú vị của cơ sở dữ liệu Oracle 12c và một thứ mà Oracle DBA sẽ bỏ lỡ là xác nhận tham nhũng dữ liệu. Kiểm tra tham nhũng của Oracle Data Guard được thực hiện để đảm bảo rằng dữ liệu được căn chỉnh chính xác trước khi dữ liệu được sao chép vào cơ sở dữ liệu dự phòng. Cơ chế này cũng có thể được sử dụng để khôi phục các khối dữ liệu trên cơ sở dữ liệu chính trực tiếp từ cơ sở dữ liệu dự phòng.
Chuyển đổi dự phòng, Chuyển mạch và Phục hồi Tự động
Để giữ cho thiết lập sao chép của bạn ổn định và chạy, điều quan trọng là hệ thống phải có khả năng phục hồi trước các lỗi. Lỗi do lỗi phần mềm, sự cố cấu hình hoặc phần cứng và có thể xảy ra bất cứ lúc nào. Trong trường hợp máy chủ gặp sự cố, bạn cần thông báo cảnh báo về thiết lập bị xuống cấp. Quản trị viên có thể thực hiện chuyển đổi dự phòng (thăng cấp nô lệ thành chủ), người này cần quyết định quảng bá nô lệ nào.
Người quản trị cần thông tin về lỗi, trạng thái đồng bộ hóa trong trường hợp bất kỳ dữ liệu nào sẽ bị mất và cuối cùng là các bước để thực hiện hành động. Tốt nhất, tất cả phải được tự động hóa và hiển thị từ một bảng điều khiển duy nhất.
Có hai cách tiếp cận chính để chuyển đổi dự phòng MySQL, tự động và thủ công. Cả hai tùy chọn đều có người hâm mộ của nó, chúng tôi mô tả các khái niệm trong một bài viết khác.
Với GTID, việc chuyển đổi dự phòng thủ công trở nên dễ dàng hơn nhiều. Nó bao gồm các bước như:
- Dừng mô-đun bộ thu (STOP SLAVE IO_THREAD)
- Chuyển đổi trang cái (ĐỔI MASTER TO
) - Khởi động mô-đun bộ thu (START SLAVE IO_THREAD)
Oracle Data Guard đi kèm với giải pháp chuyển đổi / chuyển đổi dự phòng chuyên dụng - Data Guard Broker. Nhà môi giới là một khung quản lý phân tán tự động hóa và tập trung hóa việc tạo, bảo trì và giám sát các cấu hình Oracle Data Guard. Với quyền truy cập vào công cụ môi giới DG, bạn có thể thực hiện các thay đổi cấu hình, chuyển đổi, chuyển đổi dự phòng và thậm chí kiểm tra nhanh thiết lập tính khả dụng cao của mình. Hai hành động chính là:
- Lệnh SWITCHOVER TO
được sử dụng để thực hiện thao tác chuyển đổi. Sau khi hoạt động chuyển đổi thành công, các cá thể cơ sở dữ liệu sẽ chuyển đổi vị trí và tiếp tục sao chép. Không thể chuyển đổi khi chế độ chờ không phản hồi hoặc ngừng hoạt động. - FAILOVER TO
phổ biến được sử dụng để thực hiện chuyển đổi dự phòng. Sau hoạt động chuyển đổi dự phòng, máy chủ chính trước đó yêu cầu hoạt động lại nhưng máy chủ chính mới có thể nhận khối lượng công việc cơ sở dữ liệu.
Nói về chuyển đổi dự phòng, chúng ta cần xem xét khả năng chuyển đổi dự phòng ứng dụng của bạn liền mạch như thế nào. Trong trường hợp ngừng hoạt động theo kế hoạch / không có kế hoạch, các phiên của người dùng có thể được chuyển hướng đến trang web phụ một cách hiệu quả như thế nào, với sự gián đoạn kinh doanh tối thiểu.
Cách tiếp cận tiêu chuẩn cho MySQL sẽ là sử dụng một trong các Bộ cân bằng tải có sẵn. Bắt đầu từ HAProxy được sử dụng rộng rãi để chuyển đổi dự phòng HTTP hoặc TCP / IP sang Maxscale hoặc ProxySQL nhận biết cơ sở dữ liệu.
Trong Oracle, vấn đề này được giải quyết bằng TAF (Chuyển đổi dự phòng ứng dụng minh bạch). Sau khi chuyển đổi hoặc chuyển đổi dự phòng xảy ra, ứng dụng sẽ tự động được chuyển hướng đến ứng dụng chính mới. TAF cho phép ứng dụng kết nối lại tự động và minh bạch với cơ sở dữ liệu mới, nếu phiên bản cơ sở dữ liệu mà kết nối được thực hiện không thành công.
Bảo mật
Bảo mật dữ liệu là một vấn đề nóng đối với nhiều tổ chức ngày nay. Đối với những người cần triển khai các tiêu chuẩn như PCI DSS hoặc HIPAA, bảo mật cơ sở dữ liệu là điều bắt buộc. Môi trường WAN chéo có thể dẫn đến những lo ngại về quyền riêng tư và bảo mật dữ liệu, đặc biệt là khi ngày càng có nhiều doanh nghiệp phải tuân thủ các quy định quốc gia và quốc tế. Nhật ký nhị phân MySQL được sử dụng để sao chép có thể chứa dữ liệu nhạy cảm dễ đọc. Với cấu hình tiêu chuẩn, việc lấy cắp dữ liệu là một quá trình rất dễ dàng. MySQL hỗ trợ SSL như một cơ chế để mã hóa lưu lượng cả giữa các máy chủ MySQL (sao chép) và giữa các máy chủ và máy khách MySQL. Một cách điển hình để triển khai mã hóa SSL là sử dụng chứng chỉ tự ký. Hầu hết thời gian, không bắt buộc phải có chứng chỉ SSL do Tổ chức phát hành chứng chỉ cấp. Bạn có thể sử dụng openssl để tạo chứng chỉ, ví dụ bên dưới:
$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pemSau đó, sửa đổi bản sao với các tham số cho SSL.
….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';Để có thêm tùy chọn tự động, bạn có thể sử dụng ClusterControl để bật mã hóa và quản lý khóa SSL.
Trong Oracle 12c, quá trình truyền tải lại Data Guard có thể được tích hợp với một tập hợp các tính năng bảo mật chuyên dụng được gọi là Oracle Advanced Security (OAS). Bảo mật nâng cao có thể được sử dụng để kích hoạt các dịch vụ mã hóa và xác thực giữa hệ thống chính và hệ thống dự phòng. Ví dụ:bật thuật toán mã hóa Advanced Encryption Standard (AES) chỉ yêu cầu một số thay đổi tham số trong tệp sqlnet.ora để thực hiện mã hóa redo (tương tự như MySQL binlog). Không cần thiết lập chứng chỉ bên ngoài và nó chỉ yêu cầu khởi động lại cơ sở dữ liệu dự phòng. Việc sửa đổi trong sqlnet.ora và wallet rất đơn giản như sau:
Tạo một thư mục ví
mkdir /u01/app/walletChỉnh sửa sqlnet.ora
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/u01/app/wallet)))Tạo kho khóa
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;Mở cửa hàng
ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;Tạo khóa chính
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;Ở chế độ chờ
sao chép các tệp p12 và .sso trong thư mục wallet và để cập nhật tệp sqlnet.ora tương tự như nút chính.
Để biết thêm thông tin, vui lòng theo dõi sách trắng TDE của Oracle, bạn có thể học từ sách trắng cách mã hóa datafile và làm cho ví luôn mở.
Dễ sử dụng và quản lý
Khi quản lý hoặc triển khai cấu hình Oracle Data Guard, bạn có thể thấy rằng có nhiều bước và tham số cần tìm. Để trả lời điều đó, Oracle đã tạo ra DG Broker.
Bạn chắc chắn có thể tạo cấu hình Data Guard mà không cần triển khai DG Broker nhưng nó có thể giúp cuộc sống của bạn thoải mái hơn nhiều. Khi nó được triển khai, tiện ích dòng lệnh của Nhà môi giới - DGMGRL có lẽ là lựa chọn chính cho DBA. Đối với những người thích GUI, Cloud Control 13c có tùy chọn để truy cập DG Broker qua giao diện web.
Các tác vụ mà Broker có thể trợ giúp là tự động bắt đầu khôi phục được quản lý, một lệnh để chuyển đổi / chuyển đổi dự phòng, giám sát quá trình sao chép DG, xác minh cấu hình và nhiều tác vụ khác.
DGMGRL> show configuration
Configuration - orcl_s9s_config
Protection Mode: MaxPerformance
Members:
s9sp - Primary database
s9ss - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 12 seconds agoMySQL không cung cấp giải pháp tương tự cho Oracle DG Broker. Tuy nhiên, bạn có thể mở rộng chức năng của nó bằng cách sử dụng các công cụ như Orchestrator, MHA và bộ cân bằng tải (ProxySQL, HAProxy hoặc Maxscale). Giải pháp để quản lý cơ sở dữ liệu và bộ cân bằng tải là ClusterControl. ClusterControl Enterprise Edition sẽ cung cấp cho bạn một tập hợp đầy đủ các tính năng quản lý và mở rộng quy mô ngoài các chức năng triển khai và giám sát được cung cấp như một phần của Phiên bản Cộng đồng miễn phí.
