Дълбоко гмуркане на доставчик на облак:PostgreSQL на AWS Aurora

Колко дълбоко трябва да отидем с това? Ще започна с това да кажа, че към момента на писането на тази статия мога да намеря само 3 книги в Amazon за PostgreSQL в облака и 117 дискусии за PostgreSQL пощенски списъци за Aurora PostgreSQL. Това не изглежда много и оставя на мен, любопитния краен потребител на PostgreSQL, официалната документация като единственото място, където наистина мога да науча още нещо. Тъй като нямам нито способността, нито знанията да се приключения много по-дълбоко, има AWS re:Invent 2018 за тези, които търсят такъв вид тръпка. Мога да се задоволя със статията на Вернер за кворумите.

За да загрея, започнах от началната страница на Aurora PostgreSQL, където отбелязах, че бенчмаркът, показващ, че Aurora PostgreSQL е три пъти по-бърз от стандартен PostgreSQL, работещ на същия хардуер, датира от PostgreSQL 9.6. Както научих по-късно, 9.6.9 в момента е опцията по подразбиране при настройка на нов клъстер. Това е много добра новина за тези, които не искат или не могат да надстроят веднага. И защо само 99,99% наличност? Едно обяснение може да се намери в статията на Брус Момджиан.

Съвместимост

Според AWS, Aurora PostgreSQL е добавен заместител на PostgreSQL, а документацията гласи:

Кодът, инструментите и приложенията, които използвате днес със съществуващите си MySQL и PostgreSQL бази данни, могат да се използват с Aurora.

Това е подсилено от често задавани въпроси на Aurora:

Това означава, че повечето от кода, приложенията, драйверите и инструментите, които вече използвате днес с вашите PostgreSQL бази данни, могат да се използват с Aurora с малка или никаква промяна. Базата данни на Amazon Aurora е проектирана да бъде съвместима с PostgreSQL 9.6 и 10 и поддържа същия набор от разширения на PostgreSQL, които се поддържат с RDS за PostgreSQL 9.6 и 10, което улеснява преместването на приложения между двете машини.

„повечето“ в горния текст предполага, че няма 100% гаранция, в който случай тези, които търсят сигурност, трябва да обмислят закупуване на техническа поддръжка или от AWS Professional Services, или от партньорите на Aamazon Aurora. Като странична бележка забелязах, че нито един от професионалните хостинг доставчици на PostgreSQL, наемащи основни сътрудници на общността, не е в този списък.

От страницата с често задавани въпроси на Aurora научаваме също, че Aurora PostgreSQL поддържа същите разширения като RDS, което от своя страна изброява повечето разширения на общността и няколко екстри.

Концепции

Като част от Amazon RDS, Aurora PostgreSQL идва със собствена терминология:

• Клъстер:Първичен DB екземпляр в режим четене/запис и нула или повече копия на Aurora. Основната DB често се обозначава като главна в „диаграми на AWS“_ или записваща в конзолата на AWS. Въз основа на референтната диаграма можем да направим интересно наблюдение:Аврора пише три пъти. Тъй като латентността между AZ обикновено е по-висока, отколкото в рамките на една и съща AZ, транзакцията се счита за извършена веднага щом бъде записана в копието на данните в същата AZ, в противен случай забавянето и потенциалните прекъсвания между AZ.
• Обем на клъстера:Обем за съхранение на виртуална база данни, обхващащ множество AZ.
• URL адрес на Aurora:двойка „хост:порт“.
• Крайна точка на клъстера:URL адрес на Aurora за първичната DB. Има една крайна точка на клъстера.
• Крайна точка на четеца:URL адрес на Aurora за комплекта реплики. За да направим аналогия с DNS, това е псевдоним (CNAME). Заявките за четене са балансирани на натоварването между наличните реплики.
• Персонализирана крайна точка:URL адрес на Aurora към група, състояща се от един или повече DB екземпляри.
• Крайна точка на екземпляра:URL адрес на Aurora към конкретен DB екземпляр.
• Версия на Aurora:Версия на продукта, върната от `SELECT AURORA_VERSION();`.

Ефективност и наблюдение на PostgreSQL на AWS Aurora

Оразмеряване

Aurora PostgreSQL прилага конфигурация за най-добро предположение, която се основава на размера на DB екземпляр и капацитета за съхранение, оставяйки по-нататъшна настройка на DBA чрез използването на групи параметри на DB.

Когато избирате DB екземпляр, базирайте избора си на желаната стойност за max_connections.

Мащабиране

Aurora PostgreSQL разполага с автоматично и ръчно мащабиране. Хоризонталното мащабиране на прочетените реплики е автоматизирано чрез използване на показатели за производителност. Вертикалното мащабиране може да бъде автоматизирано чрез API.

Хоризонталното мащабиране отнема офлайн режима за няколко минути, докато подменя компютърната машина и извършва всякакви операции по поддръжка (надстройки, корекции). Ето защо AWS препоръчва извършването на такива операции по време на прозорци за поддръжка.

Мащабирането и в двете посоки е лесно:

На ниво съхранение пространството се добавя на стъпки от 10G. Разпределеното хранилище никога не се възстановява, вижте по-долу как да се справите с това ограничение.

Съхранение

Както бе споменато по-горе, Aurora PostgreSQL е проектирана да се възползва от кворумите, за да подобри последователността на производителността.

Тъй като основното хранилище се споделя от всички DB екземпляри в един и същ клъстер, не се изискват допълнителни записи на възли в режим на готовност. Освен това добавянето или премахването на DB екземпляри не променя основните данни.

Чудя се какви са тези IOs единици означава на месечната сметка? Често задаваните въпроси на Aurora идват отново на помощ, за да обяснят какво е IO е в контекста на наблюдението и фактурирането. Read IO като еквивалент на 8KiB страница от база данни, прочетена, и Write IO като еквивалент на 4KiB, записана в слоя за съхранение.

Висока конкурентност

За да се възползвате напълно от дизайна на Aurora с висока конкурентност, се препоръчва приложенията да са конфигурирани да управляват голям брой едновременни заявки и транзакции.

Приложенията, предназначени да насочват заявки за четене и записване към съответно резервни и първични възли на базата данни, ще се възползват от крайната точка на репликата на четеца Aurora PostgreSQL.

Връзките са балансирани на натоварването между репликите за четене.

Използвайки персонализирани крайни точки, екземпляри на база данни с по-голям капацитет могат да бъдат групирани заедно, за да се изпълнява интензивно натоварване, като например анализи.

Крайните точки на DB екземпляра могат да се използват за фино балансиране на натоварването или бързо преминаване при отказ.

Имайте предвид, че за да могат крайните точки на Reader да балансират натоварването на отделните заявки, всяка заявка трябва да бъде изпратена като нова връзка.

Кеширане

Aurora PostgreSQL използва техника Survivable Cache Warming, която гарантира, че датата в кеша на буфера се запазва, елиминирайки необходимостта от повторно попълване или загряване на кеша след рестартиране на базата данни.

Репликация

Времето за забавяне на репликацията между репликите се запазва в рамките на едноцифрена милисекунда. Въпреки че не е наличен за PostgreSQL, добре е да знаете, че забавянето на междурегионалната репликация се запазва в рамките на 10 секунди от милисекунди.

Според документацията забавянето на репликата се увеличава по време на периоди на тежки заявки за запис.

Планове за изпълнение на заявка

Въз основа на предположението, че производителността на заявката се влошава с течение на времето поради различни промени в базата данни, ролята на този компонент Aurora PostgreSQL е да поддържа списък с одобрени или отхвърлени планове за изпълнение на заявка.

Плановете се одобряват или отхвърлят чрез проактивни или реактивни методи.

Когато план за изпълнение е маркиран като отхвърлен, планът за изпълнение на заявка отменя решенията на оптимизатора на PostgreSQL и предотвратява изпълнението на „лошия“ план.

Тази функция изисква Aurora 2.1.0 или по-нова версия.

Висока наличност и репликация на PostgreSQL на AWS Aurora

На слоя за съхранение Aurora PostgreSQL гарантира издръжливост, като репликира всеки 10GB обем за съхранение, шест пъти в 3 AZs (всеки регион се състои обикновено от 3 AZs), използвайки физическа синхронна репликация. Това прави възможно записите в база данни да продължат да работят, дори когато 2 копия на данни са загубени. Наличността за четене оцелява при загуба на 3 копия на данните.

Прочетените реплики гарантират, че неуспешен първичен екземпляр може бързо да бъде заменен чрез популяризиране на една от 15-те налични реплики. При избор на внедряване с няколко AZ автоматично се създава една реплика за четене. Отказът не изисква намеса на потребителя и операциите с базата данни се възобновяват за по-малко от 30 секунди.

За разполагания с единична AZ процедурата за възстановяване включва възстановяване от последното известно добро архивиране. Според често задаваните въпроси на Aurora процесът завършва за по-малко от 15 минути, ако базата данни трябва да бъде възстановена в различен AZ. Документацията не е толкова конкретна, като се твърди, че отнема по-малко от 10 минути, за да завърши процеса на възстановяване.

Не се изисква промяна от страна на приложението, за да се свържете с новия DB екземпляр, тъй като крайната точка на клъстера не се променя по време на промоция на реплика или възстановяване на екземпляр.

Стъпка 1:изтрийте първичния екземпляр, за да принудите отказ:

Стъпка 2:автоматичното преминаване при отказ е завършено

За натоварени бази данни времето за възстановяване след рестартиране или срив е драстично намалено, тъй като Aurora PostgreSQL не трябва да възпроизвежда регистрационните файлове на транзакциите.

Като част от напълно управлявана услуга, лошите блокове с данни и дискове се заменят автоматично.

Преминаването на отказ, когато съществуват реплики, отнема до 120 секунди, като често времето е под 60 секунди. По-бързо време за възстановяване може да се постигне, когато условията за преминаване при отказ са предварително определени, като в този случай на репликите могат да бъдат присвоени приоритети за превключване при отказ.

Aurora PostgreSQL работи добре с Amazon RDS – екземпляр на Aurora може да действа като реплика за четене за първичен RDS екземпляр.

Aurora PostgreSQL поддържа логическа репликация, която, точно както в общностната версия, може да се използва за преодоляване на вградените ограничения за репликация. Няма автоматизация или конзолен интерфейс на AWS.

Сигурност за PostgreSQL на AWS Aurora

На мрежово ниво Aurora PostgreSQL използва основни компоненти на AWS, VPC за изолация на облачна мрежа и групи за сигурност за контрол на достъпа до мрежата.

Няма достъп на суперпотребител. Когато създава клъстер, Aurora PostgreSQL създава главен акаунт с подмножество от разрешения на суперпотребител:

[email protected]:5432 postgres> \du+ postgres
                               List of roles
 Role name |          Attributes               |    Member of       | Description
-----------+-------------------------------+-----------------+-------------
 postgres  | Create role, Create DB           +| {rds_superuser} |
            | Password valid until infinity  |                 |

За да защити данните по време на пренос, Aurora PostgreSQL осигурява естествена поддръжка на SSL/TLS, която може да се конфигурира за DB екземпляр.

Всички данни в покой могат да бъдат криптирани с минимално въздействие върху производителността. Това важи и за архивиране, моментни снимки и реплики.

Удостоверяването се контролира от правилата на IAM, а маркирането позволява допълнителен контрол върху това, което потребителите могат да правят и на какви ресурси.

API повикванията, използвани от всички облачни услуги, се регистрират в CloudTrail.

Ограниченото управление на пароли от страна на клиента е достъпно чрез параметъра rds.restrict_password_commands.

Архивиране и възстановяване на PostgreSQL на AWS Aurora

Архивите са активирани по подразбиране и не могат да бъдат деактивирани. Те осигуряват възстановяване в даден момент, като използват пълна ежедневна моментна снимка като основен архив.

Възстановяването от автоматично архивиране има няколко недостатъка:времето за възстановяване може да бъде няколко часа, а загубата на данни може да бъде до 5 минути преди прекъсването. Разгръщанията на Amazon RDS Multi-AZ решават този проблем, като популяризират реплика за четене до основно, без загуба на данни.

Моментните снимки на базата данни са бързи и не оказват влияние върху производителността на клъстера. Те могат да бъдат копирани или споделени с други потребители.

Правенето на моментна снимка е почти мигновено:

Възстановяването на моментна снимка също е бързо. Сравнете с PITR:

Архивните копия и моментните снимки се съхраняват в S3, който предлага единадесет 9 издръжливост.

Освен архивиране и моментни снимки, Aurora PostgreSQL позволява клонирането на бази данни. Това е ефективен метод за създаване на копия на големи набори от данни. Например, клонирането на многотерабайти данни отнема само минути и няма влияние върху производителността.

Aurora PostgreSQL – Демо за възстановяване във времето

Свързване към клъстер:

~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Попълване на таблица с данни:

[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)

Стартирайте възстановяването:

След като възстановяването приключи, влезте и проверете:

~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)

Най-добри практики

Мониторинг и одит

• Интегрирайте потоци от дейности на базата данни с мониторинг на трети страни, за да наблюдавате дейността на базата данни за съответствие и регулаторни изисквания.
• Напълно управляваната услуга за база данни не означава липса на отговорност – дефинирайте показатели за наблюдение на CPU, RAM, дисково пространство, мрежи и връзки с базата данни.
• Aurora PostgreSQL се интегрира със стандартния инструмент за наблюдение на AWS CloudWatch, както и предоставя допълнителни монитори за Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication, както и за RDS метрики, които могат да бъдат допълнително групирани по RDS Dimensions. /li>
• Наблюдавайте средните активни сесии зареждане на DB от изчакване за признаци на излишни връзки, SQL заявки, които се нуждаят от настройка, конкуренция за ресурси или малък клас на DB екземпляр.
• Настройте известия за събития.
• Конфигуриране на параметрите на регистъра за грешки.
• Наблюдавайте промените в конфигурацията на компонентите на клъстера на базата данни:екземпляри, групи подмрежи, моментни снимки, групи за защита.

Репликация

• Използвайте собствено разделяне на таблици за работни натоварвания, които надвишават максималния клас на DB екземпляр и капацитет за съхранение

Шифроване

• Шифрованата база данни трябва да има активирани резервни копия, за да се гарантира, че данните могат да бъдат възстановени в случай, че ключът за криптиране бъде отменен.

Основен акаунт

• Не използвайте psql за промяна на главната потребителска парола.

Оразмеряване

• Помислете за използването на различни класове на екземпляри в клъстер, за да намалите разходите.

Групи параметри

• Фина настройка с помощта на групи параметри, за да спестите $$$.

Демонстрация на групи параметри

Текущи настройки:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)

Създайте нова група параметри и задайте новата стойност за широк клъстер:

Свържете групата персонализирани параметри с клъстера:

Рестартирайте записващото устройство и проверете стойността:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)

• Задайте местната часова зона

По подразбиране часовата зона е в UTC:

[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)

Задаване на новата часова зона:

И след това проверете:

[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)

Обърнете внимание, че списъкът със стойности на часовите зони, приети от Amazon Aurora, не е наборите за часови зони, намерени в PostgreSQL нагоре по веригата.

• Прегледайте параметрите на екземпляра, които са отменени от параметрите на клъстера
• Използвайте инструмента за сравнение на групи параметри.

Моментни снимки

• Избягвайте допълнителни такси за съхранение, като споделите моментните снимки с други акаунти, за да позволите възстановяване в съответните им среди.

Поддръжка

• Променете прозореца за поддръжка по подразбиране според графика на организацията.

Отказ при отказ

• Подобрете времето за възстановяване, като конфигурирате управлението на кеша на клъстера.
• Намалете стойностите за поддържане на активност на TCP на ядрото на клиента и конфигурирайте DNS кеша на приложението и TTL и низовете за връзка на PostgreSQL.

DBA Внимание!

В допълнение към известните ограничения избягвайте или имайте предвид следното:

Шифроване

• След като е създадена база данни, състоянието на криптиране не може да бъде променено.

Аврора без сървър

• Понастоящем PostgreSQL версията на Aurora Serverless е налична само в ограничен преглед.

Паралелна заявка

• Amazon Parallel Query не е налична, въпреки че функцията със същото име е налична от PostgreSQL 9.6.

Крайни точки

От Amazon Connection Management:

• 5 персонализирани крайни точки на клъстер
• Имената на персонализирана крайна точка не може да надвишава 63 знака
• Имената на крайните точки на клъстера са уникални в рамките на един и същи регион
• Както се вижда на горната екранна снимка (aurora-custom-endpoint-details), READER и ВСЯКАКВИ персонализирани типове крайни точки не са налични, използвайте CLI
• Персонализираните крайни точки не знаят за временно недостъпни реплики.

Репликация

• При популяризиране на реплика до основна, връзките през крайната точка на Reader може да продължат да бъдат насочени за кратко време към популяризираната реплика.
• Многорегионалните реплики не се поддържат
• Докато пусната в края на ноември 2017 г., предварителната версия на Amazon Aurora Multi-Master все още не е налична за PostgreSQL
• Внимавайте за влошаване на производителността, когато логическата репликация е активирана в клъстера.
• Логическата репликация изисква публикуван работещ PostgreSQL двигател 10.6 или по-нова версия.

Съхранение

• Максималното разпределено място за съхранение не се свива при изтриване на данни, нито се възстановява пространството чрез възстановяване от моментни снимки. Единственият начин да възстановите място е чрез извършване на логическо изхвърляне в нов клъстер.

Архивиране и възстановяване

• Запазването на резервни копия не се удължава, докато клъстерът е спрян.
• Максималният период на съхранение е 35 дни — използвайте ръчни моментни снимки за по-дълъг период на съхранение.
• Възстановяването в момента се възстановява в нов DB клъстер.
• кратко прекъсване на четенето по време на отказване към реплики.
• Сценариите за аварийно възстановяване не са налични в различни региони.

Моментни снимки

• Възстановяването от моментна снимка създава нова крайна точка (моментните снимки могат да бъдат възстановени само в нов клъстер).
• След възстановяване на моментна снимка персонализираните крайни точки трябва да бъдат пресъздадени.
• Възстановяването от моментни снимки нулира местната часова зона на UTC.
• Възстановяването от моментни снимки не запазва персонализираните групи за защита.
• Снимките могат да се споделят с максимум 20 идентификатора на акаунти в AWS.
• Моментните снимки не могат да се споделят между региони.
• Постепенните моментни снимки винаги се копират като пълни моментни снимки, между региони и в рамките на един и същи регион.
• Копирането на моментни снимки в региони не запазва групите параметри, които не са по подразбиране.

Таксуване

• Сметката за 10 минути важи за нови екземпляри, както и след промяна на капацитета (изчисление или съхранение).

Удостоверяване

• Използването на удостоверяване на база данни IAM налага ограничение на броя на връзките в секунда.
• Основният акаунт има отменени определени права на суперпотребител.

Стартиране и спиране

От преглед на спирането и гледането на Aurora DB Cluster:

• Клъстерите не могат да се оставят спрени за неопределено време, тъй като се стартират автоматично след 7 дни.
• Отделни екземпляри на DB не могат да бъдат спрени.

Надстройки

• Не се поддържат основни надстройки на версията на място.
• Промените на групата параметри както за DB екземпляр, така и за DB клъстер отнемат поне 5 минути, за да се разпространят.

Клониране

• 15 клонинга на база данни (оригинал или копие).
• Клонингите не се премахват при изтриване на изходната база данни.

Мащабиране

• Автоматично мащабиране изисква всички реплики да са налични.
• Може да има само „една политика за автоматично мащабиране“_ за показател за клъстер.
• Хоризонталното мащабиране на първичния DB екземпляр (клас на екземпляра) не е напълно автоматично. Преди мащабирането клъстерът задейства автоматично преминаване към една от репликите. След като мащабирането завърши, новият екземпляр трябва ръчно да бъде повишен от читател в записващ:Нов екземпляр, оставен в режим на четене след промяна на класа на DB екземпляр.

Мониторинг

• Публикуването на PostgreSQL регистрационни файлове в CloudWatch изисква минимална версия на двигателя на базата данни от 9.6.6 и 10.4.
• В RDS конзолата са налични само някои показатели за Aurora, а други показатели имат различни имена и мерни единици.
• По подразбиране регистрационните файлове за подобрен мониторинг се съхраняват в CloudWatch за 30 дни.
• Показателите за наблюдение на облака и подобрено наблюдение ще се различават, тъй като събират данни от хипервизора и съответно от агента, изпълняван на екземпляра.
• Performance Insights_ обобщава показателите във всички бази данни в DB екземпляр.
• SQL изразите са ограничени до 500 знака, когато се гледат с AWS Performance Insights CLI и API.

Миграция

• Само RDS некриптирани DB моментни снимки могат да бъдат шифровани в покой.
• Миграциите с помощта на техниката Aurora Read Replica отнемат няколко часа на TiB.

Оразмеряване

• Най-малкият наличен клас екземпляр е db.t3.medium, а най-големият db.r5.24xlarge. За сравнение, MySQL двигателят предлага db.t2.small и db.t2.medium, но няма db.r5.24xlarge в горния диапазон.
• Горната граница на max_connections е 262 143.

Управление на план за заявки

• Изявленията във функциите на PL/pgSQL не се поддържат.

Миграция

Aurora PostgreSQL не предоставя услуги за директна миграция, а задачата се прехвърля към специализиран продукт на AWS, а именно AWS DMS.

Заключение

Като напълно управляван добавен заместител на възходящия PostgreSQL, Amazon Aurora PostgreSQL се възползва от технологиите, които захранват облака на AWS, за да премахне сложността, необходима за настройка на услуги като автоматично мащабиране, балансиране на натоварването на заявки, данни на ниско ниво репликация, инкрементално архивиране и криптиране.

Архитектурата и консервативният подход за надграждане на PostgreSQL двигателя осигуряват производителността и стабилността, които организациите от малки до големи търсят.

Присъщите ограничения са само доказателство, че изграждането на широкомащабна база данни като услуга е сложна задача, оставяйки на високоспециализираните PostgreSQL хостинг доставчици пазарна ниша, в която могат да се възползват.