Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Розділ 17. Установка і робота з сервером.
Ця частина розказує як установити і запустити сервер бази даних і їх зв’язки з операційною системою.
17.1. Обліковий запис користувача PostgreSQL
Як і з будь-яким демоном сервера, що є доступним ззовні, рекомендовано запускати PostgreSQL із окремого аккаунту. Цей аккаунт має володіти даними, що керуються сервером, і не має використовуватись іншими демонами (для прикладу, використання користувача nobody буде поганою ідеєю). Не рекомендовано встновлювати виконавчі файли цього користувача, оскільки тоді інші системи зможуть модифікувати власні бібліотеки.
Щоб додати новий обліковий запис в Unix, використайте команду useradd або adduser. Зазвичай використовується імя postgres, що припускається в цій книжці, але ви можете вибрати інше імя.
17.2. Створення кластера бази даних.
Перед тим, як ви зможете щось робити, ви мусите ініціалізувати місце збереження бази даних на диску. Ми називаємо це кластером бази даних. Кластер бази даних це колекція баз даних, яка управляється одним екземпляром запущеного сервера баз даних. Після ініціалізації, кластер бази даних буде містити базу даних з назвою postgres, яка буде базою даних по замовчуванню для утиліт, користувачів та сторонніх додатків. Сервер бази даних не вимагає існування бази даних postgres, але багато зовнішніх утиліт припускають, що вони існує. Як припускає імя, вона буде використана як шаблон для інших похідних баз даних, і не буде використовуватись для роботи (дивіться більше в розділі 21 про створенні нової бази даних в кластері).
Згідно вимог файлової системи, кластер буде єдиним каталогом, в якому будуть зберігатись дані. Ми називаємо його каталогом даних. Це залежить тільки від вас, де ви збираєтесь зберігати дані. Немає значення по замовчуванню, хоча популярними є розміщення /usr/local/pgsql/data або /var/lib/pgsql/data. Щоб ініціалізувати кластер бази даних, використайте команду initdb, яка інсталюється з PostgreSQL. Потрібне розміщення вашого кластера визначається опцією –D, для прикладу:
$ initdb -D /usr/local/pgsql/data
Зауважте, що ви маєте виконати цю команду під обліковим записом користувача PostgreSQL, який описаний в попередньому розділі.
Як альтернатива –D, може бути використана установка змінної PGDATA.
Ми можете запустити initdb через програму pg_ctl так:
$ pg_ctl -D /usr/local/pgsql/data initdb
Це може бути більш інтуїтивно, якщо ви використовуєте pg_ctl для запуску і зупинки сервера (Розділ 17.3), тому pg_ctl буде вашою головною командою в роботі з екземпляром сервера бази даних.
Initdb спробує створити каталог, який ви задали, якщо його не існує. Ймовірніше за все, він не буде мати дозволу на це (якщо ви послухались нашої поради і створили непривілейований обліковий запис). В цьому випадку ви маєте створити каталог самостійно і змінити власника на користувача PostgreSQL. Це робиться ось так:
root# mkdir /usr/local/pgsql/data
root# chown postgres /usr/local/pgsql/data
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data
initdb не запуститься, якщо каталог даних вже був ініціалізований.
Оскільки каталог даних містить всі дані, що зберігаються у базі, він має бути захищеним від неавторизованого доступу initdb обмежує доступ для всіх крім користувача PostgreSQL.
Хоча і вміст каталога захищений, аутентифікація по замовчуванню дозволяє будь-якому локальному користувачу зв’язатись з базою даних і навіть стати суперкористувачем бази даних. Якщо ви не довіряєте іншим локальним користувачам, ми рекомендуємо вам використати одну з опцій initdb -W, --pwprompt або –pwfile для присвоєння пароля суперкористувачу. Також задайте -A md5 або -A password, для того щоб не використовувати trust по замовчуванню. Або змініть генерований файл pg_hba.conf після запуску initdb, але перед першим запуском сервера.
Initdb також ініціалізує налаштування по замовчуванню кластера бази даних. Зазвичай він просто візьме налаштування середовища і застосує їх до бази даних. Можливо також задавати інші налаштування (більше про це в розділі 22.1). Порядок сортування по замовчуванню задається initdb, тож коли ви створюєте нову базу даних з іншим порядком сортування, порядок в шаблонах, які створюються initdb, не може бути змінений без видалення і перестворення їх. Також можуть бути конфлікти виконання налаштувань, відмінних від C або POSIX. Тому, важливо робити правильний вибір.
Initdb також задає кодування для кластера бази даних. Він вибирається у відповідності до налаштувань. Конкретніше про це у розділі 22.2
17.2.1. Мережеві файлові системи.
Більшість установок створює кластери баз даних на мережевих файлових системах. Деколи це робиться напряму з NFS або використанням Network Attached Storage (NAS), що використовує NFS. PostgreSQL не робить нічого специфічного для NFS, тобто припускає, що NFS поводиться як локальні приводи (DAS, Direct Attached Storage). Якщо виконання NFS клієнта та сервера мають нестандартну семантику, це може створити проблему надійності (http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html). Відкладені (асинхронні) записи в сервер можеть спричинити проблеми. Якщо можливо, монтуйте синхронні системи. Також софт-монтування не рекомендується. (Storage Area Networks (SAN) використовує нижчий протокол звязку, ніж NFS.)
17.3. Запуск сервера бази даних.
Перед тим, як будь хто отримає доступ до бази даних, ви маєте запустити сервер. Програма сервера бази даних називається postgres. Вона має знати, де знайти дані, які мають використовуватись. Це робиться завдяки опції –D. Для прикладу:
$ postgres -D /usr/local/pgsql/data
Що залишить сервер запускатись. Це має робитись під записом користувача PostgreSQL. Без -D, сервер спробує використати каталог даних, названий у змінній середовища PGDATA. Якщо ця змінна не задана, він не запуститься.
Краще запускати сервер у фоні. Це робиться використовуючи синтаксис оболонки Unix:
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &
Важливо зберігати виводи сервера stdout та stderr в місці, показаному вище. Це допоможе для діагностики проблем (більше про управління логами розділі 23.3).
Програма postgres також має ще деякі опції командного рядка. Для решти інформації, дивіться роділ 18.
Цей синтаксис може скоро стати утомляючим. Тому завдання можна спростити використанням програми pg_ctl. Для прикладу pg_ctl start -l logfile запустить сервер у фоні і виведе все в названий файл логів. –D має тут таке ж значення, postgres. pg_ctl може також зупиняти сервер.
Зазвичай ви захочете, щоб сервер запускався при завантаженні комп’ютера. Скрипти авто запуску залежать від операційної системи, деякі з них ідуть в комплекті з PostgreSQL в каталозі contrib/start-scripts. Запуск їх вимагає прав суперкористувача.
Різні системи мають різні шляхи запуску демонів в процесі завантаження, в будь-якому випадку сервер має запускатись тільки під обліковим записом користувача PostgreSQL і ні під яким іншим. Ви маєте формувати ваші команди так: su -c ’...’ postgres. Для прикладу:
su -c ’pg_ctl start -D /usr/local/pgsql/data -l serverlog’ postgres
Ще декілька специфічних порад (в будь-якому випадку впевніться про використання вашого каталогу та імені користувача замість загальних, які ми подаємо).
Для FreeBSD дивіться в contrib/start-scripts/freebsd в дистрибутиві вихідних кодів PostgreSQL.
Для OpenBSD додайте наступні рядки в файл /etc/rc.local:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
su - -c ’/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s’ postgres
echo -n ’ postgresql’
fi
на системах Linux додайте
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data в /etc/rc.d/rc.local або знайдіть contrib/start-scripts/linux в дистрибутиві вихідних кодів PostgreSQL.
На NetBSD, використовуйте скрипти FreeBSD або Linux, в залежності від опцій.
На Solaris, створіть файл /etc/init.d/postgresql що містить рядок
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Тоді створіть зв'язок з ним в /etc/rc3.d як S99postgresql.
Поки сервер працює, його PID зберігається у файлі postmaster.pid. Це використовується для запобігання запуску одного каталогу даних різними екземплярами сервера, а також для зупинки сервера.
17.3.1. Помилки запуску сервера.
Є декілька звичних причин помилки запуску. Перевірте файл логів, або запустіть його вручну без пере направлення на стандартнай вивід чи помилку, і подивіться на повідомлення помилок. Ми пояснимо деякі з них більш детально.
LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket
Це означає, що ви спробували запустити інший сервер на тому самому порті, де вже працює один сервер. Якщо повідомлення не є Address already in use або подібне, то це може бути інша причина. Наприклад запуск на зарезервованому порті дасть щось подібне:
$ postgres -p 666
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket
Повідомлення типу
FATAL: could not create shared memory segment: Invalid argument
DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
Швидше за все означає, що обмеження ядра на об’єм памяті загального доступу менший, ніж робочий простір, який хоче створити PostgreSQL. Або це може означати, що у вас немає взагалі підтримки памяті загального доступу System-V-style. Як тимчасове вирішення, ви можете запустити сервер з меншим розміром буфера (shared_buffers). Ви також можете побачити повідомлення при запуску кількох серверів, якщо їх загальний простір більший за обмеження ядра.
Помилка типу:
FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(5440126, 17, 03600).
Не означає, що у вас немає місця на диску. Це означає, що обмеження ядра на кількість семафорів System V, менше, ніж хоче створити PostgreSQL. Як і вище, ви можете зменшити максимальну кількість підключень (max_connections), але пізніше вам треба буде збільшити обмеження ядра.
Якщо ви отримуєте “illegal system call” це означає, що пам'ять загального доступу або семафори взагалі не підтримуються вашою системою. Вам потрібно пере налаштувати ядро.
Детальніше про конфігурацію SystemVIPC в розділі Section 17.4.1.
17.3.2. проблеми зєднання клієнта.
Хоча помилки зі сторони клієнта дуже різняться і залежать від додатків, деякі з них напряму відносяться до запуску сервера. Інші ж умови мають бути задокументовані в клієнтському додатку.
psql: could not connect to server: Connection refused
Is the server running on host "server.joe.com" and accepting
TCP/IP connections on port 5432?
Це загальна помилка «Я не можу знайти сервер». Це відбувається при доступі до зєднання TCP/IP. Звичною помилкою є забути про дозвіл серверу зєднань TCP/IP.
Ви можете також отримати це, коли з’єднуєте сонет домена Unix з локальним сервером:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Останній рядок потрібен для переконання, що клієнт звертається до правильного місці. Якщо там не може бути сервера взагалі, то помилка буде Connection refused або No such file or directory, як показано вище. (Важливо зрозуміти, що Connection refused не означає, що сервер прийняв запит на зєднання і відхилив його. Цей випадок дасть інше повідомлення, як показано в розділі 19.4.). Інші повідомлення помилок, як наприклад Connection timed out показують більш фундаментальні проблеми, як, наприклад погане зєднання.
17.4. Робота з ресурсами ядра.
Велика установка PostgreSQL може швидко перевищити обмеження ресурсів операційної системи (на деяких системах вони такі низькі, що не треба надто великої установки). Якщо ви стикнулися з цією проблемою, читайте далі.
17.4.1. Пам'ять загального доступу і семафори.
Пам'ять загального доступу і семафори посилаються на “SystemV IPC” (разом з чергами повідомлень, які не використовуються в PostgreSQL). Більшість сучасних операційних систем забезпечують ці можливості, але багато з них не включають їх, або мають неефективний розмір по замовчуванню, особливо для доступної ОЗП та росту додатків бази даних. (на Windows, PostgreSQL забезпечує власне вионання цих служб, тому більшість цього розділу буде непотрібною.
Більшість помилок в цих можливостях супроводжуються помилкою Illegal system call під час запуску сервера. В цьому випадку немає інакших рішень, крім як пере конфігурувати ядру. PostgreSQL не буде працювати без них. Хоча це рідкісна ситуація в сучасних операційних системах.
Коли PostgreSQL досягає одного з обмежень IPC, сервер не буде працювати і залишить про це повідомлення, яке описує помилку (дивіться також розділ 17.3.1.) Відповідні параметри називаються подібно в різних системах. Таблиця 17-1 дає можливість їх переглянути. Методи для установки їх різняться. Поради для деяких платформ подані нижче.
Найбільш важливим параметром памяті загального доступу є SHMMAX, максимальний розмір, у байтах, сегменту памяті загального доступу. Якщо ви отримуєте повідомлення помилки від shmget типу “Invalid argument”, це означає, що обмеження перевищено. Розмір потрібного сегменту залежить від параметрів конфігурації PostgreSQL, показаній в таблиці 17-2 (будь-яке повідомлення помилки буде включати розмір запиту, що не запустився). Ви можете тимчасово понизити деякі з опцій, щоб уникнути помилок. Поки можливо буде запускати PostgreSQL з SHMMAX розміром в 2 Мб, ви отримаєте більш-менш задовільне виконання. Бажані вимоги – від сотень мегабайтів до декількох гігабайтів.
Деякі системи також мають обмеження загального об’єму памяті загального доступу. Впевніться, що вона досить велика для роботи з PostgreSQL та інших додатків. Зауважте, що SHMALL в деяких системах вимірюється в сторінках, а не байтах.
Менш ймовірно, що проблемою є мінімальний розмір сегментів, які мають бути приблизно 500 кб. Максимальний розмір сегментів в системі SHMMNI та для процесу SHMSEG можуть спричинити проблему, якщо система встановила їх в 0.
PostgreSQL використовує один семафор на одне дозволене зєднання і дозволений процес autovacuum, в наборах із 16. Кожен такий набір має 17 семафор, який містить «чарівне число», щоб бачити колізії з наборами семафорів, що використовуються іншими додатками. Максимальне число семафорів в системі задається SEMMNS, який має бути хоча б рівним max_connections плюс autovacuum_max_workers, плюс один додатковий на кожен з 16 дозволених зв’язків плюс робочих. Параметр SEMMNI визначає ліміт кількості наборів семафорів, які можуть існувати в системі одночасно. Цей параметр має бути рівний хоча б ceil((max_connections + autovacuum_max_workers) / 16). Пониження числа доступних зєднань є тимчасовим вирішенням проблеми, яка супроводжується “No space left on device” з функції semget.
В деяких випадках також може бути необхідним збільшити SEMMAP у відповідності до SEMMNS. Цей параметр визначає розмір карти ресурсів семафорв, в який має ввійти кожен блок доступних семафорів. Коли набір семафорів звільняється він додається до існуючого входу, або реєструється у вході нової карти. Коли карта повна, звільнені семафори втрачаються (до перезавантаження). Фрагментація простору семафорів веде до зменшення їх кількості.
Параметр SEMMSL, що визначає кількість семафорів в наборі, має бути не меншим, ніж 17 для PostgreSQL..
Решта налаштувань, наприклад SEMMNU та SEMUME не впливають на PostgreSQL.
AIX
Як мінімум з версії 5.1 не потрібно робити спеціальну конфігурацію для параметрів типу SHMMAX, тому що дозволяється використовувати всю пам'ять як пам'ять загального доступу. Це конфігурація, яка зазвичай використовується для інших баз даних, наприклад DB/2.
Але може бути необхідним модифікувати інформацію ulimit в /etc/security/limits, тому що обмеження по замовчуванню для розмірів і кількості файлів можуть бути дуже низькими.
BSD/OS
Пам'ять загального доступу – тільки 4 Мб. Зауважте, що вона не сторінкована і розташовується в ОЗП. Щоб збільшити розмір пам'яті додайте наступне в файл конфігурації ядра
options "SHMALL=8192"
options "SHMMAX=\(SHMALL*PAGE_SIZE\)"
SHMALL вимірюється в 4 Кб сторінках, тому значення 1024 представляє 4 Мб. Тому вказаний вище код збільшує його до 32 Мб. Запускаючи 4.3 і пізніші вам напевно прийдеться збільшити KERNEL_VIRTUAL_MB з 248 по замовчуванню. Коли зробите ці зміни, перекомпілюйте ядро і перезапустіть систему.
Семафори. Ви захочете збільшити кількість семафорів, тому що по замовчуванню їх 60, що дозволяє близько 50 зєднань. Встановіть значення в файлі конфігурації ядра:
options "SEMMNI=40"
options "SEMMNS=240"
FreeBSD по замовчуванню налаштування підходять для малої установки (для прикладу значення SHMMAX – 32 Мб). Зміни робляться через інтерфейси sysctl або loader. Наступні параметри можуть встановлюватись з використанням sysctl:
$ sysctl -w kern.ipc.shmall=32768
$ sysctl -w kern.ipc.shmmax=134217728
$ sysctl -w kern.ipc.semmap=256
Щоб записати їх навіть після перезавантаження, змініть /etc/sysctl.conf.
Налаштування семафорів, що залишились, недоступні для запису sysctl, але можуть бути змінені перед завантаженням з використанням loader
(loader) set kern.ipc.semmni=256
(loader) set kern.ipc.semmns=512
(loader) set kern.ipc.semmnu=256
Може бути збережено в /boot/loader.conf.
Ви також можете захотіти закрити пам'ять загального доступу в RAM, щоб не записувати її в файл підкачки. Це виконується налаштуванням kern.ipc.shm_use_phys в sysctl.
Якщо запуск FreeBSD відбувається з включенням security.jail.sysvipc_allowed, решта роботи виконується різними користувачами операційної системи. Це удосконалює захист і не дозволяє іншим користувачам працювати з пам’яттю загального доступу і семафорами в різних сеансах, і дозволяє коду PostgreSQL IPC правильно функціонувати. (в FreeBSD6.0 і підніших код очистки неправильно визначає процеси інших сеансів, запобігаючи запуску процесів на одних портах в різних сеансах).
Версії FreeBSD нижче 4.0 працюють як NetBSD та OpenBSD
NetBSD
OpenBSD
Опції SYSVSHM і SYSVSEM мають бути включені при компіляції ядра. Максимальний розмір памяті загального доступу визначається опцією SHMMAXPGS (у сторінках). Наступне показує приклад установки різних параметрів:
options SYSVSHM
options SHMMAXPGS=4096
options SHMSEG=256
options SYSVSEM
options SEMMNI=256
options SEMMNS=512
options SEMMNU=256
options SEMMAP=256
Ви також можете захотіти закрити пам'ять загального доступу в RAM, щоб не записувати її в файл підкачки. Це виконується налаштуванням kern.ipc.shm_use_phys в sysctl.
HP-UX
Налаштування по замочуванню дозволяють нормальну установку. На HP-UX 10, для SEMMNS значення 128, що замало для великих баз даних.
Параметри IPC можуть задаватись в Administration Manager (SAM) в KernelConfiguration−→Configurable Parameters. Виберіть Create A New Kernel, коли закінчите.
Linux
Розмір сегмента по замовчуванню – 32 Мб, що адекватно тільки для малих установок PostgreSQL. Максимальний розмір - 2097152 pages. Розмір сторінки – 4096 байт, за виключенням конфігурацій з великими сторінками (getconf PAGE_SIZE для інформації). Це робить доступним 8 Гб, чого часто досить, але не завжди.
Розмір памяті загального доступу міняються інтерфейсом sysctl. Для прикладу, для дозволу 16 Гб:
$ sysctl -w kernel.shmmax=17179869184
$ sysctl -w kernel.shmall=4194304
В додаток, ці опції можуть бути введені в /etc/sysctl.conf. Це рекомендується.
Старі дистрибутиви можуть не мати програми sysctl, але ці зміни можна зробити, маніпулюючи файлом
$ echo 17179869184 >/proc/sys/kernel/shmmax
$ echo 4194304 >/proc/sys/kernel/shmall
Решта значень зазвичай не потребують змін
MacOSX
Рекомендований метод для конфігурації памяті загального доступу – створення файлу /etc/sysctl.conf, що містить наступні присвоєння:
kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024
Зауважте, що в деяких версіях OS X всі параметри мають установлюватись в /etc/sysctl.conf, інакше значення будуть ігноруватись.
Остерігайтесь того, що теперішні релізи OSX ігнорують спроби установки SHMMAX до значення, яке є пропорційне 4096.
SHMALL вимірюється 4Кб сторінками на цій платформі.
У старших версіях OSX вам потрібно перезапуститись, щоб зміни вступили в дію. З версії 10.5 можна міняти на ходу все, крім SHMMNI, використовуючи sysctl. Але краще це зробити, вносячи параметри в /etc/sysctl.conf.
Файл /etc/sysctl.conf працює в OS X 10.3.9 і пізніших. Якщо ви запускаєте старіші релізи, вам треба редагувати файл /etc/rc і змінити значення в наступних командах.
sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall
Зауважте, що /etc/rc зазвичай переписується після оновлення системи, тож вам потрібно буде повертати ці зміни.
В OS X 10.2 і раніших, робіть ці зміни в файлі /System/Library/StartupItems/SystemTuning/SystemTuning.
SCOOpenServer
По замовчуванню, доступний тільки сегмент розміром 512 Кб. Для збільшення цього значення перейдіть в каталог /etc/conf/cf.d. Щоб вивести поточне значення, введіть ./configure -y SHMMAX
Щоб встановити нове значення, введіть
./configure SHMMAX=value,
Де value нове значення в байтах. Після внесення змін перебудуйте ядро:
./link_unix
І перезапустіться.
Solaris
Як мінімум в версії 2.6, максимальний розмір сегмента по замовчуванню надто малий для PostgreSQL. Відповідні значення можуть бути змінені в /etc/system, наприклад:
set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32
Виконайте перезавантаження, щоб зміни набули чинності. Також на рахунок памяті загального доступу відвідайте адресу http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html
UnixWare
На UnixWare 7, максимальний розмір сегменту тільки 512 kB, щоб вивести поточне значення, введіть:
/etc/conf/bin/idtune -g SHMMAX, що видасть поточне, по замовчуванню, мінімальне та максимальне значення. Щоб встановити нове значення, введіть
/etc/conf/bin/idtune SHMMAX value
Де value – бажане значення в байтах. Після цього перебудуйте ядро:
/etc/conf/bin/idbuild -B
І перезапустіть систему.
17.4.2. обмеження ресурсів.
Unix-подібні операційні системи мають різні види обмеження ресурсів, які можуть накладатись на операції сервера. Це ліміт на кількість процесів на одного користувача, кількість відкритих файлів на процес, кількість памяті на один процес. Кожен з них має м’який і жорсткий ліміт. Мякий ліміт може редагуватись користувачем до значення жорсткого ліміту. Жорсткий ліміт може змінюватись тільки суперкористувачем. За встановлення цих параметрів відповідає setrlimit. Вбудована в оболонку команда ulimit або limit використовується для контролю обмежень ресурсів із командного рядка. На системах сімейства BSD обмеження контролює файл /etc/login.conf. Для детальнішої інформації дивіться документацію операційної системи. Потрібні параметри - maxproc, openfiles і datasize. Для прикладу:
default:\
...
:datasize-cur=256M:\
:maxproc-cur=256:\
:openfiles-cur=256:\
...
(-cur – мякий ліміт, використовуйте –max для установки жорсткого ліміту.
Ядра також можуть мати обмеження на деякі ресурси.
На Linux /proc/sys/fs/file-max визначає максимальну кількість підтримуваних відкритих файлів. Вона можа мінятись записом іншого значення в файл, або додаваннм присвоєння в /etc/sysctl.conf. Максимальне обмеження поміняється після компіляції ядра. Більше дивіться в /usr/src/linux/Documentation/proc.txt
Сервер PostgreSQL використовує один процес на зєднання, тому вам треба забезпечити хоча б кількіст процесів рівну максимальній кількості підключень, в додаток до того, що потрібно для решти системи. Це не проблема, але якщо ви запускаєте декілька серверів на одній машині, все може змінитись.
За замовчуванням обмеження відкритих файлів задане на таке значення, що дозволить багатьом користувачаи існувати на одній машині без розбиття ресурсів, але якщо ви будете запускати декілька серверів, вам потрібно буде збільшити ці обмеження.
З іншої сторони, деякі системи дозволяють відкривати дуже багато файлів. І якщо запуститься трохи більше процесів, системний ліміт буде перевищено. Якщо ви побачите це, і не захочете міняти це у всій системі, можете встановити параметр PostgreSQL max_files_per_process.
17.4.3. Вихід за межі памяті в Linux
В версіях Linux2.4 і пізніше по замовчуванню поведінка віртуальної памяті не є прийнятною для PostgreSQL. Після виходу за межі памяті, ядро знищить сервар, якщо пам'ять, виділена на інший процес заставить ситсему вийти за обмеження віртуальнох памяті. Коли це станеть, ви отримаєте таке повідомлення :
Out of Memory: Killed process 12345 (postgres).
Це показує, що процес був вбитий через недостачу памяті. Існуючі знання будуть працювати, але нові встановити буде неможливо. Для відновлення треба перезапустити PostgreSQL.
Одним із способів уникнути цієї проблеми є запуск PostgreSQL на машині, де ви впевнені, що інші процеси не займуть всю пам'ять. Також може допомогти збільшення файлу підкачки, тому що процеси будуть знищуватись, коли закінчиться підкачка та фізична пам'ять.
В Linux 2.6 і пізніших, можливо модифікувати поведінку ядра, тож воно не буде перенавантажувати пам'ять. Хоча це не запобігне знищенню процесів, але воно знизить шанси на це, і зробить поведінку системи більш передбачуваною. Це робиться включенням строгого режиму через sysctl:
sysctl -w vm.overcommit_memory=2
Або вставлянням цього в /etc/sysctl.conf. Ви можете також захотіти модифікувати значення vm.overcommit_ratio. Детальніше в файлі документації Documentation/vm/overcommit-accounting.
Іншим способом є задання специфічного значення oom_adj для процесу -17, що гарантує йому недоторканість при знищенні процесу. Найпростіше це зробити так:
echo -17 > /proc/self/oom_adj
Це має робитись суперкористувачем. Якщо ви зробили це, треба будувати PostgreSQL з доданим в CFLAGS -DLINUX_OOM_ADJ=0. Це змусить дочірні процеси запускатись зі значенням oom_adj рівним нулю, тому при потребі вони будуть знищуватись.
Зауваження: деякі ядря Linux2.4 мають раніші версії sysctl параметру перенавантаження. Установка vm.overcommit_memory в 2 на ядрі 2.4 зробить ще гірше. Рекомендовано переглянути код ядра і подивитись, чи підтримується ця функція перед тим, як пробувати установку. Якщо сумніваєтесь, проконсультуйтеся з розробником ядра.
17.5. Зупинка сервера.
Є декілька способів зупинити сервер баз даних. Ви контролюєте закриття посиланням різних сигналів основному процесу postgres
SIGTERM
Це режим розумної зупинки. Після отримання SIGTERM, сервер забороняє нові підключення, але дозволяє існуючим сесям працювати нормально. Він закривається тільки після закриття всіх сесій. Якщо він знаходиться в режимі онлайн бекапу, він чекає поки цей режим стане неактивним. Поки цей режим активний, нові підключення будуть дозволятись, але тільки для суперкористувачів (що дозволяє суперкористувачу вручну закрити цей режим). Якщо сервер відновлюється, коли йде запит на розуну зупинку, відновлення зупиниться після закриття всіх сесій.
SIGINT
Швидка зупинка. Сервер забороняє підключення, розсилає всім процесам SIGTERM, що спричиняє зупинку транзакцій і вихід. Він чекає закриття всіх процесів і закривається сам. Режим онлайн бекапу закриється, якщо він був запущений.
SIGQUIT
Негайна зупинка. Postgres розішле всім дочірнім процесам SIGQUIT і закриється. Так само закриються дочірні процеси. Це призводить до відновлення при наступному запуску. Використовується тільки у випадку небезпеки.
Програма pg_ctl забезпечує зручний інтерфейс для посилання цих сигналів для закриття сервера. Ви також можете послати прямий сигнал з використанням kill на системах, що не відносяться до Windows. PID процесу postgres може бути знайдене використанням програми ps, або з файлу postmaster.pid в каталозі даних. Наприклад, щоб зробити швидке закриття:
$ kill -INT ‘head -1 /usr/local/pgsql/data/postmaster.pid‘
Важливо: краще не використовувати SIGKILL для закриття сервера. Це запобігне звільненню памяті загального доступу та семафорів, яке в цьому випадку треба робити вручну перед запуском нового сервера. SIGKILL вбиває процес postgres без дозволу посилання сигналу під процесам, тому їх прийдеться вбивати так само вручну.
Для видалення окремої сесії, використовуйте pg_terminate_backend() або пошліть сигнал SIGTERM до дочірнього процесу, асоційованого з сесією.
17.6 запобігання обману сервера.
Поки сервер працює, сторонній користувач не може працювати з сервером бази даних. Але коли сервер закривається, для локального користувача є можливість обманути сервер запуском власного сервера. Він може читати паролі і запити послані користувачами, але не може повертати даних, оскільки каталог PGDATA все одно буде захищеним. Обман можливий, оскільки будь-який користувач може запустити сервер. Клієнт не можу ідентифікувати неправильний сервер без спеціальної конфігурації.
Найпростішим способом уникнути обману для локальних зєднань, є використання дозволу запису в каталог сонета домена Unix тільки для довіреного користувача. Це запобігає створення файлу сокета в цьому каталозі іншими користувачами. Якщо ви знаєте, що деякі додатки все одно будуть посилатись на /tmp для файла сонету і буде можливість для обману, підчас старту системи створіть посилання /tmp/.s.PGSQL.5432, яке вказує на переміщений файл сокета. Ви також можете модифікувати скрипт очищення для запобігання видалення цього посилання.
Щоб запобігти обману на зєднаннях TCP кращим способом є використання сертифікатів SSL і перевірка клієнтом сертифікату сервера. Для цього сервер має бути відлагоджений для прийому тільки зв’язків hostssl і мати ключ SSLserver.key і сертифікат server.crt. Клієнт TCP має з’єднуватись використанням sslmode=verify-ca або verify-full і мати відповідний установлений файл сертифікату.
17.7. опції шифрування.
PostgreSQL пропонує шифрування кількох рівнів і забезпечує гнучкість в захисті даних від зловмисників, недобросовісних адміністраторів та незахищених мереж. Кодування також може бути потрібним для захисту медицинських записів і фінансових транзакцій.
Шифрування пароля.
По замовчуванню, паролі зберігаються в хешах MD5, тому адміністратор не може визначити пароль, присвоєний користувачу. Якщо для аутентифікації використовується шифрування MD5, дешифрований пароль ніколи не буде тимчасово відомим, оскільки клієнтський MD5 шифрує його перед пересилкою по мережі.
Шифрування окремих колонок.
Функція contrib бібліотеки pgcrypto дозволяє окремим полям зберігатись шифрованими. Це корисно, якщо є якісь важливі дані. Клієнт підтримує ключ дешифрування і дані декодуються сервером і відправляються клієнту.
Шифрування розділа даних.
На лінуксі, шифрування може накладатись на корінь файлової системи використанням “loopback device”. Це дозволяє розділу файлової системи знаходитись на диску в шифрованому вигляді і декодуватись операційною системою. На FreeBSD, ця служба називається GEOM Based Disk Encryption (gbde) і багато систем, включаючи Віндовс, її підтримують.
Цей механізм запобігає читанню нешифрованих даних з дисків, якщо їх вкрадуть. Це не захищає від атак, коли файлова система змонтована, оскільки операційна система дешифрує їх. Для монтування системи вам треба ввести код шифрування, а ін. деколи зберігається на хості, що монтує диск.
Шифрування паролів в мережі.
Метод MD5 двічі шифрує пароль перед посиланням на сервер. Перший MD5 шифрує імя користувача і шифрує випадкову інформацію, генеровану сервером при зєднанні. Це значення пересилається в мережі. Подвійне шифрування запобігає читанню пароля та використанню пароля іншим зєднанням.
Шифрування даних в мережі
Зєднання SSL шифрують всі дані, що посилаються через мережу: пароль, запити, і повернені дані. Файл pg_hba.conf дозволяє адміністратору специфікувати, які хости використовують нешифровані зєднання, а які вимагають шифрованих зєднань. Також клієнти можуть визначати, що вони з’єднуються до сервера тільки через SSL. Також це шифрування застосовується для кодування передачі.
SSL аутентифікація хоста.
Можливо для клієнта та сервера забезпечувати одне для одного сертифікати SSL. Це займає більше конфігурування, але забезпечує суворішу ідентифікацію ніж звичайне використання паролів. Це запобігає випадкам, коли комп’ютер прикидається сервером для отримання пароля клієнта. Це також запобігає атакам «людини всередині», коли комп’ютер між клієнтом і сервером прикидається сервером, читає і передає дані між ними.
Клієнтське шифрування
Якщо системний адміністратор для серверної машини не має довіри, для клієнта необхідне шифрування даних. Так, нешифровані дані ніколи не появляться на сервері. Дані кодуються клієнтом перед відправкою на сервер, і результати бази даних розкодовуються на клієнті перед використанням.
17.8. Захист зєднань TCP/IP з допомогою SSL
PostgreSQL має рідну підтримку використання підключень SSL, щоб кодувати клієнт-серверні зв'язки для підвищеного захисту. Це вимагає, щоб OpenSSL встановлювався як на клієнт, так і на серверну систему, і ця підтримка в PostgreSQL включена в час компонування.
З підтримкою SSL, сервер PostgreSQL може бути запущений з SSL, включений заданням параметра ssl в postgresql.conf. Сервер прослуховуватиме як нормальні, так і підключення SSL на
тому ж порту TCP, і вестиме переговори з будь-яким сполучним клієнтом про те, чи використовувати SSL. За умовчанням, це є опцією клієнта; подивіться розділ 19.1 про те, як встановити сервер, щоб вимагати використання SSL для одного або усіх підключень.
PostgreSQL читає широкий OpenSSL файл конфігурації. За умовчанням, цей файл - openssl.cnf, розташований в каталозі, заданому openssl version –d.Ц е значення по умовчанню може замінити установка змінної середовища OPENSSL_CONF на імя бажаного configuration файлу.
OpenSSL підтримує широкий діапазон шифрів і аутентифікаційні алгоритми, змінної сили. Поки список шифрів може бути вказаний в OpenSSL файлі конфігурації, ви можете конкретизувати шифри особливо для використання сервером бази даних, змінюючи ssl_ciphers в postgresql.conf.
Відмітьте: можливо мати аутентифікацію без кодування вгорі використовуючи NULL-SHA або шифри NULL-MD5. Проте, людина всередині може прочитати і передавати зв'язки між клієнтом і сервером. Також, кодування порівнюється з аутентифікацією.Тому ці шифри не рекомендовані. Щоб запуститись в режимі SSL, файли server.crt і server.key повинні існувати в каталозі даних сервера. Ці файли повинні містити серверне свідоцтво і приватний ключ, відповідно. На системах Unix, права доступу на server.key повинні відхиляти будь-який доступ до світу або групи; досягнути цього можна командою chmod 0600 server.key. Якщо приватний ключ захищається з паролем, сервер буде чекати пароля і не запуститься до його введення.
В деяких випадках, сертифікат сервера може бути підписаним посереднім повноваженням сертифікату, а не тим, що напряму довірений для клієнтів. Щоб використати такий сертифікат, приєднайте сертифікат повноважень до файлу server.crt, потім їх батьківський сертифікат, і так далі по дереву до кореневого сертифіката довіреного для клієнтів. Кореневий сертифікат має бути включений в будь-якому випадку, де server.crt містить більше, ніж один сертифікат.
17.8.1. використання клієнтських сертифікатів.
Щоб вимагати у клієнта відповідності довіреному сертифікату, помістіть сертифікат сертифікованих повноважень, яким ви довіряєте в файл root.crt в каталозі даниз, і встановіть параметр clientcert в 1 у відповідному рядку hostssl в pg_hba.conf. Сертифікат буде вимагатись у клієнта під час свтановлення звязку SSL (більше проце в розділі 31.17). Сервер буде перевіряти, чи клієнтський сертифікат підписаний одною із повноважних сертифікацій.. Входи в Certificate Revocation List (CRL) відзначаються, якщо файл root.crl існує. (для діаграм, які демонструють використання SSL дивіться http://h71000.www7.hp.com/DOC/83final/BA554_90007/ch04s02.html).
Опція clientcert в pg_hba.conf доступна для всіх методів аутентифікації, але тільки для рядків, визначених як hostssl. Коли clientcert не специфікований, або встановлений на 0. Сервер буде перевіряти клієнтські сертифікати крім root.crt, якщо цей файл існує, але не буде наполягати на присутності сертифікату.
Зауважте, що root.crt перелічує всі СА верхнього рівня, що мають використовуватись для підпису клієнтських сертифікатів. В принципі не потрібно перелічувати СА, які довірені серверу, оскільки вони всі будуть довірені клієнтам.
Якщо ви встановлюєте клієнтський сертифікат, ви можете захотіти використати метод аутентифікації cert, тоже це буде забезпечувати безпеку зєднання. Дивіться більше в розділі 19.3.9.
17.8.2. використання файла сервера SSL.
Файли server.key, server.crt, root.crt, і root.crl перевіряються при запуску сервера. Для введення змін в силу ви маєте його перезапустити.
17.8.3. Створення власного сертифіката.
Для створення такого сертифіката для сервера, використайте наступну команду OpenSSL:
openssl req -new -text -out server.req
Заповніть інформацію, яку запитує openssl. Впевніться, що ввели імя локального хоста як “Common Name”. Пароль можна залишити пустим. Програма буде генерувати ключ, який захищений паролем. Він не прийме пароль, якщо він коротший від 4 символів. Щоб видалити пароль, введіть команду
openssl rsa -in privkey.pem -out server.key
rm privkey.pem
Введіть старий пароль для розблокування існуючого ключа. Тоді зробіть:
openssl req -x509 -in server.req -text -key server.key -out server.crt
Щоб перетворити сертифікат у власний і скопіювати ключ і сертифікат туди, де їх буде шукати сервер. Нарешті зробіть:
chmod og-rwx server.key
Оскільки сервер відкине файл, якщо його дозволи більш ліберальні, ніж сервера. Для детальної інформації про те, як створити ключ і сертифікат, дивіться документацію OpenSSL.
Власний сертифікат може використовуватись для тестування, але сертифікат підписаний СА (один з глобальних, а не локальний) має використовуватись у продукції, тож клієнти мають перевіряти сервер. Якщо всі клієнти є локальними, рекомендується використання СА.
17.9. захист TCP/IP-зєднань з допомогою SSH Тунелів.
Можливо використати SSH для шифрування звязків між клієнтами і сервером. Правильно зроблене, воно забезпечує хороший захист для зєднання, навіть для клієнтів, що не підтримує SSL.
Спочатку перевірте, що сервер SSH працює правильно на тій же машині, що й PostgreSQL і ввійдіть як деякий користувач, використовуючи ssh. Тоді ви можете встановити захисний тунель командою з клієнтської машини:
ssh -L 63333:localhost:5432 joe@foo.com
Перше число в аргументі -L , 63333, це номер порта вашого кінця тунеля. Це може бути будь-який невикористовуваний порт. (IANA резервують порти з 49152 до 65535 для приватного використання). Друге число, 5432, це віддалений кінець тунеля. Номер порта, який використовує сервер. Імя або ІР-адреса між номерами портів – це хост за сервером бази даних, до якого ви пробуєте підєднатись, як його видно із хоста, з якого ви зайшли, що є в прикладі foo.com. Щоб підєднатись до сервера бази даних використовуючи цей тунель, ви зєднуєтесь до порта 63333 на локальній машині:
psql -h localhost -p 63333 postgres
Тепер сервер бази даних буде дивитись на неї так, ніби ви користувач joe на хості foo.com і зєднуєтесь до localhost, і буде використовувати процедуру аутентифікації, яка була конфігурована для зєднань міє користувачем і хостом. Зауважте, що сервер не буде думати, що зєднання шифроване, тому що воно не є шифрованим між сервером SSH і сервером PostgreSQL. Це не впливає на захист зєднання, оскільки вони знаходяться на одній машині.
Щоб закінчити установку тунелю успішно, ви маєте мати дозвід зєднання через ssh як joe@foo.com, так само, якби ви використовували ssh для створення термінальної сесії.
Ви також можете установити порт:
ssh -L 63333:foo.com:5432 joe@foo.com
але сервер бази даних буде бачити зєднання, ніби воно поступає з інтерфесу foo.com, що не відкритий значенням по замовчуванню listen_addresses = ’localhost’. Це не те, що вам потрібно.
Якщо ви хочете перескочити на сервер бази даних через деякий вхідний хост. Можливою установкою буде:
ssh -L 63333:db.foo.com:5432 joe@shell.foo.com
Зауважте, що так зєднання з shell.foo.com до db.foo.com не буде шифрованим через тунель SSH. SSH пропонує декілька можливостей конфігурації, коли мережа побудована різним шляхом. Перегляньте документацію SSH для деталей.
Підказка: декілька інших додатків можуть забезпечувати такий же захист, з допомогою процедури, яка була описана.