Услугите на AWS PostgreSQL попадат в рамките на RDS чадъра, който е DaaS предложението на Amazon за всички известни машини за бази данни.
Услугите за управлявани бази данни предлагат определени предимства, които са привлекателни за клиента, търсещ независимост от поддръжката на инфраструктурата, и високодостъпни конфигурации. Както винаги, няма универсално решение за всички. Наличните в момента опции са подчертани по-долу:
Aurora PostgreSQL
Страницата с често задавани въпроси на Amazon Aurora предоставя важни подробности, които трябва да бъдат взети предвид, преди да се потопите в продукта. Например, научаваме, че слоят за съхранение е виртуализиран и се намира на собствена виртуализирана система за съхранение, архивирана от SSD.
Ценообразуване
По отношение на ценообразуването трябва да се отбележи, че Aurora PostgreSQL не е налична в AWS Free Tier.
Съвместимост
На същата страница с често задавани въпроси става ясно, че Amazon не претендира за 100% съвместимост с PostgreSQL. Повечето (подчертавам) на приложенията ще са добре, напр. вкусът на AWS PostgreSQL е съвместим с проводници с PostgreSQL 9.6. В резултат на това Wireshark PostgreSQL Dissector ще работи добре.
Ефективност
Производителността също е свързана с типа на екземпляра, например максималният брой връзки по подразбиране се конфигурира въз основа на размера на екземпляра.
Също така важен, когато става въпрос за съвместимост, е размерът на страницата, който е запазен на 8KiB, което е размерът на страницата по подразбиране на PostgreSQL. Говорейки за страници, струва си да цитирате често задаваните въпроси:„За разлика от традиционните машини за бази данни Amazon Aurora никога не избутва модифицирани страници от база данни към слоя за съхранение, което води до допълнително спестяване на IO консумация. ” Това стана възможно, защото Amazon промени начина, по който се управлява кеша на страниците, позволявайки му да остане в паметта в случай на повреда на базата данни. Тази функция също е от полза за рестартирането на базата данни след срив, позволявайки възстановяването да се случи много по-бързо, отколкото при традиционния метод за повторно възпроизвеждане на регистрационните файлове.
Според споменатите по-горе ЧЗВ, Aurora PostgreSQL осигурява три пъти по-висока производителност от PostgreSQL при операции SELECT и UPDATE. Съгласно Бялата книга за сравнение на PostgreSQL на Amazon инструментите, използвани за измерване на производителността, са pgbench и sysbench. Забележителна е зависимостта на производителността от типа на екземпляра, избора на регион и производителността на мрежата. Чудите се защо INSERT не се споменава? Това е така, защото съответствието с PostgreSQL ACID („C“) изисква да бъде създаден актуализиран запис с помощта на изтриване, последвано от вмъкване.
За да се възползва напълно от подобренията в производителността, Amazon препоръчва приложенията да са проектирани да взаимодействат с базата данни, използвайки голям брой едновременни заявки и транзакции . Този важен фактор често се пренебрегва, което води до лошо представяне, обвинено в изпълнението.
Ограничения
Има някои ограничения, които трябва да се имат предвид при планирането на миграцията:
-
huge_pages не може да се променя, но е включено по подразбиране:
template1=> select aurora_version(); aurora_version ---------------- 1.0.11 (1 row) template1=> show huge_pages ; huge_pages ------------ on (1 row) - pg_hba не може да се използва, тъй като изисква рестартиране на сървъра. Като странична забележка, това трябва да е печатна грешка в документацията на Amazon, тъй като PostgreSQL трябва само да се презареди. Вместо да разчитат на pg_hba, администраторите ще трябва да използват AWS Security Groups и PostgreSQL GRANT.
- Зърнелността на PITR е 5 минути.
- Многорегионалната репликация в момента не е налична за PostgreSQL.
- Максималният размер на таблиците е 64TiB
- До 15 прочетени реплики
Мащабируемост
Мащабирането нагоре и надолу на екземпляра на базата данни понастоящем е ръчен процес, който може да се извърши чрез AWS Console или CLI, въпреки че автоматичното мащабиране работи, но според често задаваните въпроси на Amazon Aurora то ще бъде достъпно само за MySQL.
Изчислителни ресурси за мащабиране на регистър на събития За да мащабират хоризонтално, приложенията трябва да се възползват от приложните програмни интерфейси на AWS SDK, например, за да постигнат бързо преминаване при отказ.
Висока наличност
Преминавайки към висока наличност, в случай на отказ на първичен възел, Aurora PostgreSQL предоставя крайна точка на клъстер като DNS A запис, който автоматично се актуализира вътрешно, за да сочи към репликата, избрана да стане главен.
Резервни копия
Струва си да се спомене, че ако базата данни бъде изтрита, всички ръчни резервни снимки ще бъдат запазени, докато автоматичните моментни снимки се премахват.
Репликация
Тъй като репликите споделят същото основно хранилище като първичния екземпляр, забавянето на репликацията на теория е в диапазона от милисекунди.
Amazon препоръчва четене на реплики, за да се намали продължителността на отказ. С реплика за четене в режим на готовност процесът на отказ отнема около 30 секунди, докато без реплика очаквайте до 15 минути.
Друга добра новина е, че се поддържа и логическа репликация, както е показано на страница 22.
Въпреки че често задаваните въпроси на Amazon Aurora не предоставят подробности за репликацията, както за MySQL, най-добрите практики на Aurora PostgreSQL предоставя полезна заявка за проверка на състоянието на репликация:
select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();Горната заявка дава:
-[ RECORD 1 ]--------------+-------------------------------------
server_id | testdb
session_id | 9e268c62-9392-11e8-87fc-a926fa8340fe
highest_lsn_rcvd | 46640889
cur_replay_latency_in_usec | 8830
now | 2018-07-29 20:14:55.434701-07
last_update_timestamp | 2018-07-29 20:14:54-07
-[ RECORD 2 ]--------------+-------------------------------------
server_id | testdb-us-east-1b
session_id | MASTER_SESSION_ID
highest_lsn_rcvd |
cur_replay_latency_in_usec |
now | 2018-07-29 20:14:55.434701-07
last_update_timestamp | 2018-07-29 20:14:55-07Тъй като репликацията е толкова важна тема, си струваше да настроите теста pgbench, както е описано в бялата книга за сравнителния анализ, посочена по-горе:
[[email protected] ~]$ whoami
ec2-user
[[email protected] ~]$ tail -n 2 .bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
export PATH=$PATH:/usr/local/pgsql/bin/
[[email protected] ~]$ which pgbench
/usr/local/pgsql/bin/pgbench
[[email protected] ~]$ pgbench --version
pgbench (PostgreSQL) 9.6.8Съвет: Избягвайте ненужното въвеждане, като създадете pgpass файл и експортирате променливите на хоста, базата данни и потребителската среда, напр.:
[[email protected] ~]# tail -n 3 ~/.bashrc export
PGUSER=dbadmin
export PGHOST=c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGDATABASE=template1
[[email protected] ~]# cat ~/.pgpass
*:*:*:dbadmin:passwordИзпълнете командата за инициализация на данни:
[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgresДокато инициализацията на данните се изпълнява, заснемете забавянето на репликацията, като използвате горния SQL, извикан от следния скрипт:
while : ; do
psql -t -q \
-c 'select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp
from aurora_replica_status();' postgres
sleep 1
doneФилтриране на изхода на екранния журнал чрез следната команда:
[[email protected] ~]# awk -F '|' '{print $4,$5,$6}' screenlog.2 | sort -k1,1 -n | tail
513116 2018-07-30 04:30:44.394729+00 2018-07-30 04:30:43+00
529294 2018-07-30 04:20:54.261741+00 2018-07-30 04:20:53+00
544139 2018-07-30 04:41:57.538566+00 2018-07-30 04:41:57+00
1001902 2018-07-30 04:42:54.80136+00 2018-07-30 04:42:53+00
2376951 2018-07-30 04:38:06.621681+00 2018-07-30 04:38:06+00
2376951 2018-07-30 04:38:07.672919+00 2018-07-30 04:38:07+00
5365719 2018-07-30 04:36:51.608983+00 2018-07-30 04:36:50+00
5365719 2018-07-30 04:36:52.912731+00 2018-07-30 04:36:51+00
6308586 2018-07-30 04:45:22.951966+00 2018-07-30 04:45:21+00
8210986 2018-07-30 04:46:14.575385+00 2018-07-30 04:46:13+00Оказва се, че репликацията изостава с цели 8 секунди!
Във връзка с това метриката на AWS CloudWatch AuroraReplicaLagMaximum не е съгласна с резултатите от горната SQL команда. Бих искал да знам защо, така че отзивите са високо оценени.
Графика на изоставане с максимална реплика на RDS CloudWatch Сигурност
-
Криптирането е налично и трябва да бъде активирано при създаването на базата данни, тъй като не може да се променя след това.
Отстраняване на неизправности
Този кратък раздел е важен бит. Уверете се, че PostgreSQL work_mem е настроен по подходящ начин, така че операциите по сортиране да не записват данни на диск.
Настройка
Просто следвайте съветника за настройка в конзолата на AWS:
-
Отворете Amazon RDS конзола за управление.
Конзола за управление на RDS -
Изберете Amazon Aurora и PostgreSQL издание.
Съветник Aurora PostgreSQL -
Посочете подробностите за DB и отбележете ограниченията за парола Aurora PostgreSQL:
Master Password must be at least eight characters long, as in "mypassword". Can be any printable ASCII character except "/", """, or "@".
Подробности за базата данни на съветника Aurora PostgreSQL -
Конфигурирайте опциите на базата данни:
- Към това писане е наличен само PostgreSQL 9.6. Използвайте PostgreSQL на Amazon RDS, ако имате нужда от поддръжка за по-нови версии, включително бета визуализации.
-
Конфигурирайте приоритета при отказ и изберете броя на репликите.
Описание на снимката -
Задайте запазване на резервното копие (максимумът е 35 дни).
Запазване на резервно копие на съветника Aurora PostgreSQL -
Изберете графика за поддръжка. Налични са автоматични незначителни надстройки на версии, но е важно да се провери с поддръжката на AWS дали техният график за корекции може да бъде ускорен, в случай че проектът PostgreSQL пусне спешни актуализации. Например, на AWS бяха необходими повече от два месеца, за да прокара актуализациите от 2018-05-10.
График за поддръжка на съветника Aurora PostgreSQL -
Ако базата данни е създадена успешно, ще се покаже връзка към инструкции как да се свържете с нея:
Настройката на съветника Aurora PostgreSQL завършена
Свързване с база данни
Прегледайте подробни инструкции за наличните опции за свързване въз основа на настройката на инфраструктурата. В най-простия сценарий връзката се осъществява чрез публичен EC2 екземпляр.
Забележка:Клиентът трябва да е съвместим с PostgreSQL 9.6.3 или по-нова версия.
[[email protected] ~]# psql -U dbadmin -h c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com template1
Password for user dbadmin:
psql (9.6.8, server 9.6.3)
SSL connection (protocol: TLSv1.2, cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.Мониторинг
Amazon предоставя различни показатели за наблюдение на базата данни, като пример по-долу показва метрики на екземпляра:
Показатели на екземпляра на RDS Изтеглете Бялата книга днес PostgreSQL Management &Automation с ClusterControl Научете за това, от което се нуждаете, за да наблюдавате управлявайте и мащабирайте PostgreSQLD Изтеглете Бялата книга RDS за PostgreSQL
Това е предложение, което позволява повече детайлност по отношение на избора на конфигурация. Например, за разлика от Aurora, която използва собствена система за съхранение, RDS предлага конфигурируемо съхранение с помощта на EBS томове, които могат да бъдат или SSD с общо предназначение (GP2), или осигурени IOPS, или магнитни (не се препоръчва).
За да подпомогне големи инсталации, изискващи персонализиране, което не е налично в предлагането на Aurora, Amazon наскоро пусна препоръките за най-добри практики, налични само за RDS.
Високата наличност трябва да бъде конфигурирана ръчно (или автоматизирана с помощта на някой от познатите инструменти на AWS) и се препоръчва да настроите внедряване с няколко AZ.
Репликацията се осъществява с помощта на собствената репликация на PostgreSQL.
Има някои ограничения за PostgreSQL DB екземпляри, които трябва да бъдат взети предвид.
Имайки предвид горните бележки, ето ръководство за настройка на RDS PostgreSQL Multi-AZ среда:
-
От Конзолата за управление на RDS стартирайте съветника
Помощник за RDS PostgreSQL -
Изберете между производствена и развойна настройка.
Избор на случай на използване на базата данни на съветника RDS PostgreSQL -
Въведете подробностите за вашия нов клъстер от база данни.
Подробности за базата данни на съветника за RDS PostgreSQL 
Настройки на базата данни на съветника за RDS PostgreSQL -
На следващата страница настройте графика за работа в мрежа, сигурност и поддръжка:
Разширени настройки на съветника за RDS PostgreSQL 
Сигурност и поддръжка на съветника за RDS PostgreSQL
Заключение
Amazon RDS услугите за PostgreSQL включват RDS PostgreSQL и Aurora PostgreSQL, като и двете са управлявани DaaS предложения. Снабдени с много функции и солидно бекенд съхранение, те имат някои ограничения спрямо традиционната настройка, но с внимателно планиране тези предложения могат да осигурят добре балансирано съотношение цена-функционалност. Amazon RDS за PostgreSQL е насочен към потребители, които се нуждаят от повече опции за конфигуриране на техните среди и като цяло е по-скъп. Повечето потребители ще се възползват от стартиране с Aurora PostgreSQL и ще си проправят път в по-сложни конфигурации.
