PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

PgBouncer 1.7 – „Цветовете варират след възкресението“

PgBouncer е лек пул за връзки за PostgreSQL. PgBouncer 1.7 беше обявен на 18 декември 2015 г. В тази публикация в блога ще говорим за основните нови подобрения в PgBouncer.

Най-цветните функции

  • PgBouncer 1.7 поддържа TLS връзки и мисля, че това е най-голямото подобрение на новата версия. Те използваха OpenSSL/LibreSSL библиотеки като бекенд реализация на функцията.
  • PgBouncer вече поддържа удостоверяване чрез TLS клиентски сертификат .

Нека се задълбочим в подробности за настройките на TLS на PgBouncer. Има 14 конфигурационни параметъра, свързани с настройката на TLS (настройки от страна на клиента + от страна на сървъра).

За да зададем кой режим TLS да използваме за връзки от клиенти, трябва да зададем client_tls_sslmode параметър. TLS връзките са деактивирани по подразбиране. Когато е активирано, client_tls_key_file и client_tls_cert_file трябва също да бъде конфигуриран за настройка на ключ и сертификат, които PgBouncer използва за приемане на клиентски връзки.

Можем да присвоим основен сертификат за валидиране на клиентски сертификати, като зададем client_tls_ca_file параметър, по подразбиране не е зададен.

Можем да посочим кои версии на протокола TLS са разрешени, като зададем client_tls_protocols параметър, по подразбиране е всичко.

За по-подробни настройки от страна на клиента можете да проверите client_tls_ciphers , client_tls_ecdhcurve и client_tls_dheparams параметри.

Сега нека поговорим за конфигурационните параметри от страна на TLS сървъра. Първо, трябва да декларираме TLS режим за използване за връзки към PostgreSQL сървъри с server_tls_sslmode параметър. TLS връзките са деактивирани по подразбиране. Можем да присвоим CA сървър с server_tls_ca_file параметър. Ако искаме да зададем частен ключ за PgBouncer за удостоверяване срещу PostgreSQL сървър, можем да използваме server_tls_key_file параметър, можем дори да присвоим сертификат за частен ключ, който PostgreSQL сървърът може да потвърди с server_tls_cert_file параметър. Както направихме в настройките за TLS връзка от страна на клиента, можем да декларираме кои версии на TLS протокола са разрешени с server_tls_protocols параметър.

  • След поддръжката на TLS, друга важна нова функция е поддръжката за „peer“ удостоверяване на Unix сокети.
  • Като последна основна функция на тази версия бих искал да спомена поддръжката за Host-базиран файл за контрол на достъпа, като pg_hba.conf в Postgres. Това позволява да конфигурирате TLS за мрежови връзки и „peer“ удостоверяване за локални връзки.

Можем да конфигурираме как да удостоверяваме потребители с auth_type параметър на PgBouncer. Всички конфигурационни параметри са дефинирани в конфигурационния файл pgbouncer.ini. Нека разгледаме подробности за auth_type параметър.

auth_type на параметъра може да се присвои една от 6-те стойности, изброени по-долу. Нека видим обясненията и използването на тези стойности.

  • hba : Ако зададем параметър auth_type със стойността hba , трябва да зададем auth_hba_file параметър, както и за показване кой pg_hba.conf файл ще се използва като конфигурация. По този начин позволяваме действителният тип на удостоверяване да бъде зареден от auth_hba_file. Това означава, че можем да използваме различни методи за удостоверяване за различни пътища за достъп. Например, с връзката от версия 1.7 през Unix сокет използва метод за удостоверяване на партньори, в същото време връзката през TCP трябва да използва TLS. Досега файловият формат HBA не поддържа всички методи за удостоверяване на pg_hba.conf. Поддържаните методи са:trust, reject, md5, password, peer и cert.
  • сертификат : Клиентът трябва да се свърже през TLS връзка с валиден клиентски сертификат. След това потребителското име се взема от CommonName поле от сертификат.
  • md5 : Използвайте проверка на паролата, базирана на MD5. auth_file (името на файла за зареждане на потребителски имена и пароли от ) може да съдържа както MD5-криптирани пароли, така и пароли с обикновен текст. Това е методът за удостоверяване по подразбиране.
  • обикновен : Паролата с ясен текст се изпраща по кабел. Оттеглено.
  • доверие : Не се извършва удостоверяване. Потребителското име все още трябва да съществува в auth_file .
  • всякакъв : Подобно на метода за доверие, но даденото потребителско име се игнорира. Изисква всички бази данни да са конфигурирани да влизат като конкретен потребител. Освен това конзолната база данни позволява на всеки потребител да влезе като администратор.

Други блестящи функции

Има още функции, пуснати в тази версия. Можете да посетите страницата на промените в PgBouncer или да разгледате списъка по-долу за други подобрения:

  • Задайте query_wait_timeout до 120s по подразбиране. Този параметър определя максималното време, което заявките могат да прекарат в очакване на изпълнение. Ако заявката не е присвоена на сървър през това време, клиентът се прекъсва. Това се използва за предотвратяване на неотзивчиви сървъри да захващат връзки. Също така помага, когато сървърът не работи или базата данни отхвърля връзки по някаква причина. Ако това е деактивирано, клиентите ще бъдат наредени на опашка безкрайно. Текущата по подразбиране (0) причинява безкрайна опашка, което не е полезно. С версия 1.7, ако клиентът има чакаща заявка и не е бил присвоен към сървърна връзка, клиентската връзка ще бъде прекъсната след 120 секунди по подразбиране.
  • Деактивирайте server_reset_query_always по подразбиране. Сега заявката за нулиране се използва само в пулове, които са в режим на сесия.
  • Увеличете pkt_buf до 4096 байта. Подобрявапроизводителност сTLS . Поведението вероятно е специфично за натоварването, но трябва да е безопасно, тъй като от v1.2 буферите на пакети се разделят от връзките и се използват мързеливо от пула.
  • Очаква се поддръжка на конвейерния брой ReadyForQuery пакети. Това избягва твърде ранното освобождаване на сървъра. Поправки №52.
  • Подобрен sbuf_loopcnt логика – сокетът гарантирано ще бъде повторно обработен, дори ако няма събитие от сокета. Изисква се за TLS тъй като има собствено буфериране.
  • Адаптирайте системните тестове за работа с модерен BSD и MacOS . (Ерик Радман )
  • Премахнете крипта авт. Той е остарял и не се поддържа от PostgreSQL от 8.4 .
  • Коригирайте обикновени “–с грижи” опция за конфигуриране – без аргумент е счупена.

Какво е PgBouncer?

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

Можете да изтеглите PgBouncer от тяхната страница за изтегляне и да започнете да го използвате сега!

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

Приятно четене!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Разделете дадения низ и подгответе изявление за case

  2. Failover &Failback за PostgreSQL на Microsoft Azure

  3. Надграждане на PostgreSQL 11 до PostgreSQL 13 с TimescaleDB и PostGIS в Linux с помощта на pg_upgrade

  4. Rails/Postgresql SQL разлики с дати

  5. Postgres:Добавете ограничение, ако все още не съществува