MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

So sánh Amazon RDS Point-in-Time Recovery với ClusterControl

Dịch vụ cơ sở dữ liệu quan hệ Amazon (AWS RDS) là một dịch vụ cơ sở dữ liệu được quản lý đầy đủ có thể hỗ trợ nhiều công cụ cơ sở dữ liệu. Trong số những người được hỗ trợ có PostgreSQL, MySQL và MariaDB. Mặt khác, ClusterControl là một phần mềm tự động hóa và quản lý cơ sở dữ liệu cũng hỗ trợ xử lý sao lưu cho các cơ sở dữ liệu mã nguồn mở PostgreSQL, MySQL và MariaDB.

Mặc dù RDS đã được nhiều công ty chấp nhận rộng rãi, nhưng một số công ty có thể không quen với cách hoạt động của tính năng Phục hồi theo thời gian (PITR) của họ và cách nó có thể được sử dụng.

Một số công cụ cơ sở dữ liệu được Amazon RDS sử dụng có những cân nhắc đặc biệt khi khôi phục từ một thời điểm cụ thể và trong blog này, chúng tôi sẽ trình bày cách hoạt động của nó đối với PostgreSQL, MySQL và MariaDB. Chúng tôi cũng sẽ so sánh sự khác biệt của nó với hàm PITR trong ClusterControl.

Khôi phục theo thời gian (PITR) là gì

Nếu bạn chưa quen với Lập kế hoạch khôi phục sau thảm họa (DRP) hoặc Lập kế hoạch liên tục kinh doanh (BCP), bạn nên biết rằng PITR là một trong những thực hành tiêu chuẩn quan trọng để quản lý cơ sở dữ liệu. Như đã đề cập trong blog trước của chúng tôi, Point In Time Recovery (PITR) liên quan đến việc khôi phục cơ sở dữ liệu tại bất kỳ thời điểm nào trong quá khứ. Để có thể thực hiện việc này, chúng tôi sẽ cần khôi phục một bản sao lưu đầy đủ và sau đó PITR diễn ra bằng cách áp dụng tất cả các thay đổi đã xảy ra tại một thời điểm cụ thể mà bạn muốn khôi phục.

Khôi phục điểm trong thời gian (PITR) với AWS RDS

AWS RDS xử lý PITR khác với cách truyền thống phổ biến đối với cơ sở dữ liệu tại chỗ. Kết quả cuối cùng có chung một khái niệm, nhưng với AWS RDS, bản sao lưu đầy đủ là một ảnh chụp nhanh, sau đó nó áp dụng PITR (được lưu trữ trong S3), rồi khởi chạy phiên bản cơ sở dữ liệu mới (khác).

Cách phổ biến yêu cầu bạn sử dụng một bản sao lưu lôgic (sử dụng pg_dump, mysqldump, mydumper) hoặc vật lý (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) để sao lưu đầy đủ trước khi bạn áp dụng PITR.

AWS RDS sẽ yêu cầu bạn khởi chạy phiên bản DB mới, trong khi cách tiếp cận truyền thống cho phép bạn lưu trữ linh hoạt PITR trên cùng một nút cơ sở dữ liệu nơi sao lưu được thực hiện hoặc nhắm mục tiêu một phiên bản DB khác (hiện có) cần khôi phục hoặc một phiên bản DB mới.

Khi tạo phiên bản AWS RDS, sao lưu tự động sẽ được bật. Amazon RDS tự động thực hiện ảnh chụp nhanh toàn bộ dữ liệu hàng ngày của bạn. Lịch trình chụp nhanh có thể được đặt trong quá trình tạo tại cửa sổ sao lưu ưa thích của bạn. Trong khi sao lưu tự động được bật, AWS cũng ghi lại nhật ký giao dịch vào Amazon S3 5 phút một lần, ghi lại tất cả các bản cập nhật DB của bạn. Sau khi bạn bắt đầu khôi phục tại thời điểm, nhật ký giao dịch được áp dụng cho bản sao lưu hàng ngày thích hợp nhất để khôi phục phiên bản DB của bạn về thời gian được yêu cầu cụ thể.

Cách áp dụng PITR với AWS RDS

Việc áp dụng PITR có thể được thực hiện theo ba cách khác nhau. Bạn có thể sử dụng Bảng điều khiển quản lý AWS, AWS CLI hoặc API Amazon RDS sau khi phiên bản DB khả dụng. Bạn cũng phải lưu ý rằng nhật ký giao dịch được ghi lại sau mỗi năm phút, sau đó được lưu trữ trong AWS S3.

Sau khi bạn khôi phục một phiên bản DB, nhóm bảo mật DB mặc định (SG) sẽ được áp dụng cho phiên bản DB mới. Nếu bạn cần db SG tùy chỉnh, bạn có thể xác định rõ ràng điều này bằng cách sử dụng Bảng điều khiển quản lý AWS, lệnh AWS CLI mod-db-instance hoặc hoạt động Amazon RDS API ModifyDBInstance sau khi phiên bản DB khả dụng.

PITR yêu cầu bạn cần xác định thời gian khôi phục mới nhất cho một phiên bản DB. Để thực hiện việc này, bạn có thể sử dụng lệnh AWS CLI description-db-instance và xem giá trị được trả về trong trường LatestRestworthyTime cho cá thể DB. Ví dụ,

[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime

            "LatestRestorableTime": "2020-05-08T07:25:00+00:00",

Áp dụng PITR với Bảng điều khiển AWS

Để áp dụng PITR trong Bảng điều khiển AWS, hãy đăng nhập vào Bảng điều khiển AWS → chuyển đến Amazon RDS → Cơ sở dữ liệu → Chọn (hoặc nhấp vào) phiên bản DB mong muốn của bạn, sau đó nhấp vào Hành động. Xem bên dưới,

Sau khi bạn cố gắng khôi phục qua PITR, giao diện người dùng bảng điều khiển sẽ thông báo cho bạn những gì thời gian phục hồi mới nhất mà bạn có thể đặt. Bạn có thể sử dụng thời gian khôi phục mới nhất hoặc chỉ định ngày và giờ mục tiêu mong muốn của mình. Xem bên dưới:

Cách làm khá dễ dàng nhưng đòi hỏi bạn phải chú ý và điền đầy đủ thông tin các thông số kỹ thuật mong muốn mà bạn cần để phiên bản mới được khởi chạy.

Áp dụng PITR với AWS CLI

Sử dụng AWS CLI có thể khá tiện dụng, đặc biệt nếu bạn cần kết hợp điều này với các công cụ tự động hóa cho đường ống CI / CD của mình. Để làm điều này, bạn có thể bắt đầu đơn giản với,

[[email protected] ~]# aws rds restore-db-instance-to-point-in-time \

>     --source-db-instance-identifier  database-s9s-mysql \

>     --target-db-instance-identifier  database-s9s-mysql-pitr \

>     --restore-time 2020-05-08T07:30:00+00:00

{

    "DBInstance": {

        "DBInstanceIdentifier": "database-s9s-mysql-pitr",

        "DBInstanceClass": "db.t2.micro",

        "Engine": "mysql",

        "DBInstanceStatus": "creating",

        "MasterUsername": "admin",

        "DBName": "s9s",

        "AllocatedStorage": 18,

        "PreferredBackupWindow": "00:00-00:30",

        "BackupRetentionPeriod": 7,

        "DBSecurityGroups": [],

        "VpcSecurityGroups": [

            {

                "VpcSecurityGroupId": "sg-xxxxx",

                "Status": "active"

            }

        ],

        "DBParameterGroups": [

            {

                "DBParameterGroupName": "default.mysql5.7",

                "ParameterApplyStatus": "in-sync"

            }

        ],

        "DBSubnetGroup": {

            "DBSubnetGroupName": "default",

            "DBSubnetGroupDescription": "default",

            "VpcId": "vpc-f91bdf90",

            "SubnetGroupStatus": "Complete",

            "Subnets": [

                {

                    "SubnetIdentifier": "subnet-exxxxx",

                    "SubnetAvailabilityZone": {

                        "Name": "us-east-2a"

                    },

                    "SubnetStatus": "Active"

                },

                {

                    "SubnetIdentifier": "subnet-xxxxx",

                    "SubnetAvailabilityZone": {

                        "Name": "us-east-2c"

                    },

                    "SubnetStatus": "Active"

                },

                {

                    "SubnetIdentifier": "subnet-xxxxxx",

                    "SubnetAvailabilityZone": {

                        "Name": "us-east-2b"

                    },

                    "SubnetStatus": "Active"

                }

            ]

        },

        "PreferredMaintenanceWindow": "fri:06:01-fri:06:31",

        "PendingModifiedValues": {},

        "MultiAZ": false,

        "EngineVersion": "5.7.22",

        "AutoMinorVersionUpgrade": true,

        "ReadReplicaDBInstanceIdentifiers": [],

        "LicenseModel": "general-public-license",

        "OptionGroupMemberships": [

            {

                "OptionGroupName": "default:mysql-5-7",

                "Status": "pending-apply"

            }

        ],

        "PubliclyAccessible": true,

        "StorageType": "gp2",

        "DbInstancePort": 0,

        "StorageEncrypted": false,

        "DbiResourceId": "db-XXXXXXXXXXXXXXXXX",

        "CACertificateIdentifier": "rds-ca-2019",

        "DomainMemberships": [],

        "CopyTagsToSnapshot": false,

        "MonitoringInterval": 0,

        "DBInstanceArn": "arn:aws:rds:us-east-2:042171833148:db:database-s9s-mysql-pitr",

        "IAMDatabaseAuthenticationEnabled": false,

        "PerformanceInsightsEnabled": false,

        "DeletionProtection": false,

        "AssociatedRoles": []

    }

}

Cả hai cách tiếp cận này đều cần thời gian để tạo hoặc chuẩn bị phiên bản cơ sở dữ liệu cho đến khi nó có sẵn và có thể xem được trong danh sách các phiên bản cơ sở dữ liệu trong bảng điều khiển AWS RDS của bạn.

Giới hạn AWS RDS PITR

Khi sử dụng AWS RDS, bạn được ràng buộc với họ với tư cách là nhà cung cấp. Di chuyển các hoạt động của bạn ra khỏi hệ thống của họ có thể gây rắc rối. Dưới đây là một số điều bạn phải xem xét:

  • Mức độ hạn chế của nhà cung cấp khi sử dụng AWS RDS
  • Tùy chọn duy nhất của bạn để khôi phục qua PITR yêu cầu bạn khởi chạy phiên bản mới chạy trên RDS
  • Không có cách nào bạn có thể khôi phục bằng quy trình PITR đối với một nút bên ngoài không có trong RDS
  • Yêu cầu bạn tìm hiểu và làm quen với các công cụ và khung bảo mật của họ.

Cách áp dụng PITR với ClusterControl

ClusterControl thực hiện PITR theo cách đơn giản nhưng dễ hiểu (nhưng yêu cầu bạn phải bật hoặc đặt các điều kiện tiên quyết để PITR có thể được sử dụng). Như đã thảo luận trước đó, PITR cho ClusterControl hoạt động khác với AWS RDS. Dưới đây là danh sách những nơi có thể áp dụng PITR bằng ClusterControl (kể từ phiên bản 1.7.6):

  • Áp dụng sau khi sao lưu đầy đủ dựa trên các giải pháp phương pháp sao lưu có sẵn mà chúng tôi hỗ trợ cho cơ sở dữ liệu PostgreSQL, MySQL và MariaDB.
    • Đối với PostgreSQL, chỉ hỗ trợ phương pháp sao lưu pg_basebackup và tương thích để hoạt động với PITR
    • Đối với MySQL hoặc MariaDB, chỉ phương pháp sao lưu xtrabackup / mariabackup được hỗ trợ và tương thích để hoạt động với PITR
  • Có thể áp dụng cho cơ sở dữ liệu MySQL hoặc MariaDB, PITR chỉ áp dụng nếu nút nguồn của bản sao lưu đầy đủ là nút đích cần được khôi phục.
  • Cơ sở dữ liệu MySQL hoặc MariaDB yêu cầu bạn phải bật ghi nhật ký nhị phân
  • Có thể áp dụng cho cơ sở dữ liệu PostgreSQL, PITR chỉ áp dụng cho chính / chính đang hoạt động và yêu cầu bạn phải bật lưu trữ WAL.
  • PITR chỉ có thể được áp dụng khi khôi phục một bản sao lưu đầy đủ hiện có

Quản lý sao lưu cho ClusterControl có thể áp dụng cho các môi trường mà cơ sở dữ liệu không được quản lý đầy đủ và yêu cầu quyền truy cập SSH, điều này hoàn toàn khác với AWS RDS. Mặc dù chúng có chung kết quả là khôi phục dữ liệu, nhưng các giải pháp sao lưu có trong ClusterControl không thể áp dụng trong AWS RDS. ClusterControl cũng không hỗ trợ RDS để quản lý và giám sát.

Sử dụng ClusterControl cho PITR trong PostgreSQL

Như đã đề cập trước đó về các điều kiện tiên quyết để tận dụng PITR, bạn phải bật tính năng lưu trữ WAL. Có thể đạt được điều này bằng cách nhấp vào biểu tượng bánh răng như hình dưới đây:

Vì PITR có thể được áp dụng ngay sau khi sao lưu đầy đủ, bạn chỉ có thể chạy tìm tính năng này trong danh sách Sao lưu nơi bạn có thể thử khôi phục bản sao lưu hiện có. Để làm điều đó, chuỗi ảnh chụp màn hình sẽ hướng dẫn bạn cách thực hiện:

Sau đó, khôi phục nó trên cùng một máy chủ lưu trữ như nguồn của bản sao lưu như đã chụp ,

Sau đó, chỉ cần chỉ định ngày và giờ,

Khi bạn đã thiết lập và chỉ định ngày và giờ, ClusterControl sau đó sẽ khôi phục sau đó sao lưu áp dụng PITR sau khi sao lưu hoàn tất. Bạn cũng có thể xác minh điều này bằng cách kiểm tra nhật ký hoạt động công việc giống như bên dưới,

Sử dụng ClusterControl cho PITR trong MySQL / MariaDB

PITR cho MySQL hoặc MariaDB không khác với cách tiếp cận mà chúng tôi có ở trên cho PostgreSQL. Tuy nhiên, không có sự tương đương về lưu trữ WAL cũng như không có nút hoặc tùy chọn bạn có thể đặt được yêu cầu để kích hoạt chức năng PITR. Vì MySQL và MariaDB yêu cầu PITR có thể được áp dụng bằng nhật ký nhị phân, trong ClusterControl, điều này có thể được xử lý trong tab Quản lý. Xem bên dưới:

Sau đó chỉ định biến log_bin với giá trị boolean tương ứng. Ví dụ,

Khi log_bin được đặt trên nút, hãy đảm bảo rằng bạn có đầy đủ sao lưu được thực hiện trên cùng một nút nơi bạn cũng sẽ áp dụng quy trình PITR. Điều này đã được nêu trước đó trong điều kiện tiên quyết. Ngoài ra, bạn cũng có thể chỉ cần chỉnh sửa tệp cấu hình (/etc/my.cnf hoặc /etc/mysql/my.cnf) và thêm log_bin =ON trong phần [mysqld] chẳng hạn.

Khi nhật ký nhị phân được bật và có sẵn bản sao lưu đầy đủ, bạn có thể thực hiện quy trình PITR giống như cách giao diện người dùng PostgreSQL nhưng với các trường khác mà bạn có thể điền vào. Bạn có thể chỉ định ngày và giờ hoặc chỉ định dựa trên tệp và vị trí của binlog (hoặc vị trí x &y). Xem bên dưới:

Giới hạn PITR của ClusterControl

Trong trường hợp bạn đang tự hỏi mình có thể và không thể làm gì đối với PITR trong ClusterControl, đây là danh sách bên dưới:

  • Hiện tại không có công cụ CLI s9s nào hỗ trợ quy trình PITR, vì vậy không thể tự động hóa hoặc tích hợp vào đường dẫn CI / CD của bạn.
  • Không hỗ trợ PITR cho các nút bên ngoài
  • Không hỗ trợ PITR khi nguồn của bản sao lưu khác với nút đích
  • Không có thông báo định kỳ nào về khoảng thời gian gần nhất mà bạn có thể đăng ký PITR

Kết luận

Cả hai công cụ đều có các cách tiếp cận khác nhau và các giải pháp khác nhau cho môi trường mục tiêu. Điểm mấu chốt chính là AWS RDS có PITR riêng của nó nhanh hơn, nhưng chỉ áp dụng được nếu cơ sở dữ liệu của bạn được lưu trữ theo RDS và bạn bị ràng buộc bởi nhà cung cấp khóa.

ClusterControl cho phép bạn tự do áp dụng quy trình PITR cho bất kỳ trung tâm dữ liệu hoặc tại cơ sở nào miễn là các điều kiện tiên quyết được xem xét. Mục tiêu của nó là khôi phục dữ liệu. Bất kể giới hạn của nó là gì, nó dựa trên cách bạn sẽ sử dụng giải pháp phù hợp với môi trường kiến ​​trúc mà bạn đang sử dụng.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MariaDB ở Tokyo

  2. Chuyển sang MariaDB Backup

  3. Làm thế nào để ghi một số với Zeros hàng đầu trong MariaDB

  4. Tổng quan về Phân cụm ProxySQL trong ClusterControl

  5. Cách chuyển từ Oracle DB sang MariaDB