reload configuration что это
Sysadminium
База знаний системного администратора
Способы конфигурирования PostgreSQL
Сервер баз данных PostgreSQL имеет очень много параметров с помощью которых его можно настроить под любые нужды. В этой статье мы не будет рассматривать все эти параметры. Здесь мы посмотрим на различные cпособы конфигурирования PostgreSQL.
Если же вы хотите посмотреть список параметров настройки PostgreSQL, то ищите его в справочнике на официальном сайте: на английском и на русском языках.
Конфигурационный файл postgresql.conf
Главный конфигурационный файл для кластера PostgreSQL – это postgresql.conf, в разных системах он может находится в разных местах. Так как мы собирали сервер из исходников и не меняли путь хранения этого файла, то по умолчанию он будет находится в каталоге PGDATA:
Этот конфигурационный файл читается один раз при запуске сервера. Если параметр указан несколько раз, то применяется последний.
Самый точный способ узнать расположение этого файла, посмотреть из терминала psql:
Если вы измените параметры в этом файле, его нужно перечитать. Первый способ – из командной оболочки операционной системы:
Второй способ – из терминала psql:
Но есть некоторые параметры, для изменения которых потребуется перезапуск сервера.
Конфигурация сервера используя ALTER SYSTEM
Для настройки сервера также существует другой файл – postgresql.auto.conf. Он были придуман для настройки сервера из консоли psql. Читается этот файл после postgresql.conf, поэтому параметры из него имеют приоритет. Этот файл всегда находится в каталоге с данными (PGDATA).
Для создания параметров в файле postgresql.auto.conf нужно выполнить подобный запрос:
ALTER SYSTEM SET TO ;
Чтобы удалить параметр используем другой запрос:
ALTER SYSTEM RESET ;
А чтобы удалить все параметры из postgresql.auto.conf выполним:
ALTER SYSTEM RESET ALL;
Чтобы применить изменения нужно перечитать конфигурационные файлы как было описано выше.
Информация о текущих настройках сервера
В PostgreSQL есть 2 представления через которые можно посмотреть текущие настройки сервера:
Например посмотрим значение параметра config_file из представления pg_settings, который покажет конфигурационный файл текущего кластера:
Внесём изменения в параметр work_mem в postgresql.conf и postgresql.auto.conf. Затем посмотрим на все не закомментированные параметры в этих файлах:
Как можно заметить в примере выше, у меня 2 одинаковых параметра work_mem. Колонка applied показывает, может ли быть применён параметр. Первый work_mem не может быть применен, так как второй его перезапишет. При этом реальное значение с которым работает сервер отличается, так как сервер не перечитал конфигурацию.
Теперь посмотрим на реальное, текущее значение этого параметра:
В примере выше мы использовали расширенный режим (в конце запроса \gx), поэтому табличка перевёрнута. Разберём колонки:
Перечитаем конфигурацию сервера:
Как видим, параметр изменился. Он был взят из postgresql.auto.conf и теперь равняется 10 MB.
Установка параметров на лету
Для своего сеанса можно изменить параметры с context=user. Для этого используется конструкция:
Например сделаем это для work_mem:
Как видим, теперь источником является текущая сессия, а параметр равен 64 MB, но если мы перечитаем конфигурацию параметр снова станет равным 10 MB.
Чтобы вернуть все на место нужно просто перезайти в psql. Или выполнить команду RESET :
Тоже самое может проделывать приложение для одной транзакции, и если транзакция откатывается, то и значение параметра откатывается вместе с ней:
Как вы могли заметить посмотреть текущее значение параметра ещё можно так:
Какие параметры требуют перезапуск сервера?
Чтобы это выяснить нужно посмотреть все параметры у которых context = postmaster:
Reload configuration что это
pg_ctl — инициализировать, запустить, остановить или управлять сервером Postgres Pro
Синтаксис
pg_ctl kill имя_сигнала ид_процесса
Описание
pg_ctl — это утилита для начальной инициализации, запуска, остановки, повторного запуска и управления кластером баз данных Postgres Pro ( postgres ). Сервер можно стартовать в ручном режиме, но pg_ctl реализует задачи направления вывода в журнал и отсоединения от терминала и группы процессов, а также предоставляет удобный интерфейс остановки кластера.
Параметры
Указывает флаги, которые будут переданы непосредственно программе postgres ; несколько параметров складываются вместе.
Вывести справку по команде pg_ctl и прервать выполнение.
Параметры, специфичные для Windows
Переменные окружения
Значение по умолчанию для максимального времени ожидания запуска или остановки сервера (в секундах). По умолчанию это время составляет 60 секунд. PGDATA
Размещение каталога хранения данных по умолчанию.
Файлы
Наличие файла в каталоге хранения данных помогает pg_ctl определить, работает ли сервер в настоящий момент. postmaster.opts
Примеры
Запуск сервера
Для запуска сервера:
Для запуска сервера с ожиданием готовности к приёму подключений:
Остановка сервера
Для остановки сервера:
Повторный запуск сервера
Повторный запуск сервера производится аналогично остановке с дальнейшим его запуском, за исключением того, что pg_ctl использует аргументы, которые были переданы при предыдущем запуске кластера. В простейшем случае повторный запуск выглядит так:
Для повторного запуска сервера с ожиданием полной остановки и последующего запуска:
Для повторного запуска на порту 5433 с выключенным fsync после старта:
Вывод состояния сервера
Ниже представлен примерный вывод pg_ctl :
Показанная командная строка будет использоваться в режиме перезапуска.
Systemd за пять минут
Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).
В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.
Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…
Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.
Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.
Все эти юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
Команды на старт/стоп и релоад сервиса
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
Перезагрузка конфигурации Nginx без простоя
Я использую nginx в качестве обратного прокси. Всякий раз, когда я обновляю конфиг для него, используя
Я сталкиваюсь с коротким временем простоя. Как я могу избежать этого?
Запустить service nginx reload или /etc/init.d/nginx reload
Это сделает горячую перезагрузку конфигурации без простоя. Если у вас есть ожидающие запросы, будут существовать длительные процессы nginx, которые будут обрабатывать эти соединения до того, как они умирают, так что это очень изящный способ перезагрузить конфиги.
Иногда вы можете захотеть начать с sudo
Смотрите http://wiki.nginx.org/CommandLine для получения дополнительных параметров командной строки.
Нет, вы не правы, вы не должны сталкиваться с каким-либо простоем из-за описанной вами процедуры. (Nginx может не только перезагрузить конфигурацию на лету без каких-либо простоев, но даже обновить исполняемый файл на лету, без каких-либо простоев.)
Чтобы nginx перечитал файл конфигурации, сигнал HUP должен быть отправлен ведущему процессу. Главный процесс сначала проверяет правильность синтаксиса, затем пытается применить новую конфигурацию, то есть открыть файлы журнала и новые прослушивающие сокеты. Если это не удается, он откатывает изменения и продолжает работать со старой конфигурацией.
Обычно перезагрузка файла конфигурации службы не должна влиять на работающую службу. Однако это зависит от того, как SIGHUP обрабатывается сигнал.
Если конкретная служба испытывает простои во время перезагрузки, это можно обойти, запустив одну и ту же службу на нескольких серверах, предпочтительно с использованием балансировщика нагрузки. В этом случае вы можете вынуть один сервер за раз и перезагрузить / перезапустить его. Затем он может быть повторно добавлен после подтверждения, что все в порядке.