Как да наблюдавате производителността на PostgreSQL 12 с OmniDB

OmniDB е графичен инструмент за управление на база данни с отворен код, разработен от 2ndQuadrant, световен лидер в технологиите и услугите на PostgreSQL. OmniDB е базиран на браузър, универсален клиентски инструмент, който може да управлява основни машини за бази данни като PostgreSQL, MariaDB, MySQL и Oracle. Други двигатели, които скоро ще бъдат поддържани, включват SQLite, Firebird, MS SQL Server и IBM DB2.

Както всеки отличен клиентски софтуер за база данни, OmniDB също дава възможност на потребителите с някои страхотни функции. Те включват възможността за създаване и персонализиране на табла за наблюдение на производителността на базата данни. В тази поредица от статии от две части ще научим как да използваме вградените модули за наблюдение на OmniDB – известни като „джаджи“ в термините на таблото за управление – за изграждане на табла за проверка на ефективността за клъстер за репликация на PostgreSQL 12.

Тестовата среда

Нашата тестова среда е PostgreSQL 12 клъстер с два възела, работещ в AWS VPC в региона us-east-1. VPC обхваща три зони за наличност и има три подмрежи. Всяка подмрежа е в отделна зона за наличност (AZ). Основният и резервният възел се намират в две от тези подмрежи. И двата възела са t2.large EC2 тип екземпляр и ще работят с отворен код PostgreSQL 12. Основният възел ще се репликира на възела в режим на готовност.

Ще има и „възел за наблюдение“, работещ с най-новата версия на инструмента за управление на база данни OmniDB на 2ndQuadrant. Този възел няма да бъде част от клъстера PostgreSQL, но ще бъде хостван в третата подмрежа на VPC, в друга AZ. OmniDB ще може да се свърже както с главния, така и с резервния възел и ще провери тяхната производителност. Възелът OmniDB ще бъде t2.medium EC2 екземпляр.

И трите възли ще работят с Red Hat Enterprise Linux (RHEL) 8. Изображението по-долу показва опростената архитектура:

Тестовият сценарий

След като настроим клъстера и OmniDB, ще регистрираме и двата PostgreSQL възела в OmniDB. След това ще се запознаем с някои от стандартните модули за наблюдение в OmniDB и ще прегледаме показателите за производителност от двата възела на клъстера. След това ще изпълним тест за натоварване в първичния възел с помощта на pgbench. В идеалния случай тестът за натоварване трябва да бъде иницииран от отделна машина, но в този случай ще го стартираме локално. След това ще видим как таблото за наблюдение на OmniDB показва промените в различните броячи на производителността при промяна на натоварването.

Настройка на средата

Стъпка 1:Инсталиране на PostgreSQL 12 репликационен клъстер

За да създадем PostgreSQL клъстер с два възела, ние следваме стъпките, описани в по-рано публикуван блог 2ndQuadrant. Читателят може да провери тази статия за да види как инсталирахме клъстер с три възли с възел-свидетел, използвайки друг продукт от 2ndQuadrant, наречен repmgr . За нашата текуща настройка следваме същите стъпки, използвайки repmgr, за да създадем клъстер с два възела вместо клъстер с три възела. Също така, клъстерът за репликация няма да има нито един свидетелски възел. За да бъде нещата опростени, тази статия не показва подробните стъпки за инсталиране и конфигуриране.

След като нашият клъстер е настроен, можем да потвърдим, че функционира, като запитаме pg_stat_replication изглед от основния възел:

SELECT    usename, client_addr, application_name, state, sent_lsn, write_lsn, replay_lsnFROM     pg_stat_replication;

Стъпка 2:Инсталиране и конфигуриране на OmniDB сървър

Достъпът до OmniDB се осъществява с помощта на URL, което означава, че зад сцената той управлява собствен уеб сървър. Има два варианта на OmniDB:

Приложение OmniDB :Обикновено се изпълнява от работна станция и се държи като нормално настолно приложение. OmniDB стартира уеб сървъра на произволен порт и не е необходима допълнителна настройка.
OmniDB сървър :Това е за инсталиране на OmniDB на мрежов сървър за многопотребителски режим. В сървърния режим можем да посочим номера на порта за достъп до URL адреса, SSL криптиране на URL адреса, балансиране на натоварването и обратен прокси, SSH преходен достъп до възлите на базата данни и създаване на потребителски акаунти за достъп.

За нашия тестов сценарий ще инсталираме OmniDB сървър в OmniDB EC2 възела. Първо, изтегляме най-новия пакет от сайта OmniDB:

# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm

След това започваме инсталацията. Тук ние инсталираме OmniDB като root потребител, но можете да използвате всеки друг потребител, стига той да има правилните права:

# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmПроверка...                          ############################# #### [100%]Подготовка...                          ################################# [100%]Актуализиране / installing...   1:omnidb-server-2.17.0-0           ################################ [ 100%]

След като пакетът е инсталиран, можем да стартираме OmniDB от командния ред:

# omnidb-сървър

Това показва как сървърът стартира:

Стартиране на OmniDB websocket...Проверка на наличността на порт...Стартиране на websocket сървър на порт 25482 .Стартиране на сървъра OmniDB...Проверка на наличността на портове...Стартиране на сървъра OmniDB 2.17.0 на 127.0.0.1:8000 .Стартиране на миграция на потребителска база данни от версия 0.0.0 към версия 2.17.0...OmniDB успешно мигрира потребителска база данни от версия 0.0.0 към версия 2.17.0Отворете OmniDB в любимия си браузър Натиснете Ctrl+C за изход

Можем да видим, че OmniDB е избрал порт за уеб сървър по подразбиране 8000 и сървър за уеб сокет по подразбиране на порт 25482.

Натискаме Ctrl+C, за да спрем процеса на сървъра и да отидем до домашната директория на root потребителя. Виждаме, че има скрита папка с име .omnidb . Под тази папка има поддиректория, наречена omnidb-server . В поддиректорията omnidb-server има няколко файла:

# ls -la ~ …drwxr-xr-x. 3 корен корен       27 юни 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root  106 юни 13 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 корен корен 131072 13 юни 02:49 db.sqlite3-rw-r--r--. 1 корен корен   1209 13 юни 02:49 omnidb.conf -rw-r--r--. 1 корен корен 116736 13 юни 02:49 omnidb.db -rw-r--r--. 1 корен корен      0 13 юни 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 корен корен    579 13 юни 02:49 omnidb.log

След като процесът на сървъра стартира, OmniDB инициализира тези файлове. Базата данни с метаданни OmniDB се нарича omnidb.db . Това е база данни на SQLite и съдържа информация за връзки към база данни, потребители на OmniDB и т.н. omnidb.conf файл съдържа опции за конфигурация за OmniDB сървъра. Ако отворим този файл в редактор, той изглежда така:

# конфигурационен файл на OmniDB сървър[webserver]# Какъв адрес слуша уеб сървъра, 0.0.0.0 слуша всички адреси, свързани с машинатаадрес_слушания    =127.0.0.1 # Порт на уеб сървъра, ако портът се използва друг произволен порт ще бъде избранlistening_port       =8000 # Порт на Websocket, ако портът се използва, друг произволен порт ще бъде избранwebsocket_port       =25482 # Външен порт на Websocket, използвайте този параметър, ако OmniDB не се вижда директно от клиента# external_websocket_port =25482# Параметри за сигурност# is_ssl =Вярно изисква параметри ssl_certificate_file и ssl_key_file# Това е силно препоръчително =за защита на информацията  ssl_certificate_file =/път/до/cert_file ssl_key_file         =/path/to/key_file # Доверен произход, използвайте този параметър, ако OmniDB е конфигуриран със SSL и е достъпен от друг домейнcsrf_trusted_origins =origin1,origin2,origin3# Url път за достъп до OmniDB, по подразбиране е празенпът = [queryserver]# максимален брой нишки, които могат да се използват от всяка заявка за разширено търсене на обектthread_pool_max_workers =2 # Брой секунди между всяка заявка за подкана за парола. По подразбиране:30 минутиpwd_timeout_total =1800

OmniDB изпълнява два сървърни процеса. Единият е уеб сървър, който показва потребителския интерфейс, другият е сървърът на websocket. Websocket сървърът се използва от няколко функции на приложението, като заявка, конзола и отстраняване на грешки.

От конфигурационния файл можем да видим, че по подразбиране OmniDB сървърът приема локален трафик (127.0.0.1) на порт 8000 на уеб сървъра. Ще променим това на ВСИЧКИ IP адреси. Освен ако машината не стои зад обратен прокси, силно се препоръчва да използвате SSL криптиране за HTTP връзки към сървъра. В нашия пример обаче ще оставим is_ssl параметър на „False“, защото ще развалим тази машина, след като тестовете ни приключат. Също така ще променим порта на уеб сървъра на 8080 и ще запазим порта на сървъра на websocket на стойността му по подразбиране от 25482.

След като промените бъдат направени, конфигурационният файл трябва да изглежда така:

[webserver] Слушане_адрес>

С направените и запазени промени стартираме друго приложение, наречено omnidb-config-server . Този инструмент може да се използва за извършване на допълнителна конфигурация, като например:

Почистване на базата данни на SQLite OmniDB
Нулирайте старата база данни и създайте нова
Изтриване на временни файлове
Създайте нова домашна директория за базата данни и конфигурационния файл
Създайте суперпотребител за влизане в OmniDB

Въпреки че ще влезем в OmniDB с помощта на администраторския потребителски акаунт, който е създаден по подразбиране, тук ще създадем друг суперпотребител. Това може да бъде полезно, ако искаме да създадем индивидуални DBA акаунти в OmniDB. Фрагментът по-долу показва това:

# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Създаване на суперпотребител... Създаден суперпотребител.

Със създадения суперпотребител започваме отново процеса на omnidb-сървър:

# omnidb-server Стартиране на OmniDB websocket...Проверка на наличността на портове...Стартиране на сървър на websocket на порт 25482.Стартиране на OmniDB сървър...Проверка на наличността на портове...Стартиране на сървъра OmniDB 2.17.0 на 0.0.0.0:8080. Потребителската база данни версия 2.17.0 вече съответства на версията на сървъра. Отворете OmniDB в любимия си браузър Натиснете Ctrl+C, за да излезете

Преди да осъществим достъп до интерфейса OmniDB, ние също добавяме порт 8080 и порт 25482 към групата за сигурност на EC2 инстанция:

Стъпка 3:Достъп до интерфейса OmniDB

Преглеждането на публичния адрес и възела OmniDB вече показва екрана за влизане:

Посочваме потребителското име по подразбиране „admin“ и неговата парола „admin“. Това ни позволява да влезем в основния интерфейс на OmniDB. Първият екран е показан по-долу:

След това щракваме върху иконата „Управление на потребителите“ в горния десен ъгъл на екрана:

И променете паролата по подразбиране на администраторския потребител:

След като приключим, щракваме върху бутона „Запазване на данни“, за да актуализираме паролата. Както можете да видите, ние също можем да създаваме нови потребители от този екран.

От горния ляв ъгъл на екрана щракваме върху връзката „Връзки“ и след това от получения диалогов прозорец щракваме върху бутона „Нова връзка“:

След това указваме подробностите за връзката за основния възел на PostgreSQL и щракваме върху бутона „Запазване на данни“:

След като връзката бъде запазена, щракваме върху иконата на връзката (зелена отметка) от колоната „Действия“.

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

Следваме същия процес, за да регистрираме възела в режим на готовност:

Стъпка 4:Възстановяване на примерна база данни

Сега възстановяваме примерна база данни в основния екземпляр на PostgreSQL. Тази база данни се нарича „DVDRental“ и може да се изтегли свободно от сайта за обучение на PostgreSQL. Разархивирахме изтегления файл и извлечехме изходните файлове в поддиректория под папката /tmp на основния възел:

[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 корен     корен         280 16 юни 11:32 .drwxrwxrwt. 9 корен     корен         257 16 юни 11:31 ..-rw-------. 1 postgres postgres   57147 12 май 2019 г. 3055.dat-rw-------. 1 postgres postgres    8004 12 май 2019 г. 3057.dat-rw-------. 1 postgres postgres     483 12 май 2019 г. 3059.dat-rw-------. 1 postgres postgres  333094 12 май 2019 г. 3061.dat-rw-------. 1 postgres postgres  149469 12 май 2019 г. 3062.dat-rw-------. 1 postgres postgres   26321 12 май 2019 г. 3063.dat-rw-------. 1 postgres postgres   46786 12  май 2019 г. 3065.dat-rw-------. 1 postgres postgres   21762 12 май 2019 г. 3067.dat-rw-------. 1 postgres postgres    3596 12 май 2019 г. 3069.dat-rw-------. 1 postgres postgres  140422 12 май 2019 г. 3071.dat-rw-------. 1 postgres postgres     263 12 май 2019 г. 3073.dat-rw-------. 1 postgres postgres  718644 12 май 2019 г. 3075.dat-rw-------. 1 postgres postgres 1214420 12  май 2019 г. 3077.dat-rw-------. 1 postgres postgres     271 12 май 2019 г. 3079.dat-rw-------. 1 postgres postgres      57 12 май 2019 г. 3081.dat-rw-------. 1 postgres postgres   45872 12 май 2019 г. restore.sql-rw-------. 1 postgres postgres   55111 12 май  2019 toc.dat

След това изпълняваме следните команди на обвивката в първичния екземпляр на PostgreSQL (PG-Node1). Тези команди правят някои промени във файла restore.sql:

Премахнете всички срещания на „$$PATH$$/“. Това гарантира, че скриптът може да намери всички файлове с данни в една и съща директория
Променете всички срещания на „English_United States.1252“ на „en_US.UTF-8“. Това гарантира, че няма грешки поради липсващ локал, когато скриптът се изпълнява.
Променете командата „DROP DATBASE dvdrental“ на „DROP DATBASE IF EXISTS dvdrental“, така че да не се показва невалидна грешка в базата данни.

# sed -i 's/$$PATH$$\//\/tmp\/dvdrental\//g' /tmp/dvdrental/restore.sql# sed -i 's/English_United States.1252/en_US .UTF-8/g' /tmp/dvdrental/restore.sql# sed -i 's/ИЗПУСКАНЕ БАЗА ДАННИ dvdrental;/ИЗПУСКАНЕ БАЗА ДАННИ, АКО СЪЩЕСТВУВА dvdrental;/g' /tmp/dvdrental/restore.sql

След това преминаваме към потребителя на postgres и изпълняваме следната команда от подканата на shell:

$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql

Това възстановява примерната база данни в основния възел. Ако проверим от OmniDB, можем да видим, че базата данни е създадена:

Заключение

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

Настройката на средата вече е завършена. Във втората част на тази статия ще започнем да създаваме табло за наблюдение на производителността за основния екземпляр.

Как да наблюдавате производителността на PostgreSQL 12 с OmniDB – част 1