Данная статья не претендует на полноту изложения всех возможностей конфигурирования PostgreSQL, и в сравнительном тестировании я не охватываю всех режимов работы базы данных. Заинтересовавшимся советую изучить книгу по ссылке
Вступление
Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных. PostgreSQL прекрасно использует индексы, хорошо справляется с параллельной нагрузкой, функционал хранимых процедур на высоте, есть хорошие средства администрирования и повышения производительности "из коробки", а сообщество создало полезные утилиты. Но я с удивлением узнал что у многих администраторов 1С мнение о PostgreSQL не на высоте, что он тормоз и едва обгоняет файловый вариант базы, и только MSSQL может спасти положение.
Поизучав вопрос, я нашел множество статей по установке PostgreSQL по шагам для чайников, как по Linux, так и под Windows. Но подавляющее большинство статей описывают установку до "установилось - создадим базу", и совершенно не затрагивают вопрос конфигурирования. В оставшихся конфигурирование упоминается лишь на уровне "прописать такие значения", практически не объясняя зачем.
И если подход "установка в одну кнопку" применим к MSSQL и вообще многим продуктам под Windows, то к PostgreSQL он, к сожалению, не относится. Настройки по умолчанию очень сильно ограничивают его в использовании памяти, чтобы можно было его установить хоть на калькулятор и он там не мешал работе остального ПО. PostgreSQL обязательно нужно конфигурировать под конкретную систему, и только тогда он сможет показать себя на высоте. В особо тяжелых случаях можно тюнинговать настройки PostgreSQL, базы и файловой системы друг под друга, но это касается в большей степени Linux-систем, где больше возможностей по настройке всего и вся.
Следует напомнить, что для 1С не подойдет сборка PostgreSQL от разработчиков СУБД, только собранная из пропатченных 1С исходных текстов. Готовые совместимые сборки предлагает 1С (через диски ИТС и кабинет для имеющих подписку на поддержку) и EterSoft
Тестирование проводилось в среде Windows, но все рекомендации по настройке не являются специфичными для платформы и применимы к любой ОС.
Тестирование и сравнение
При тестировании я не ставил задачи провести испытания во всех режимах и сценариях работы, исключительно черновая проверка успешного конфигурирования.
Для тестирования я использовал следующую конфигурацию:
Host-машина: Win7, Core i5-760 2.8MHz, 4 ядра, 12Гб ОЗУ, VMWare 10
Виртуальная: Win7 x64, 2 ядра, 4Гб ОЗУ, отдельный физический жесткий диск для размещения БД (не SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383
Использовалась БД, dt-выгрузка 780Мб.
После восстановления базы:
размер файла 1CD в файловом варианте - 10Гб,
размер базы PostgreSQL - 8Гб,
размер базы MSSQL - 6.7Гб.
Для теста использовал запрос на выборку договоров контрагентов (21к) с выборкой дополнительных реквизитов из различных регистров, для каждого договора фактически делалась отдельная выборка из регистров. Конфигурацию взял что была под рукой - сильно доработанная на базе Бухгалтерии 3.0.
При тестировании выполнял запрос одним и двумя клиентами по несколько раз до получения стабильных результатов. Первые прогоны игнорировал.
Тестирование одним клиентом:
Выборка на хосте из файлового варианта с размещением базы на SSD - 31с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - 46с
Выборка из MSSQL-базы - первый проход - 25с или 9с (видимо в зависимости от актуальности кэша СУБД) (потребление памяти процессом СУБД составило примерно 1.3Гб)
Выборка из PostgreSQL с настройками по умолчанию - 43с (потребление памяти не превышало 80Мб на подключение)
Выборка из оптимизированного PostgreSQL - 21с (потребление памяти составило 120Мб на подключение)
Тестирование двумя клиентами:
Выборка на хосте из файлового варианта с размещением базы на SSD - по 34с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - по 56с
Выборка из MSSQL-базы - по 50с или 20с (видимо в зависимости от актуальности кэша СУБД)
Выборка из PostgreSQL с настройками по умолчанию - по 60с
Выборка из оптимизированного PostgreSQL - по 40с
Замечания к тестированию:
- После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
- MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
- MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
- Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
- Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но MSSQL субъективно стартовал быстрее.
Конфигурирование PostgreSQL
Есть прекрасная книга на русском языке о конфигурировании и оптимизировании PostgreSQL: Каждому слоноводу имеет смысл поставить себе в закладки эту ссылку. В книге описывается множество техниг оптимизации СУБД, создание отказоустойчивых и распределенных систем. Но сейчас мы рассмотрим то что пригодится всем - конфигурирование использования памяти. PostgreSQL не будет использовать памяти больше чем разрешено настройками, а с настройками по умолчанию PostgreSQL использует минимум памяти. При этом не стоит указывать памяти больше чем доступно к использованию - система начнет использовать файл подкачки со всеми вытекающими печальными последствиями для производительности сервера. Ряд советов по настройке PostgreSQL приведены на диске ИТС.
В Windows конфигурационные файлы PostgreSQL находятся в каталоге установки в каталоге Data:
- postgresql.conf - основной файл с настройками СУБД
- pg_hba.conf - файл с настройками доступа для клиентов. В частности, тут можно указать каким пользователям с каких IP-адресов можно подключаться к определенным БД, и требуется ли проверять пароль пользователя, и если требуется - каким методом.
- pg_ident.conf - файл с преобразованием имен пользователей из системных во внутренние (вряд ли он потребуется большинству пользователей)
Файлы текстовые, можно править блокнотом. Строки, начинающиеся с # считаются комментариями и игнорируются.
Параметры, относящиеся к объму памяти могут дополняться суффиксами kB, MB, GB - килобайты, мегабайты, гигабайты, например, 128MB. Параметры, описывающие интервалы времени, могут дополняться суффиксами ms,s,min,h,d - миллисекунды, секунды, минуты, часы, дни, например, 5min
Если вы забыли пароль к постгрессу - не беда, можно прописать в pg_hba.conf строку:
Host all all 127.0.0.1/32 trust
И подключаться любым пользователем (например, postgres ) к СУБД на локальной машине по адресу 127.0.0.1 без проверки пароля.
Оптимизация использования памяти
Настройки использования памяти располагаются в postgresql.conf
Оптимальные значения параметров зависят от объема свободной оперативной памяти, размера базы и отдельных элементов базы (таблицы и индексы), сложности запросов (в принципе, стоит полагаться что запросы будут достаточно сложными - множественные соединения в запросах это типовой сценарий) и количества одновременных активных клиентов. Кстати, PostgreSQL хранит таблицы и индексы БД в отдельных файлах (<каталог установки PG>\data\base\<идентификатор БД>\), и размеры объектов можно оценить. Так же можно используя входящую в поставку утилиту pgAdmin подключиться к базе, раскрыть "Схемы"-"public", и сформировать отчет по статистике для элемента "Таблицы".
Далее я приведу ориентировочные значения, с которых можно начинать настройку. После первоначальной настройки рекомендуется погонять сервер в рабочих режимах и следить за потреблением памяти. В зависимости от полученных результатов может потребоваться подкорректировать значения параметров.
При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 4Гб ОЗУ. Потребители - ОС Windows, сервер 1С, PostgreSQL и дисковый кэш системы. Я исходил из того что для СУБД можно выделить до 2.5Гб ОЗУ
Значения могут указываться с суффиксами kB, MB, GB (значения в килобайта, мегабайтах или гигабайтах). После изменения значений требуется перезапустить службу PostgreSQL.
shared_buffers - Общий буфер сервера
Размер кэша чтения и записи PostgreSQL, общего для всех подключений. Если данные отсутствуют в кэше, производится чтение с диска (возможно, будут кэшированы ОС)
Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.
Но это не вся память, требуемая для работы, не следует указывать слишком большое значение, иначе не останется памяти как для собственно выполнения запросов клиентов (а чем их больше тем выше потребление памяти), так и для ОС и прочих приложений, например, процесса сервера 1С. Так же сервер полагается и на кэш ОС и старается не держать в своём буфере то что скорее всего закэшировано системой.
В тесте использовалось
shared_buffers = 512MB
work_mem - память для сортировки, агрегации данных и т.д.
Выделяется на каждый запрос, возможно по нескольку раз для сложных запросов. Если памяти недостаточно - PostgreSQL будет использовать временные файлы. Если значение слишком большое - может возникнуть перерасход оперативной памяти и ОС начнет использовать файл подкачки с соответствующим падением быстродействия.
Есть рекомендация при расчетах взять объем доступной памяти за вычетом shared_buffers , и поделить на количество одновременно исполняемых запросов. В случае сложных запросов делитель стоит увеличить, т.е. уменьшить результат. Для рассматриваемого случая из расчета 5 активных пользователей (2.5Гб-0.5Гб (shared_buffers))/5=400Мб. В случае если СУБД сочтет запросы достаточно сложными, или появятся дополнительные пользователи, потребуется значение уменьшить.
Для простых запросов достаточно небольших значений - до пары мегабайт, но для сложных запросов (а это типовой сценарий для 1С) потребуется больше. Рекомендация - для памяти 1-4Гб можно использовать значения 32-128Мб. В тесте использовал
work_mem = 128MB
maintenance_work_mem - память для команд сбора мусора, статистики, создания индексов.
Рекомендуется устанавливать значение 50-75% от размера самой большой таблицы или индекса, но чтобы памяти хватило для работы системы и приложений. Рекомендуется устанавливать значения больше чем work_mem. В тесте использовал
maintenance_work_mem = 192MB
temp_buffers - буфер под временные объекты, в основном для временных таблиц.
Можно установить порядка 16 МБ. В тесте использовал
temp_buffers = 32MB
effective_cache_size - примерный объем дискового кэша файловой системы.
Оптимизатор использует это значение при построении плана запроса, для оценки вероятности нахождения данных в кэше (с быстрым случайным доступом) или на медленном диске. В Windows текущий объем памяти, выделенной под кэш, можно посмотреть в диспетчере задач.
Autovacuum - "сборка мусора"
PostgreSQL как типичный представитель "версионных" СУБД (в противоположность блокирующим) самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций (в случае 1С этим занимается сам сервер 1С). Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. Как следствие, в таблицах накапливаются устаревшие данные - предыдущие версии измененных записей. Для того чтобы СУБД могла высвободившееся место использовать, необходимо произвести "сборку мусора" - определить какие из записей больше не используются. Это можно сделать явно SQL-командой VACUUM , либо дождаться когда таблицу обработает автоматический сборщик мусора - AUTOVACUUM . Так же до определенной версии сборка мусора была связана со сбором статистики (планировщик использует данные о количестве записей в таблицах и распределении значений индексированных полей для построения оптимального плана запроса). С одной стороны, сбор мусора делать необходимо, чтобы таблицы не разрастались и эффективно использовали дисковое пространство. С другой внезапно начавшаяся уборка мусора дает дополнительную нагрузку на диск и таблицы, что приводит к увеличению времени выполнения запросов. Аналогичный эффект создает автоматический сбор статистики (явно его можно запустить командой ANALYZE или совместно со сборкой мусора VACUUM ANALYZE ). И хотя от версии к версии PostgreSQL совершенствует эти механизмы, чтобы минимизировать негативное влияние на производительность (например, в ранних версиях сборка мусора полностью блокировала доступ к таблице, с версии 9.0 работа VACUUM ускорена), тут есть что настроить.
Полностью отключить autovacuum можно параметром:
autovacuum = off
Так же для работы Autovacuum требуется параметр track_counts = on, в противном случае он работать не будет.
По умолчанию оба параметра включены. На самом деле autovacuum полностью отключить нельзя - даже при autovacuum = off иногда (после большого количества транзакций) autovacuum будет запускаться.
Замечание: VACUUM обычно не уменьшает размер файла таблицы, только помечает свободные, доступные для повторного использования области. Если же требуется физически высвободить лишнее место и максимально уменьшить занимаемое пространство на диске, потребуется команда VACUUM FULL . Этот вариант блокирует доступ к таблице на время работы, и обычно не требуется его использовать. Подробнее об использовании команды VACUUM можно прочитать в документации (на английском).
Если Autovacuum полностью не отключать, настроить его влияние на выполнение запросов можно следующими параметрами:
autovacuum_max_workers - максимальное количество параллельно запущенных процессов уборки.
autovacuum_naptime - минимальный интервал, реже которого autovacuum не будет запускаться. По умолчанию 1 минута. Можно увеличить, тогда при частых изменениях данных анализ будет выполняться реже.
autovacuum_vacuum_threshold, - количество измененных или удаленных записей в таблице, необходимых для запуска процесса сборки мусора VACUUM или сбора статистики ANALYZE . По умолчанию по 50.
autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - коэфициент от размера таблицы в записях, добавляемый к autovacuum_vacuum_threshold и autovacuum_analyze_threshold соответственно. Значения по умолчанию 0.2 (т.е. 20% от количества записей) и 0.1 (10%) соответственно.
Рассмотрим пример с таблицей на 10000 записей. Тогда при настройках по умолчанию после 50+10000*0.1=1050 измененных или удаленных записей будет запущен сбор статистики ANALYZE , а после 2050 изменений - сборка мусора VACUUM .
Если увеличить threshold и scale_factor, обслуживающие процессы будут выполняться реже, но небольшие таблицы могут существенно разрастаться. Если БД состоит преимущественно из небольших таблиц, общее увеличение занимаемого дискового пространства может быть существенным, таким образом увеличивать эти значения можно, но с умом.
Таким образом может иметь смысл увеличить интервал autovacuum_naptime, и несколько увеличить threshold и scale_factor. В нагруженных базах может быть альтернативой существенно поднять scale_factor (значение 1 позволит "разбухать" таблицам вдвое) и поставить в планировщик ежесуточное выполнение VACUUM ANALYZE в период минимальной загруженности БД.
default_statistics_target - назначает объем статистики, собираемый командой ANALYZE . Значение по умолчанию 100. Большие значения увеличивают время выполнения команды ANALYZE, но позволяют планировщику строить более эффективные планы выполнения запросов. Встречаются рекомендации по увеличению до 300.
Можно управлять производительностью AUTOVACUUM , делая его более длительным но менее нагружающим систему.
vacuum_cost_page_hit - размер "штрафа" за обработку блока, находящегося в shared_buffers. Связан с необходимостью блокировать доступ к буферу. Значение по умолчанию 1
vacuum_cost_page_miss - размер "штрафа" за обработку блока на диске. Связан с блокировкой буфера, поиском данных в буфере, чтении данных с диска. Значение по умолчанию 10
vacuum_cost_page_dirty - размер "штрафа" за модификацию блока. Связан с необходимостью сбросить модифицированные данные на диск. Значение по умолчанию 20
vacuum_cost_limit - максимальный размер "штрафов", после которых процесс сборки может быть "заморожен" на время vacuum_cost_delay. По умолчанию 200
vacuum_cost_delay - время "заморозки" процесса сборки мусора по достижению vacuum_cost_limit. Значение по умолчанию 0ms
autovacuum_vacuum_cost_delay - время "заморозки" процесса сборки мусора для autovacuum. По умолчанию 20ms. Если установить -1, будет использоваться значение vacuum_cost_delay
autovacuum_vacuum_cost_limit - максимальный размер "штрафа" для autovacuum. Значение по умолчанию -1 - используется значение vacuum_cost_limit
По сообщениям использование vacuum_cost_page_hit = 6 , vacuum_cost_limit = 100 , autovacuum_vacuum_cost_delay = 200ms уменьшает влияние AUTOVACUUM до 80%, но увеличивает время его выполнения втрое.
Настройка записи на диск
При завершении транзакции PostgreSQL начала пишет данные в специальный журнал транзакций WAL (Write-ahead log), а затем уже в базу после того, как данные журнала гарантированно записаны на диск. По умолчанию используется механизм fsync , когда PostgreSQL принудительно сбрасывает данные (журнала) из дискового кэша ОС на диск, и только после успешной записи (журнала) клиенту сообщается об успешном завершении транзакции. Использование журнала транзакций позволяет завершить транзакцию или восстановить базу если во время записи данных произойдет сбой.
В нагруженных системах с большими объемами записи может иметь смысл вынести журнал транзакций на отдельный физический диск (но не на другой раздел этого же диска!). Для этого нужно остановить СУБД, перенести каталог pg_xlog в другое место, а на старом месте создать символическую ссылку, например, утилитой junction. Так же ссылки умеет создавать Far Manager (Alt-F6). При этом надо убедиться что новое место имеет права доступа для пользователя, от которого запускается PostgreSQL (обычно postgres).
При большом количестве операций изменения данных может потребоваться увеличить значение checkpoint_segments, регулирующее объем данных, который может ожидать переноса из журнала в саму базу. По умолчанию используется значение 3. При этом следует учитывать что под журнал выделяется место, расчитываемое по формуле (checkpoint_segments * 2 + 1) * 16 МБ, что при значении 32 уже потребует более 1Гб места на диске.
PostgreSQL после каждого завершения пишущей транзакции сбрасывает данные из файлового кэша ОС на диск. С одной стороны, это гарантирует что данные на диске всегда в актуальном состоянии, с другой при большом количестве транзакций падает производительность. Полностью отключить fsync можно, указав
fsync = off
full_page_writes = off
Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.
Определенной альтернативой может быть использование параметра
synchronous_commit = off
В этом случае после успешного ответа на завершение транзакции до безопасной записи на диск может пройти некоторое время. В случае внезапного отключения база не разрушится, но могут быть потеряны данные последних транзакций.
Если не отключать fsync совсем, можно указать метод синхронизации в параметре. Статья с диска ИТС ссылается на утилиту pg_test_fsync, но в моей сборке PostgreSQL её не оказалось. По утверждению 1С, в их случае в Windows оптимально себя показал метод open_datasync (судя по всему, именно этот метод и используется по умолчанию).
В случае если используется множество мелких пишущих транзакций (в случае 1С этом может быть массовое обновление справочника вне транзакции), может помочь сочетание параметров commit_delay (время задержки завершения транзакции в микросекундах, по умолчанию 0) и commit_siblings (по умолчанию 5). При включении опций завершение транзакции может быть отложено на время commit_delay, если в данный момент исполняется не менее commit_siblings транзакций. В этом случае результат всех завершившихся транзакций будет записан совместно для оптимизации записи на диск.
Прочие параметры, влияющие на производительность
wal_buffers - объем памяти в shared_buffers для ведения транзакционных логов. Рекомендация - при 1-4Гб доступной памяти использовать значения 256КБ-1МБ. Документация утверждает что использование значения "-1" автоматически подбирает значение в зависимости от значения shared_buffers.
random_page_cost - "стоимость" случайного чтения, используется при поиске данных по индексам. По умолчанию 4.0. За единицу берется время последовательного доступа к данным. Для быстрых дисковых массивов, особенно SSD, имеет смысл понижать значение, в этом случае PostgreSQL будет более активно использовать индексы.
В книге по ссылке есть некоторые другие параметры, которые можно настраивать. Так же настоятельно рекомендуется ознакомиться с документацией на PostgreSQL по назначению конкретных параметров.
Параметры из раздела QUERY TUNING, особенно касающиеся запрета планировщику использовать конкретные методы поиска, рекомендуется изменять только в том случае если есть полное понимание что делаете. Очень легко оптимизировать один вид запросов и обрушить производительность всех остальных. Эффективность изменения большинства параметров в этом разделе зависит от данных в БД, запросов к этим данным (т.е. от используемой версии 1С в т.ч.) и версии СУБД.
Заключение
PostgreSQL - мощная СУБД в умелых руках, но требующая тщательной настройки. Его вполне можно использовать совместно с 1С и получить приличное быстродействие, а бесплатность его будет очень приятным бонусом.
Критика и дополнения к этой статье приветствуются.
Полезные ссылки
http://postgresql.leopard.in.ua/ - сайт книги "Работа с PostgreSQL настройка и масштабирование ", наиболее полное и понятное руководство на мой взгляд по конфигурированию и администрированию PostgreSQL
http://etersoft.ru/products/postgre - здесь можно скачать 1С-совместимую сборку PostgreSQL под Windows и различные дистрибутивы и версии Linux. Для тех у кого нет подписки на ИТС или требуется версия под версию Linux, которая не представлена на v8.1c.ru.
http://www.postgresql.org/docs/9.2/static/ - официальная документация на PostgreSQL (на английском)
Статьи с диска ИТС по настройке PostgreSQL
История правок статьи
- 29.01.2015 - опубликована первоначальная версия
- 31.01.2015 - статья дополнена разделом по AUTOVACUUM, добавлена ссылка на оригинальную документацию.
В дальнейшем я намерен провести тестирование работы СУБД в режиме добавления и изменения данные.
- Tutorial
Мне хотелось создать прекрасный объемлющий мануал Getting Start без всякой воды, но включающий основные плюшки для начинающих по системе PostgreSQL в Linux.
PostgreSQL является объектно-реляционной системой управления базами данных (ОРСУБД) на основе POSTGRES, версия 4.2 , разработанной в Университете Калифорнии в Беркли департаменте компьютерных наук.
PostgreSQL является open source потомком оригинального кода Berkeley. Он поддерживает большую часть стандарта SQL и предлагает множество современных функций:
- Cложные запросы
- Управление конкурентным доступом с помощью многоверсионности
- типов данных
- функций
- операторов
- агрегатных функций
- индекс методов
- процедурных языков
Сборка и установка
Как и все любители мейнстрима PostgreSQL мы будем конечно же собирать, а не скачивать готовые пакеты (в репозитариях Debian, например, нет последней версии). Вот лежит множество версий, скачивать конечно же лучше всего последнюю. На момент написания поста это версия 9.2.2Wget http://ftp.postgresql.org/pub/source/v9.2.2/postgresql-9.2.2.tar.gz
tar xzf postgresql-9.2.2.tar.gz
Теперь у нас есть директория с исходниками сей прекрасной базы данных.
По умолчанию файлы базы будут установлены в директорию /usr/local/pgsql, но эту директорию можно изменить задав
Prefix=/path/to/pgsql
перед командой./configure
Перед сборкой можно указать компилятор С++
Export CC=gcc
PostgeSQL может использовать readline библиотеку, если у вас её нет и нет желания её ставить просто укажите опцию
Without-readline
Надеюсь у всех есть Autotools ? Тогда вперед к сборке:
Cd postgresql-9.2.2
./configure --without-readline
sudo make install clean
Все господа! Поздравляю!
Настройка
Нам необходимо указать хранилище данных наших баз данных (кластер) и запустить её.Есть один нюанс - владельцем директории данных и пользователь, который может запускать базу должен быть не root. Это сделано в целях безопасности системы. Поэтому создадим специального пользователя
sudo useradd postgres -p postgres -U -m
И далее все понятно
Sudo chown -R postgres:postgres /usr/local/pgsql
Важный процесс. Мы должны инициализировать кластер баз дынных. Сделать мы должны это от имени пользователя postgres
Initdb -D /usr/local/pgsql/data
Теперь нужно добавить запуск PostgreSQL в автостарт. Для этого существует уже готовый скрипт и лежит он в postgresql-9.2.2/contrib/start-scripts/linux
Этот файл можно открыть и обратить внимание на следующие переменные:
- prefix - это место куда мы ставили PostgreSQL и задавали в./configure
- PGDATA - это то, где хранится кластер баз данных и куда должен иметь доступ наш пользователь postgres
- PGUSER - это тот самый пользователь, от лица которого будет все работать
Sudo cp ./postgresql-9.2.2/contrib/start-scripts/linux /etc/init.d/postgres
sudo update-rc.d postgres defaults
Перезапускам систему, чтобы проверить что наш скрипт работает.
Вводим
/usr/local/pgsql/bin/psql -U postgres
И если появится окно работы с базой, то настройка прошла успешно! Поздравляю!
По умолчанию создается база данных с именем postgres
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
host all all 127.0.0.1/32 trust
host all all::1/128 trust
Первая строка отвечает за локальное соединение, вторая - за соединение про протоколу IPv4, а третья по протоколу IPv6.
Самый последний параметр - это как раз таки метод авторизации. Его и рассмотрим (только основные)
- trust - доступ к базе может получить кто угодно под любым именем, имеющий с ней соединение.
- reject - отклонить безоговорочно! Это подходит для фильтрации определенных IP адресов
- password - требует обязательного ввода пароля. Не подходит для локальных пользователей, только пользователи созданные командой CREATE USER
- ident - позволяет только пользователем зарегистрированным в файле /usr/local/pgsql/data/pg_ident.conf устанавливать соединение с базой.
Утилиты для работы с базой
pg_config
Возвращает информацию о текущей установленной версии PostgreSQL.initdb
Инициализирует новое хранилище данных (кластер баз данных). Кластер представляет собой совокупность баз данных управляемых одним экземпляром севера. initdb должен быть запущен от имени будущего владельца сервера (как указано выше от имени postgres).pg_ctl
Управляет процессом работы сервера PostgreSQL. Позволяет запускать, выполнять перезапуск, останавливать работу сервера, указать лог файл и другое.psql
Клиент для работы с базой дынных. Позволяет выполнять SQL операции.createdb
Создает новую базу данных. По умолчанию, база данных создается от имени пользователя, который запускает команду. Однако, чтобы задать другого - необходимо использовать опцию -O (если у пользователя есть необходимые привилегии для этого). По сути - это обертка SQL команды CREATE DATABASE.dropdb
Удаляет базу данных. Является оберткой SQL команды DROP DATABASE.createuser
Добавляет нового пользователя базы дынных. Является оберткой SQL команды CREATE ROLE.dropuser
Удаляет пользователя базы данных. Является оберткой SQL команды DROP ROLE.createlang
Добавляет новый язык программирования в базу PostgreSQL. Является оберткой SQL команды CREATE LANGUAGE.droplang
Удаляет язык программирования. Является оберткой SQL команды DROP LANGUAGE.pg_dump
Создает бэкап (дамп) базы данных в файл.pg_restore
Восстанавливает бэкап (дамп) базы данных из файла.pg_dumpall
Создает бэкап (дамп) всего кластера в файл.reindexdb
Производит переиндексацию базы данных. Является оберткой SQL команды REINDEX.clusterdb
Производит перекластеризацию таблиц в базе данных. Является оберткой SQL команды CLUSTER.vacuumdb
Сборщик мусора и оптимизатор базы данных. Является оберткой SQL команды VACUUM.Менеджеры по работе с базой
Что касается менеджера по работа с базой, то есть php менеджер - этоДанная система плагинов позволяет модифицировать любую функциональность скрипта по своему усмотрению. Установка плагинов на сайт, обновление плагинов, осуществляется в один клик, непосредственно в панели управления DataLife Engine. Если плагин разработан под новую систему, то пользователям больше не придется читать инструкции по установке, что-то править непосредственно в файлах скрипта, и т.д. Им достаточно будет просто закачать плагин в админпанели и все.
Cистема плагинов построена по технологии виртуальной файловой системы. Вы описываете в плагине, в каком файле и какие действия нужно произвести, на основе этой информации DataLife Engine создаст виртуальные копии этих файлов, со всеми нужными изменениями и модификациями, и будет работать с созданными виртуальными копиями, не затрагивая при этом оригинальных файлов. При этом вы можете описать изменения практически во всех файлах, за исключением ряда базовых, например корневых файлов, но они не несут какого либо функционала, кроме как подключение других файлов. Также может быть изменена функциональность файлов, отвечающих за AJAX функции, для этого они были полностью переписаны для работы через контроллер. Какие это преимущества дает? Во-первых, оригинальные файлы всегда остаются неизменными, поэтому плагины могут быть легко изменены, удалены, обновлены и т.д. Во вторых эта система использует минимально возможную нагрузку на сайты в целом, т.к. виртуальные копии файлов создаются всего один раз, в момент установки или обновления плагинов, после чего DataLife Engine работает с этими измененными файлами как с обычными нативными файлами и нет никаких расходов памяти на точки вызова, хранение и контроль информации о том где и какую функциональность нужно менять и т.д. Нагрузка на сервер увеличится только на ту нагрузку, которую принесет с собой сам плагин, а система управления плагинами не будет вызывать какой либо дополнительной нагрузки. В-третьих, нет никаких проблем непосредственно с обновлением скрипта, скрипт может обновляться, на новые версии, а ваши плагины автоматически применяться к новым версиям. При этом различные плагины могут модифицировать один и тот же файл не вызывая конфликтов, при условии конечно если разные плагины не производят прямо противоположных друг другу действий.
Итак в самом модуле управления плагинами, вы можете либо создать плагин непосредственно в панели управления, либо загрузить готовый плагин. Рассмотрим добавление нового плагина в непосредственно в панели управления:
На первой вкладке вы задаете общие данные о плагине. Его название, его краткое описание. Для удобства различения с другими плагинами, вы можете указать ему иконку, которую он будет использовать в списке плагинов. Также вы задаете версию непосредственно самого плагина, и версию DataLife Engine c которой он совместим.
На следующей вкладке, вы задаете непосредственно действия над файлами, которые необходимо произвести. Вы можете добавить один или несколько файлов над которыми необходимо произвести действия, а также каждому файлу назначить одно или несколько действий, которые необходимо произвести. В файлах вы можете произвести следующие действия:
1. Найти и заменить какой либо код.
2. Найти и добавить выше нужный код.
3. Найти и добавить ниже какой либо код.
4. Полностью заменить содержимое файла на свое.
5. Создать новый виртуальный файл, который не существует в оригинальном DLE.
Вы можете в любое время также добавлять или удалять файлы, менять или удалять действия над файлами. Для удобства восприятия и редактирования, весь код при этом подсвечивается, а поля могут динамически растягиваться.
Тем самым, ситуация, при которой вы раньше вручную правили файлы скрипта, а изменения где то хранили у себя в блокноте, и каждый раз при обновлении скрипта, повторно вносили их в файлы скрипта, с новой версией полностью уходит в прошлое. Вы можете самостоятельно создать свой личный плагин непосредственно в админпанели, описав один раз нужные вам изменения в скрипте, и при обновлении скрипта до новой версии, вам не придется больше об этом заботиться, ваши изменения будут автоматически применяться к новым версиям.
На следующей вкладке вы можете добавить необходимые действия в базе данных MySQL, которые должен производить плагин в тех или иных ситуациях. Вы можете задать список MySQL запросов которые необходимо выполнить при установке плагина, при его обновлении, при его отключении, при его включении, при его удалении. При этом на каждое действие вы можете задать как один, так и список из нескольких запросов к базе данных.
Для существующего плагина, вы можете выполнить следующие действия: Вы можете его отключить, при этом он остается на сайте, но полностью игнорируется скриптом, и все его действия над файлами приостанавливаются. Вы можете его обновить до более новой версии, если таковая есть. Скачать плагин на компьютер для установки его на другой сайт. При этом сам файл скачивается в XML формате, и в данном XML содержится описание всех действий. По сути плагин представляет собой XML файл, который может быть установлен на сайт в админпанели.
Рассмотрим загрузку уже готового плагина на сайт. Вы можете загрузить и установить на свой сайт уже готовый плагин. При нажатии соответствующей кнопки вы можете загрузить либо XML файл с плагином. Либо ZIP архив с плагином. Это позволяет создавать очень сложные плагины, содержащие в себе большое количество других дополнительных файлов, как графических, так и PHP файлов. Чтобы например не описывать все действия непосредственно в самом плагине, можно создать дополнительные файлы и упаковать их в архив, разложив по новым местам. При этом важно знать, что в архиве могут быть только те PHP файлы, которые не входят в состав дистрибутива, а только ваши дополнительные файлы, в случае если будут файлы входящие в дистрибутив, такая загрузка будет заблокирована. Модификацию стандартных файлов, нужно описывать уже в самом плагине. Сам файл с XML плагином должен находится в корне вашего архива.
В случае если вы загружаете архив с плагином, и у DataLife Engine не будет прав на запись находящихся в вашем архиве файлов. Он автоматически запросит FTP доступ для того чтобы загрузить ваш архив. Если доступов не требуется, то все будет скопировано автоматически без них. При этом эти доступы не будут нигде храниться, а будут автоматически удалены после того как будут не нужны.
Новая система управления плагинами, обладает также встроенной системой логирования ошибок в плагине. В случае если какое либо действие над файлами не может быть выполнено, или произойдут какие либо ошибки, вы можете их легко увидеть и исправить. Например, это крайне удобно, если ваш плагин будет не совместим со следующей версией DLE, вы это быстро увидите, и можно легко адаптировать плагин.
