Ако сте следвали Microsoft напоследък, няма да е изненада, че доставчикът на конкурентен продукт за бази данни, а именно SQL Server, също скочи към PostgreSQL. От издаване на 60 000 патента за OIN до платинен спонсор в PGCon, Microsoft като една от поддържащите корпоративни организации на PostgreSQL. Възползвахте се от всяка възможност, за да покажете, че не само можете да стартирате PostgreSQL на Microsoft, но и обратното е вярно:Microsoft, чрез своето облачно предложение, може да стартира PostgreSQL вместо вас. Изявлението стана още по-ясно с придобиването на Citus Data и пускането на техния флагмански продукт в Azure Cloud под името Hyperscale. Безопасно е да се каже, че приемането на PostgreSQL нараства и сега има още повече основателни причини да го изберете.
Пътешествието ми през облака Azure започна точно от целевата страница, където се срещам с претендентите:единичен сървър и предварителен преглед (с други думи без SLA) версия на Hyperscale (Citus). Този блог ще се фокусира върху първото. Докато бях на това пътуване, имах възможността да практикувам какво представлява отвореният код - връщане на общността - в този случай, като предоставям обратна връзка към документацията, че, за чест на Microsoft, те правят това много лесно, като изпращат обратната връзка директно в Github:
Съвместимост с PostgreSQL с Azure
Версиониране
Според документацията на продукта Single Server е насочен към версии на PostgreSQL в n-2 основния диапазон:
Като решение, създадено за производителност, единичен сървър се препоръчва за набори от данни 100 GB и по-големи. Сървърите осигуряваха предвидима производителност — екземплярите на базата данни идват с предварително дефиниран брой vCore и IOPS (въз основа на размера на предоставеното хранилище).
Разширения
Има доста голям брой поддържани разширения, като някои от тях се инсталират от кутията:
[email protected]:5432 postgres> select name, default_version, installed_version from pg_available_extensions where name !~ '^postgis' order by name;
name | default_version | installed_version
------------------------------+-----------------+-------------------
address_standardizer | 2.4.3 |
address_standardizer_data_us | 2.4.3 |
btree_gin | 1.2 |
btree_gist | 1.5 |
chkpass | 1.0 |
citext | 1.4 |
cube | 1.2 |
dblink | 1.2 |
dict_int | 1.0 |
earthdistance | 1.1 |
fuzzystrmatch | 1.1 |
hstore | 1.4 |
hypopg | 1.1.1 |
intarray | 1.2 |
isn | 1.1 |
ltree | 1.1 |
orafce | 3.7 |
pg_buffercache | 1.3 | 1.3
pg_partman | 2.6.3 |
pg_prewarm | 1.1 |
pg_qs | 1.1 |
pg_stat_statements | 1.6 | 1.6
pg_trgm | 1.3 |
pg_wait_sampling | 1.1 |
pgcrypto | 1.3 |
pgrouting | 2.5.2 |
pgrowlocks | 1.2 |
pgstattuple | 1.5 |
plpgsql | 1.0 | 1.0
plv8 | 2.1.0 |
postgres_fdw | 1.0 |
tablefunc | 1.0 |
timescaledb | 1.1.1 |
unaccent | 1.1 |
uuid-ossp | 1.1 |
(35 rows)Наблюдение на PostgreSQL в Azure
Наблюдението на сървъра разчита на набор от показатели, които могат да бъдат добре групирани, за да се създаде персонализирано табло:
Запознатите с Graphviz или Blockdiag вероятно ще оценят опцията за експортиране на цялото табло за управление към JSON файл:
Освен това показателите могат — и трябва — да бъдат свързани към сигнали:
Статистиката на заявката може да бъде проследена с помощта на Query Store и визуализирана с ефективност на заявката Прозрение. За това ще трябва да бъдат активирани няколко специфични за Azure параметри:
[email protected]:5432 postgres> select * from pg_settings where name ~ 'pgms_wait_sampling.query_capture_mode|pg_qs.query_capture_mode';
-[ RECORD 1 ]---+------------------------------------------------------------------------------------------------------------------
name | pg_qs.query_capture_mode
setting | top
unit |
category | Customized Options
short_desc | Selects which statements are tracked by pg_qs. Need to reload the config to make change take effect.
extra_desc |
context | superuser
vartype | enum
source | configuration file
min_val |
max_val |
enumvals | {none,top,all}
boot_val | none
reset_val | top
sourcefile |
sourceline |
pending_restart | f
-[ RECORD 2 ]---+------------------------------------------------------------------------------------------------------------------
name | pgms_wait_sampling.query_capture_mode
setting | all
unit |
category | Customized Options
short_desc | Selects types of wait events are tracked by this extension. Need to reload the config to make change take effect.
extra_desc |
context | superuser
vartype | enum
source | configuration file
min_val |
max_val |
enumvals | {none,all}
boot_val | none
reset_val | all
sourcefile |
sourceline |
pending_restart | fЗа да визуализираме бавните заявки и чакания, преминаваме към приспособлението за ефективност на заявката:
Дълго изпълняващи се заявки
Статистика за изчакване
Влизане в PostgreSQL в Azure
Стандартните регистрационни файлове на PostgreSQL могат да бъдат изтеглени или експортирани в Log Analytics за по-разширен синтактичен анализ:
Производительность и мащабиране на PostgreSQL с Azure
Докато броят на vCores може лесно да бъде увеличен или намален, това действие ще задейства рестартиране на сървъра:
За да постигнат нулев престой, приложенията трябва да могат грациозно да обработват преходни грешки .
За заявки за настройка Azure предоставя на DBA препоръки за производителност, в допълнение към предварително заредените разширения pg_statements и pg_buffercache:
Висока наличност и репликация в Azure
Високата наличност на сървъра на базата данни се постига чрез хардуерна репликация, базирана на възел. Това гарантира, че в случай на хардуерна повреда, нов възел може да бъде изведен в рамките на десетки секунди.
Azure предоставя излишен шлюз като крайна точка за мрежова връзка за всички сървъри на бази данни в даден регион.
Сигурност на PostgreSQL в Azure
По подразбиране правилата на защитната стена отказват достъп до екземпляра на PostgreSQL. Тъй като сървърът на база данни Azure е еквивалент на клъстер от база данни, правилата за достъп ще се прилагат към всички бази данни, хоствани на сървъра.
В допълнение към IP адресите правилата на защитната стена могат да препращат към виртуална мрежа, функция, достъпна само за нива с общо предназначение и оптимизирани за памет.
Едно нещо, което открих странно в уеб интерфейса на защитната стена — не можах да се ориентирам далеч от страницата, докато промените се запазват:
Данните в покой се криптират с помощта на управляван от сървър ключ и потребителите в облак не могат деактивирайте криптирането. Транзитните данни също са криптирани — изискваният SSL може да бъде променен само след създаването на сървъра на базата данни. Точно както данните в покой, резервните копия са криптирани и криптирането не може да бъде деактивирано.
Разширената защита от заплахи предоставя сигнали и препоръки за редица заявки за достъп до база данни, които се считат за риск за сигурността. Функцията в момента е в предварителен преглед. За да демонстрирам, симулирах атака с груба сила с парола:
~ $ while : ; do psql -U $(pwgen -s 20 1)@pg10 ; sleep 0.1 ; done
psql: FATAL: password authentication failed for user "AApT6z4xUzpynJwiNAYf"
psql: FATAL: password authentication failed for user "gaNeW8VSIflkdnNZSpNV"
psql: FATAL: password authentication failed for user "SWZnY7wGTxdLTLcbqnUW"
psql: FATAL: password authentication failed for user "BVH2SC12m9js9vZHcuBd"
psql: FATAL: password authentication failed for user "um9kqUxPIxeQrzWQXr2v"
psql: FATAL: password authentication failed for user "8BGXyg3KHF3Eq3yHpik1"
psql: FATAL: password authentication failed for user "5LsVrtBjcewd77Q4kaj1"
....Проверете регистрационните файлове на PostgreSQL:
2019-08-19 07:13:50 UTC-5d5a4c2e.138-FATAL: password authentication failed
for user "AApT6z4xUzpynJwiNAYf"
2019-08-19 07:13:50 UTC-5d5a4c2e.138-DETAIL: Role "AApT6z4xUzpynJwiNAYf" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:51 UTC-5d5a4c2f.13c-LOG: connection received: host=173.180.222.170 port=27248 pid=316
2019-08-19 07:13:51 UTC-5d5a4c2f.13c-FATAL: password authentication failed for user "gaNeW8VSIflkdnNZSpNV"
2019-08-19 07:13:51 UTC-5d5a4c2f.13c-DETAIL: Role "gaNeW8VSIflkdnNZSpNV" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:52 UTC-5d5a4c30.140-LOG: connection received: host=173.180.222.170 port=58256 pid=320
2019-08-19 07:13:52 UTC-5d5a4c30.140-FATAL: password authentication failed for user "SWZnY7wGTxdLTLcbqnUW"
2019-08-19 07:13:52 UTC-5d5a4c30.140-DETAIL: Role "SWZnY7wGTxdLTLcbqnUW" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:53 UTC-5d5a4c31.148-LOG: connection received: host=173.180.222.170 port=32984 pid=328
2019-08-19 07:13:53 UTC-5d5a4c31.148-FATAL: password authentication failed for user "BVH2SC12m9js9vZHcuBd"
2019-08-19 07:13:53 UTC-5d5a4c31.148-DETAIL: Role "BVH2SC12m9js9vZHcuBd" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:53 UTC-5d5a4c31.14c-LOG: connection received: host=173.180.222.170 port=43384 pid=332
2019-08-19 07:13:54 UTC-5d5a4c31.14c-FATAL: password authentication failed for user "um9kqUxPIxeQrzWQXr2v"
2019-08-19 07:13:54 UTC-5d5a4c31.14c-DETAIL: Role "um9kqUxPIxeQrzWQXr2v" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:54 UTC-5d5a4c32.150-LOG: connection received: host=173.180.222.170 port=27672 pid=336
2019-08-19 07:13:54 UTC-5d5a4c32.150-FATAL: password authentication failed for user "8BGXyg3KHF3Eq3yHpik1"
2019-08-19 07:13:54 UTC-5d5a4c32.150-DETAIL: Role "8BGXyg3KHF3Eq3yHpik1" does not exist.
Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"
2019-08-19 07:13:55 UTC-5d5a4c33.154-LOG: connection received: host=173.180.222.170 port=12712 pid=340
2019-08-19 07:13:55 UTC-5d5a4c33.154-FATAL: password authentication failed for user "5LsVrtBjcewd77Q4kaj1"
2019-08-19 07:13:55 UTC-5d5a4c33.154-DETAIL: Role "5LsVrtBjcewd77Q4kaj1" does not exist.Сигналът по имейл пристигна около 30 минути по-късно:
За да позволи фин достъп до сървъра на базата данни, Azure предоставя RBAC, което е функция за контрол на достъпа в облак, само още един инструмент в арсенала на PostgreSQL Cloud DBA. Това е възможно най-близо до вездесъщите pg_hba правила за достъп.
Архивиране и възстановяване на PostgreSQL в Azure
Независимо от ценовите нива, резервните копия се запазват между 7 и 35 дни. Ценовото ниво също влияе върху възможността за възстановяване на данни.
Възстановяването в момента е достъпно чрез Azure Portal или CLI и според документацията е детайлно до пет минути. Функционалността на портала е доста ограничена — джаджата за избор на дата показва сляпо последните 7 дни като възможни дати за избор, въпреки че създадох сървъра днес. Освен това не се извършва проверка за целево време за възстановяване — очаквах, че въвеждането на стойност извън интервала за възстановяване ще предизвика грешка, предотвратяваща продължаването на съветника:
След като процесът на възстановяване започне, грешка, уж причинена от изхода от стойността на диапазона, ще се появи около минута по-късно:
...но, за съжаление, съобщението за грешка не беше много полезно:
Накрая, архивното съхранение е безплатно за периоди на съхранение до 7 дни. Това може да се окаже изключително удобно за среди за разработка.
Съвети и съвети
Ограничения
Свикнете с ограниченията за единичен сървър.
Свързване
Винаги използвайте низа за връзка, за да може връзката да бъде насочена към правилния сървър на база данни.
Репликация
За сценарии за възстановяване след бедствие, намерете реплики за четене в един от сдвоените региони.
Роли
Както е в случая с AWS и GCloud, няма достъп на суперпотребител.
GUCs
Параметрите, изискващи рестартиране на сървъра или достъп на суперпотребител, не могат да бъдат конфигурирани.
Мащабиране
По време на автоматично мащабиране приложенията трябва да опитат отново, докато се изведе новият възел.
Обемът на паметта и IOPS не могат да бъдат посочени — паметта се разпределя в единици GB на vCore, до максимум 320GB (32vCores x 10GB), а IOPS зависят от размера на предоставеното хранилище за максимум 6000 IOPS. Понастоящем Azure предлага голяма опция за предварителен преглед на съхранение с максимум 20 000 IOPS.
Сървърите, създадени в основното ниво, не могат да бъдат надстроени до общо предназначение или оптимизирани за памет.
Съхранение
Уверете се, че функцията за автоматично нарастване е активирана — ако количеството данни надвиши предвиденото пространство за съхранение, базата данни ще влезе в режим само за четене.
Съхранението може да бъде само увеличено. Точно както при всички други доставчици на облак, разпределението на съхранение не може да бъде намалено и не можах да намеря никакво обяснение. Като се има предвид най-съвременното оборудване, големите облачни играчи могат да си позволят, не би трябвало да има причина да не предоставят функции, подобни на преместването на LVM онлайн данни. Съхранението е наистина евтино в днешно време, наистина няма причина да мислите за намаляване на мащаба до следващото основно надграждане на версията.
Защитна стена
В някои случаи разпространението на актуализациите на правилата на защитната стена може да отнеме до пет минути.
Сървърът се намира в същата подмрежа като сървърите на приложения няма да бъде достъпен, докато не бъдат въведени съответните правила за защитната стена.
Правилата на виртуалната мрежа не позволяват достъп между региони и в резултат на това dblink и postgres_fdw не могат да се използват за свързване с бази данни извън облака Azure.
Подходът на VNet/Subnet не може да се приложи към уеб приложения, тъй като техните връзки произхождат от публични IP адреси.
Големите виртуални мрежи ще бъдат недостъпни, докато крайните точки на услугата са активирани.
Шифроване
За приложения, които изискват валидиране на сървърен сертификат, файлът е достъпен за изтегляне от Digicert. Microsoft го направи лесно и не трябва да се притеснявате за подновяване до 2025 г.:
~ $ openssl x509 -in BaltimoreCyberTrustRoot.crt.pem -noout -dates
notBefore=May 12 18:46:00 2000 GMT
notAfter=May 12 23:59:00 2025 GMTСистема за откриване на проникване
Версията за предварителен преглед на Advanced Threat Protection не е налична за екземпляри от основно ниво.
Архивиране и възстановяване
За приложения, които не могат да си позволят престой в региона, помислете за конфигуриране на сървъра с гео-излишно архивно хранилище. Тази опция може да бъде активирана само в момента на създаване на сървъра на базата данни.
Изискването за преконфигуриране на правилата на облачната защитна стена след операция PITR е особено важно.
Изтриването на сървър на база данни премахва всички резервни копия.
След възстановяването има определени задачи след възстановяване, които ще трябва да бъдат изпълнени.
Нерегистрираните таблици се препоръчват за групови вмъквания, за да се повиши производителността, но те не се репликират.
Наблюдение
Показателите се записват всяка минута и се съхраняват в продължение на 30 дни.
Регистриране
Съхранението на заявки е глобална опция, което означава, че се прилага за всички бази данни. Транзакциите само за четене и заявките, по-дълги от 6000 байта, са проблематични. По подразбиране заснетите заявки се запазват за 7 дни.
Ефективност
Препоръките на Query Performance Insight понастоящем са ограничени до създаване и пускане на индекс.
Деактивирайте pg_stat_staements, когато не е необходимо.
Заменете uuid_generate_v4 с gen_random_uuid(). Това е в съответствие с препоръката в официалната документация на PostgreSQL, вижте Изграждане uuid-ossp.
Висока наличност и репликация
Има ограничение от пет прочетени реплики. Приложенията с интензивно писане трябва да избягват използването на реплики за четене, тъй като механизмът на репликация е асинхронен, което въвежда някои забавяния, които приложенията трябва да могат да понасят. Прочетените реплики могат да се намират в различен регион.
Поддръжката на REPLICA може да бъде активирана само след като сървърът е създаден. Функцията изисква рестартиране на сървъра:
Репликата за четене не наследяват правилата на защитната стена от главния възел:
Отказът за четене на реплика не е автоматично. Механизмът за преминаване при отказ е базиран на възли.
Има дълъг списък от съображения, които трябва да бъдат прегледани, преди да конфигурирате реплики за четене.
Създаването на реплики отнема много време, дори когато тествах с относително малък набор от данни:
Вакуум Вакуум
Прегледайте ключовите параметри, тъй като Azure Database за PostgreSQL се доставя със стойности по подразбиране за вакуум нагоре по веригата:
[email protected]:5432 postgres> select name,setting from pg_settings where name ~ '^autovacuum.*';
name | setting
-------------------------------------+-----------
autovacuum | on
autovacuum_analyze_scale_factor | 0.05
autovacuum_analyze_threshold | 50
autovacuum_freeze_max_age | 200000000
autovacuum_max_workers | 3
autovacuum_multixact_freeze_max_age | 400000000
autovacuum_naptime | 15
autovacuum_vacuum_cost_delay | 20
autovacuum_vacuum_cost_limit | -1
autovacuum_vacuum_scale_factor | 0.05
autovacuum_vacuum_threshold | 50
autovacuum_work_mem | -1
(12 rows)Надстройки
Автоматични големи надстройки не се поддържат. Както споменахме по-рано, това е възможност за спестяване на разходи чрез намаляване на автоматично отглежданото хранилище.
Подобрения на PostgreSQL Azure
Таймсерии
TimescaleDB се предлага като разширение (не е част от модулите на PostgreSQL), но е само на няколко щраквания. Единственият недостатък е по-старата версия 1.1.1, докато версията нагоре по веригата в момента е 1.4.1 (2019-08-01).
[email protected]:5432 postgres> CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
WARNING:
WELCOME TO
_____ _ _ ____________
|_ _(_) | | | _ \ ___ \
| | _ _ __ ___ ___ ___ ___ __ _| | ___| | | | |_/ /
| | | | _ ` _ \ / _ \/ __|/ __/ _` | |/ _ \ | | | ___ \
| | | | | | | | | __/\__ \ (_| (_| | | __/ |/ /| |_/ /
|_| |_|_| |_| |_|\___||___/\___\__,_|_|\___|___/ \____/
Running version 1.1.1
For more information on TimescaleDB, please visit the following links:
1. Getting started: https://docs.timescale.com/getting-started
2. API reference documentation: https://docs.timescale.com/api
3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture
CREATE EXTENSION
[email protected]:5432 postgres> \dx timescaledb
List of installed extensions
Name | Version | Schema | Description
-------------+---------+--------+-------------------------------------------------------------------
timescaledb | 1.1.1 | public | Enables scalable inserts and complex queries for time-series data
(1 row)Регистриране
В допълнение към опциите за регистриране на PostgreSQL, Azure Database за PostgreSQL може да бъде конфигурирана да записва допълнителни събития за диагностика.
Защитна стена
Azure Portal включва удобна функция за разрешаване на връзки от IP адресите, влезли в портала:
Отбелязах функцията, тъй като улеснява разработчиците и системните администратори да позволяват на себе си и се откроява като функция, която не се предлага нито от AWS, нито от GCloud.
Заключение
Azure Database за PostgreSQL Single Server предлага услуги на корпоративно ниво, но много от тези услуги все още са в режим на визуализация:Съхранение на заявки, Performance Insight, Performance Recommendation, Advanced Threat Protection, Large Storage, Cross-region Прочетете репликите.
Докато познанията за операционната система вече не са необходими за администриране на PostgreSQL в облака Azure, се очаква от DBA да придобие умения, които не са ограничени до самата база данни — работа в мрежа Azure (VNet), сигурност на връзката (защитна стена) ), преглед на регистрационни файлове и анализи, заедно с KQL, Azure CLI за удобни скриптове и списъкът продължава.
Накрая, за тези, които планират да мигрират своите PostgreSQL работни натоварвания към Azure, има редица налични ресурси, заедно с избран списък с партньори на Azure, включително Credativ, един от основните спонсори и сътрудници на PostgreSQL.
