Услугата за релационна база данни на Amazon (AWS RDS) е напълно управлявана услуга за база данни, която може да поддържа множество машини за бази данни. Сред поддържаните са PostgreSQL, MySQL и MariaDB. ClusterControl, от друга страна, е софтуер за управление и автоматизация на база данни, който също поддържа обработка на архиви за бази данни с отворен код PostgreSQL, MySQL и MariaDB.
Докато RDS е широко възприет от много компании, някои може да не са запознати с това как работи тяхното възстановяване във времето (PITR) и как може да се използва.
Няколко от машините за бази данни, използвани от Amazon RDS, имат специални съображения при възстановяване от определен момент във времето и в този блог ще разгледаме как работи за PostgreSQL, MySQL и MariaDB. Ще сравним също как се различава с функцията PITR в ClusterControl.
Какво е възстановяване по време (PITR)
Ако все още не сте запознати с планирането за аварийно възстановяване (DRP) или планирането за непрекъснатост на бизнеса (BCP), трябва да знаете, че PITR е една от важните стандартни практики за управление на база данни. Както беше споменато в предишния ни блог, Point In Time Recovery (PITR) включва възстановяване на базата данни във всеки един момент в миналото. За да можем да направим това, ще трябва да възстановим пълен архив и след това PITR се извършва чрез прилагане на всички промени, настъпили в определен момент от време, който искате да възстановите.
Възстановяване в момента (PITR) с AWS RDS
AWS RDS обработва PITR по различен начин от традиционния начин, общ за локалната база данни. Крайният резултат споделя същата концепция, но с AWS RDS пълното архивиране е моментна снимка, след това прилага PITR (който се съхранява в S3) и след това стартира нов (различен) екземпляр на база данни.
Общият начин изисква да използвате или логически (използвайки pg_dump, mysqldump, mydumper) или физически (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) за пълното си архивиране, преди да приложите PITR.
AWS RDS ще изисква от вас да стартирате нов DB екземпляр, докато традиционният подход ви позволява гъвкаво да съхранявате PITR на същия възел на базата данни, където е направено архивиране, или да насочвате към различен (съществуващ) DB екземпляр, който се нуждае от възстановяване или до нов екземпляр на БД.
При създаването на вашия AWS RDS екземпляр автоматичното архивиране ще бъде включено. Amazon RDS автоматично извършва пълна ежедневна снимка на вашите данни. Графиците за моментни снимки могат да бъдат зададени по време на създаването в предпочитания от вас прозорец за архивиране. Докато автоматичното архивиране е включено, AWS също заснема регистрационни файлове на транзакциите в Amazon S3 на всеки 5 минути, като записва всичките ви актуализации на БД. След като стартирате възстановяване в даден момент, регистрационните файлове на транзакциите се прилагат към най-подходящото ежедневно архивиране, за да възстановите вашия DB екземпляр до конкретното поискано време.
Как да приложите PITR с AWS RDS
Прилагането на PITR може да стане по три различни начина. Можете да използвате AWS Management Console, AWS CLI или Amazon RDS API, след като DB екземплярът е наличен. Трябва също да вземете предвид, че регистрационните файлове на транзакциите се заснемат на всеки пет минути, които след това се съхраняват в AWS S3.
След като възстановите DB екземпляр, групата за защита на DB по подразбиране (SG) се прилага към новия DB екземпляр. Ако имате нужда от персонализирания db SG, можете изрично да го дефинирате чрез конзолата за управление на AWS, командата modify-db-instance на AWS CLI или операцията ModifyDBInstance на Amazon RDS API, след като DB екземплярът е наличен.
PITR изисква да идентифицирате най-новото време за възстановяване за DB екземпляр. За да направите това, можете да използвате командата describe-db-instances на AWS CLI и да погледнете стойността, върната в полето LatestRestorableTime за DB екземпляра. Например,
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Прилагане на PITR с AWS Console
За да приложите PITR в AWS Console, влезте в AWS Console → отидете на Amazon RDS → Бази данни → Изберете (или щракнете) желания DB екземпляр, след което щракнете върху Действия. Вижте по-долу,
След като се опитате да възстановите чрез PITR, потребителският интерфейс на конзолата ще ви уведоми какво е най-новото време за възстановяване, което можете да зададете. Можете да използвате най-новото време за възстановяване или да посочите желаната от вас целева дата и час. Вижте по-долу:
Това е доста лесно за следване, но изисква да обърнете внимание и да попълните желаните спецификации, от които се нуждаете, за да бъде стартиран новият екземпляр.
Прилагане на PITR с AWS CLI
Използването на AWS CLI може да бъде доста удобно, особено ако трябва да включите това с вашите инструменти за автоматизация за вашия CI/CD конвейер. За да направите това, можете да започнете просто с,
[[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": []
}
}И двата подхода отнемат време за създаване или подготовка на екземпляра на базата данни, докато той стане достъпен и видим в списъка с екземпляри на база данни във вашата AWS RDS конзола.
Ограничения на AWS RDS PITR
Когато използвате AWS RDS, вие сте обвързани с тях като доставчик. Преместването на вашите операции извън тяхната система може да бъде обезпокоително. Ето някои неща, които трябва да имате предвид:
- Нивото на заключване на доставчика при използване на AWS RDS
- Единствената ви опция за възстановяване чрез PITR изисква да стартирате нов екземпляр, работещ на RDS
- Няма начин да възстановите с помощта на PITR процес към външен възел, който не е в RDS
- Изисква от вас да научите и да сте запознати с техните инструменти и рамка за сигурност.
Как да приложите PITR с ClusterControl
ClusterControl изпълнява PITR по прост, но ясен начин (но изисква да активирате или зададете предпоставките, за да може да се използва PITR). Както беше обсъдено по-рано, PITR за ClusterControl работи по различен начин от AWS RDS. Ето списък с къде може да се приложи PITR с помощта на ClusterControl (от версия 1.7.6):
- Прилага се след пълното архивиране въз основа на наличните решения за метод за архивиране, които поддържаме за бази данни PostgreSQL, MySQL и MariaDB.
- За PostgreSQL се поддържа само pg_basebackup метод за архивиране и е съвместим за работа с PITR
- За MySQL или MariaDB се поддържа само xtrabackup/mariabackup метод за архивиране и е съвместим за работа с PITR
- Приложимо за бази данни MySQL или MariaDB, PITR се прилага само ако изходният възел на пълното архивиране е целевият възел, който трябва да бъде възстановен.
- базите данни MySQL или MariaDB изисква да имате активиран двоичен журнал
- Приложимо за PostgreSQL бази данни, PITR се прилага само за активния главен/основен и изисква да активирате WAL архивиране.
- PITR може да се приложи само при възстановяване на съществуващ пълен архив
Управлението на архивиране за ClusterControl е приложимо за среди, където базите данни не се управляват напълно и изисква SSH достъп, който е напълно различен от AWS RDS. Въпреки че споделят същия резултат, който е за възстановяване на данни, решенията за архивиране, които присъстват в ClusterControl, не могат да бъдат приложими в AWS RDS. ClusterControl също не поддържа RDS за управление и наблюдение.
Използване на ClusterControl за PITR в PostgreSQL
Както споменахме по-рано от предпоставките за използване на PITR, трябва да активирате WAL архивирането. Това може да се постигне чрез щракване върху иконата на зъбно колело, както е показано по-долу:
Тъй като PITR може да се приложи веднага след пълно архивиране, можете да стартирате само намерете тази функция в списъка за архивиране, където можете да опитате да възстановите съществуващ архив. За да направите това, последователността от екранни снимки ще ви покаже как да го направите:
След това го възстановете на същия хост като източника на резервното копие, както е взето ,
След това просто посочете датата и часа,
След като сте настроили и посочите датата и часа, ClusterControl ще възстанови архивирането след това приложете PITR, след като архивирането е направено. Можете също да потвърдите това, като прегледате регистрационните файлове за дейността, както по-долу,
Използване на ClusterControl за PITR в MySQL/MariaDB
PITR за MySQL или MariaDB не се различава от подхода, който имаме по-горе за PostgreSQL. Въпреки това, няма еквивалентност на архивиране на WAL, нито бутон или опция, които можете да зададете, които са необходими за активиране на функционалността PITR. Тъй като MySQL и MariaDB изискват PITR да може да се прилага с помощта на двоични регистрационни файлове, в ClusterControl това може да се обработва в раздела Управление. Вижте по-долу:
След това посочете променливата log_bin със съответната булева стойност. Например,
След като log_bin е зададен на възела, уверете се, че имате пълния архивиране, направено на същия възел, където ще приложите и процеса на PITR. Това е посочено по-рано в предпоставките. Като алтернатива можете просто да редактирате конфигурационните файлове (/etc/my.cnf или /etc/mysql/my.cnf) и да добавите log_bin=ON в секцията [mysqld], например.
Когато двоичните регистрационни файлове са активирани и е налично пълно архивиране, тогава можете да извършите PITR процеса по същия начин като потребителския интерфейс на PostgreSQL, но с различни полета, които можете да попълните. Можете да посочите датата и часа или посочете въз основа на файла и позицията на binlog (или позиция x &y). Вижте по-долу:
Ограничения на ClusterControl PITR
В случай, че се чудите какво можете и какво не можете да правите за PITR в ClusterControl, ето списъка по-долу:
- Няма текущ инструмент на s9s CLI, който да поддържа процеса PITR, така че не е възможно да се автоматизира или интегрира във вашия CI/CD конвейер.
- Няма поддръжка на PITR за външни възли
- Без поддръжка на PITR, когато източникът на архивирането е различен от целевия възел
- Няма такова периодично известие за най-новия период от време, за който можете да кандидатствате за PITR
Заключение
И двата инструмента имат различни подходи и различни решения за целевата среда. Основният извод е, че AWS RDS има свой собствен PITR, който е по-бърз, но е приложим само ако вашата база данни се хоства под RDS и сте обвързани с заключването на доставчика.
ClusterControl ви позволява свободно да прилагате процеса PITR към всеки център за данни или локален, стига да се вземат предвид предпоставките. Целта му е да възстанови данните. Независимо от неговите ограничения, то се основава на начина, по който ще използвате решението в съответствие с архитектурната среда, която използвате.
