Wal-g: бэкапы и восстановление субд postgresql

Скрипт изменения владельца базы данных и таблиц postgresql

#!/bin/bash
usage()
{
cat << EOF
usage: $0 options
This script set ownership for all table, sequence and views for a given database
Credit: Based on https://stackoverflow.com/a/2686185/305019 by Alex Soto
        Also merged changes from @sharoonthomas
OPTIONS:
   -h      Show this message
   -d      Database name
   -o      Owner
EOF
}
DB_NAME="web"
NEW_OWNER="postgres"
while getopts "hd:o:" OPTION
do
    case $OPTION in
        h)
            usage
            exit 1
            ;;
        d)
            DB_NAME=$OPTARG
            ;;
        o)
            NEW_OWNER=$OPTARG
            ;;
    esac
done
if ] || ]
then
     usage
     exit 1
fi
for tbl in `psql -qAt -c "select tablename from pg_tables where schemaname = 'public';" ${DB_NAME}` \
           `psql -qAt -c "select sequence_name from information_schema.sequences where sequence_schema = 'public';" ${DB_NAME}` \
           `psql -qAt -c "select table_name from information_schema.views where table_schema = 'public';" ${DB_NAME}` ;
do
    psql -c "alter table \"$tbl\" owner to ${NEW_OWNER}" ${DB_NAME} ;
done

Отправка postgresql в rsyslog > fluentd > kibana

Макет для rsyslog.d

$ModLoad imfile
$InputFileName /var/log/postgresql/postgresql-9.4-main.log
$InputFileTag postgresql-9.4-main.log
$InputFileStateFile postgresql-9.4-main.log.state
$InputFileFacility local6
$InputRunFileMonitor
$template simple, " %msg%"
local6.* @;simple

Архив журналов

Можно создавать архив wal файлов. Такой архив может быть файловым или потоковым.

Файловый архив:

  • сегменты WAL копируются в архив по мере заполнения;
  • механизм работает под управлением сервера;
  • неизбежны задержки попадания данных в архив.

Потоковый архив:

  • в архив постоянно записывается поток журнальных записей;
  • требуются внешние средства;
  • задержки минимальны.

Чтобы запустить файловый архив нужно запустить процесс archiver. Для этого нужно настроить 3 параметра:

  • archive_mode = on;
  • archive_command – команда shell для копирования сегмента WAL в отдельное хранилище (или скрипт);
  • archive_timeout – максимальное время для переключения на новый сегмент WAL (если по окончанию этого времени сегмент wal не заполнится, то переключение всё равно произойдет на новый файл). Даже если wal файл до конца не заполнился он все равно будет весить 16 МБ, поэтому слишком маленьким таймаут лучше не делать.

При заполнении сегмента WAL вызывается команда archive_command если команда завершается со статусом 0, сегмент удаляется если команда возвращает не 0 (в частности, если команда не задана), сегмент остается до тех пор, пока попытка не будет успешной.

При настроенном архивировании, на резервном сервере мы можем восстановиться на любой момент времени.

Для потокового архива используется утилита pg_receivewal. Она подключается по протоколу репликации и может использовать слот репликации. Затем она направляет поток записей WAL в файлы-сегменты. Стартовая позиция – начало текущего сегмента. В отличии от файлового архивирования записи wal передаются постоянно.

При восстановлении базы данных, когда есть данные на определённый момент времени и архив wal файлов. Нужно создать файл $PGDATA/recovery.conf в котором указать, откуда брать wal файлы, и включить сервер.

ЗАПРОСЫ

Удаление данных от удаленных плагинов и данные постов

После удаления ненужных плагинов в таблице  могут остаться записи от них. В этой же таблице находятся мета данные постов.

Создайте запрос для удаления неиспользуемых записей плагинов и постов, которые остались после удаления плагинов или постов.

DELETE FROM wp_postmeta WHERE meta_key = ‘ваш-мета-ключ‘;

Замените ваш-мета-ключ на нужное значение.

Для мультисайта:

DELETE FROM wp_#_postmeta WHERE meta_key = ‘ваш-мета-ключ‘;

Измените # на ID сайта и ваш-мета-ключ на нужное значение.

Удаление спам комментариев

Удалить весь спам из бд можно этим запросом:

DELETE FROM wp_comments WHERE comment_approved = ‘spam‘;

Для мультисайта:

DELETE FROM wp_#_comments WHERE comment_approved = ‘spam‘;

Измените # на ID сайта.

Удаление комментариев, ожидающих проверки

Если у вас много спама, ожидающего проверки, вы можете удалить его этим запросом. Перед удалением проверьте, чтобы не удалились нужные комментарии.

DELETE FROM wp_comments WHERE comment_approved = ‘‘;

Для мультисайта:

DELETE FROM wp_#_comments WHERE comment_approved = ‘‘;

Измените # на ID сайта.

Удаление неиспользуемых тегов

Если у вас есть тег, который не связаны ни с одной статьей, удалите его этим запросом:

DELETE FROM wp_terms wtINNER JOIN wp_term_taxonomy wtt ON wt.term_id = wtt.term_id WHERE wtt.taxonomy = ‘post_tag’ AND wtt.count = 0;

Для мультисайта:

DELETE FROM wp_#_terms wtINNER JOIN wp_term_taxonomy wtt ON wt.term_id = wtt.term_id WHERE wtt.taxonomy = ‘post_tag’ AND wtt.count = 0;

Измените # на ID сайта.

Удаление Trackback и Pingback

Если вы выключили эти функции и хотите удалить их записи из базы данных, используйте эти запросы:

Trackback

DELETE FROM wp_comments WHERE comment_type = ‘trackback‘;

Для мультисайта:

DELETE FROM wp_#_comments WHERE comment_type = ‘trackback‘;

Измените # на ID сайта.

Pingback

DELETE FROM wp_comments WHERE comment_type = ‘pingback‘;

Для мультисайта:

DELETE FROM wp_#_comments WHERE comment_type = ‘pingback‘;

Измените # на ID сайта.

Выключить эти функции в WordPress можно в Настройках — Обсуждения.

Удаление ревизий постов

Сохраненные версии постов хранятся в базе данных. Если у вас большой сайт, большое количество ревизий сильно увеличивает ее размер. Чтобы удалить их все, используйте этот запрос:

DELETE a,b,c FROM wp_posts aLEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id)LEFT JOIN wp_postmeta с ON ( a.ID = c.post_id)LEFT JOIN wp_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id)WHERE a.post_type = ‘revision’AND d.taxonomy != ‘link_category’

Для мультисайта:

DELETE a,b,c FROM wp_#_posts aLEFT JOIN wp_#_term_relationships b ON ( a.ID = b.object_id)LEFT JOIN wp_#_postmeta с ON ( a.ID = c.post_id)LEFT JOIN wp_#_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id)WHERE a.post_type = ‘revision’AND d.taxonomy != ‘link_category’

Замените # на ID сайта.

Удаление шорткодов плагинов и тем

Если вы пользовались каким-то плагином, который вставляет шорткоды, или вы сменили тему, в которой были встроены шорткоды, то теперь шорткоды появятся на сайте в виде текста. Чтобы удалить все записи о шорткодах из базы данных, сделайте этот запрос:

UPDATE wp_post SET post_content = replace(post_content, ‘‘, »);

Для мультисайта:

UPDATE wp_#_post SET post_content = replace(post_content, ‘‘, »);

Измените # на ID сайта.

Удаление постов старше Х дней

Если вы хотите удалить посты старше Х дней, используйте этот запрос:

DELETE FROM ‘wp_posts’WHERE ‘post_type’ = ‘post’AND DATEDIFF(NOW(),’post_date’) > X-дней

Замените X-дней на нужное число дней.

Для мультисайта:

DELETE FROM ‘wp_#_posts’WHERE ‘post_type’ = ‘post’AND DATEDIFF(NOW(),’post_date’) > X-дней

Измените # и X-дней.

Удаление других комментариев

Иногда некоторые плагины добавляют комментарии в таблицу вместо . Если вы хотите очистить эту таблицу, используйте этот запрос:

SELECT FROM wp_commentsmeta WHERE comment_idNOT IN (SELECT comment_idFROM wp_comments);

Если вы хотите очистить таблицу на другом сайте в сети, используйте этот запрос:

SELECT FROM wp_#_commentsmeta WHERE comment_idNOT IN (SELECT comment_idFROM wp_#_comments);

Замените # на ID сайта.

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Восстановление данных в целевую базу данных

После создания целевой базы данных можно воспользоваться командой с параметром , чтобы восстановить данные в целевую базу данных из файла дампа.

При включении параметра все объекты, созданные во время восстановления, будут присвоены пользователю, отмеченному . Дополнительные сведения см. в документации по PostgreSQL.

Примечание

На серверах базы данных Azure для PostgreSQL соединения TLS и SSL включены по умолчанию. Если сервер PostgreSQL требует соединения TLS или SSL, но не содержит их, задайте переменную среды чтобы утилита pg_restore могла подключаться с помощью TLS. Без протокола TLS может появиться ошибка «FATAL: SSL connection is required. Please specify SSL options and retry.» (Критическая ошибка: необходимо соединение SSL. Настройте SSL и повторите попытку) В командной строке Windows выполните команду перед выполнением команды . В Linux или Bash выполните команду перед выполнением команды .

В этом примере необходимо восстановить данные из файла дампа testdb.dump в базу данных mypgsqldb на целевом сервере mydemoserver.postgres.database.azure.com.

Ниже приведен пример использования этого для одиночного сервера:

Ниже приведен пример использования этого для гибкого сервера:

Восстановление данных в целевую базу данных

После создания целевой базы данных можно воспользоваться командой с параметром , чтобы восстановить данные в целевую базу данных из файла дампа.

При включении параметра все объекты, созданные во время восстановления, будут присвоены пользователю, отмеченному . Дополнительные сведения см. в документации по PostgreSQL.

Примечание

На серверах базы данных Azure для PostgreSQL соединения TLS и SSL включены по умолчанию. Если сервер PostgreSQL требует соединения TLS или SSL, но не содержит их, задайте переменную среды чтобы утилита pg_restore могла подключаться с помощью TLS. Без протокола TLS может появиться ошибка «FATAL: SSL connection is required. Please specify SSL options and retry.» (Критическая ошибка: необходимо соединение SSL. Настройте SSL и повторите попытку) В командной строке Windows выполните команду перед выполнением команды . В Linux или Bash выполните команду перед выполнением команды .

В этом примере необходимо восстановить данные из файла дампа testdb.dump в базу данных mypgsqldb на целевом сервере mydemoserver.postgres.database.azure.com.

Ниже приведен пример использования этого для одиночного сервера:

Ниже приведен пример использования этого для гибкого сервера:

Импорт дампа базы данных PostgreSQL в pgAdmin 4

Дамп готов, теперь можно переходить к восстановлению базы данных из этого дампа. Однако перед тем как приступать к импорту, необходимо создать пустую базу данных, в которую собственно и импортировать все данные, как это делается, я подробно рассказывал в отдельном материале.

Все действия по созданию базы данных и восстановлению данных этой базы из архивной копии мы будем делать все на том же компьютере с помощью того же pgAdmin 4, только для этого необходимо подключиться к нужному нам серверу (пункт контекстного меню «Создать сервер» и ввести настройки для подключения, подробнее, как это делается, я рассказывал в той же статье, которая посвящена установке PostgreSQL на Debian).

Импорт сжатого дампа базы данных

Чтобы импортировать базу данных, дамп который был создан в «специальном» формате, необходимо на целевом сервере выбрать базу данных, которую требуется восстановить из дампа (мы ее предварительно создали), в контекстном меню выбрать пункт «Восстановить», затем в пункте «Имя файла», используя кнопку с тремя точками, указать файл дампа, который мы создали чуть ранее с расширением backup.

Больше никаких настроек вводить не требуется, нужный формат выбран по умолчанию, мы можем сразу нажимать кнопку «Восстановить».

Когда появится сообщение «Успешно завершено», процесс будет завершен.

В результате все данные будут восстановлены из дампа, и таким образом мы перенесли базу данных PostgreSQL на новый сервер.

Импорт дампа базы данных в формате SQL

В случае с простым форматом, т.е. с обычными SQL инструкциями, использовать отдельный функционал для восстановления не получится, поэтому мы можем просто выполнить SQL скрипт, который содержится в этом файле.

Для этого открываем Query Tool (запросник) в контексте нужной нам базы данных, затем используя кнопку «Открыть файл» выбираем наш дамп в формате SQL и нажимаем кнопку «Выполнить».

Если инструкция выполнится без ошибок, значит, все хорошо.

В итоге мы перенесли базу данных PostgreSQL с одного сервера, который управляется операционной системой Windows, на другой, который управляется Linux, хотя это, как Вы понимаете, в нашем случае было не так принципиально.

Стоит отметить, что если требуется перенести базу данных, размер которой достаточно большой, например, несколько десятков или сотен гигабайт, то лучше напрямую использовать консольные утилиты pg_dump или pg_dumpall, т.е. без графического интерфейса pgAdmin 4.

Оптимизация процесса миграции

Один из способов миграции существующей базы данных PostgreSQL в службу баз данных Azure для PostgreSQL — это резервное копирование базы данных в источнике и ее восстановление в Azure. Чтобы свести к минимуму время, необходимое для завершения миграции, можно использовать следующие параметры с командами резервного копирования и восстановления.

Примечание

Подробные сведения о синтаксисе см. в статьях о pg_dump и pg_restore.

Для резервного копирования

Создайте резервную копию с использованием параметра , чтобы можно было выполнять восстановление параллельно. Это позволит ускорить процесс. Пример:

Для восстановления

Переместите файл резервной копии на виртуальную машину Azure в том же регионе, в котором находится сервер базы данных Azure для PostgreSQL, на который выполняется миграция. Выполните из этой виртуальной машины, чтобы снизить задержку в сети. Создание виртуальной машины с ускоренной сетью.

Откройте файл дампа, чтобы убедиться в том, что инструкции создания индекса находятся после вставки данных. Если это не так, переместите инструкции создания индекса после вставленных данных. Это должно быть сделано по умолчанию, но рекомендуется дополнительно проверить и подтвердить.

Для параллелизации восстановления необходимо выполнить восстановление с параметрами и (с номером). Указанное вами число — это количество ядер на целевом сервере. Вы также можете попробовать установить вдвое большее количество ядер целевого сервера, чтобы оценить нагрузку.
Ниже приведен пример использования этого для одиночного сервера:

Ниже приведен пример использования этого для гибкого сервера:

Файл дампа также можно отредактировать, добавив в его начале команду , а в конце — команду . Если не включить ее в конце, это может привести к последующей потере данных прежде, чем приложения изменят данные.

Перед восстановлением рассмотрите возможность выполнения следующих действий на целевом сервере Базы данных Azure для PostgreSQL.

Отключите отслеживание производительности запросов. Эти статистические данные не требуются во время миграции. Это можно сделать, установив для параметров , и значение .

Используйте SKU с высоким объемом ресурсов вычисления и памяти, например модель 32 vCore Memory Optimized (32 виртуальных ядра с оптимизацией для операций в памяти), чтобы ускорить миграцию. Вы можете легко вернуться к предпочитаемому SKU после завершения восстановления. Чем выше номер SKU, тем большего параллелизма можно достичь, увеличив значение соответствующего параметра в команде .

Увеличьте число операций ввода-вывода в секунду на целевом сервере — это может улучшить производительность восстановления. Вы можете подготовить больше операций ввода-вывода в секунду, увеличив объем хранилища на сервере

Этот параметр необратим, но стоит принять во внимание, будет ли большее количество операций ввода-вывода в секунду полезным для вашей рабочей нагрузки в будущем.

Не забудьте проверить и протестировать эти команды в тестовой среде, прежде чем использовать их в рабочей среде.

Копирование числовых ячеек из 1С в Excel Промо

Решение проблемы, когда значения скопированных ячеек из табличных документов 1С в Excel воспринимаются последним как текст, т.е. без дополнительного форматирования значений невозможно применить арифметические операции. Поводом для публикации послужило понимание того, что целое предприятие с более сотней активных пользователей уже на протяжении года мучилось с такой, казалось бы на первый взгляд, тривиальной проблемой. Варианты решения, предложенные специалистами helpdesk, обслуживающими данное предприятие, а так же многочисленные обсуждения на форумах, только подтвердили убеждение в необходимости описания способа, который позволил мне качественно и быстро справиться с ситуацией.

15.01.2019 29831 itriot11 27

1С:Предприятие Бухгалтерия переход с редакции 2.0 на 3.0. Практика перевода информационной базы для работы в управляемом приложении. Промо

Из информационного выпуска 1С № 16872 от 08.07.2013г. стало известно об относительно скором необходимом переходе на редакцию 1С:Бухгалтерия 3.0. В данной публикации будут разобраны некоторые особенности перевода нетиповой конфигурации 1С:Бухгалтерия 2.0 на редакцию 3.0, которая работает в режиме «Управляемое приложение».
Публикация будет дополняться по мере подготовки нового материала. Публикация не является «универсальной инструкцией».

Update 3. Права доступа. 14.08.2013
Update 4. Добавлен раздел 0. Дополнен раздел 4. Добавлен раздел 7. Внесены поправки, актуализирована информация. 23.11.2013.

1 стартмани

Утилиты (программы) PosgreSQL:

  • createdb и dropdb – создание и удаление базы данных (соответственно)
  • createuser и dropuser – создание и пользователя (соответственно)
  • pg_ctl – программа предназначенная для решения общих задач управления (запуск, останов, настройка параметров и т.д.)
  • postmaster – многопользовательский серверный модуль PostgreSQL (настройка уровней отладки, портов, каталогов данных)
  • initdb – создание новых кластеров PostgreSQL
  • initlocation – программа для создания каталогов для вторичного хранения баз данных
  • vacuumdb – физическое и аналитическое сопровождение БД
  • pg_dump – архивация и восстановление данных
  • pg_dumpall – резервное копирование всего кластера PostgreSQL
  • pg_restore – восстановление БД из архивов (.tar, .tar.gz)

Примеры создания резервных копий:

Создание бекапа базы mydb, в сжатом виде

pg_dump -h localhost -p 5440 -U someuser -F c -b -v -f mydb.backup mydb

Создание бекапа базы mydb, в виде обычного текстового файла, включая команду для создания БД

pg_dump -h localhost -p 5432 -U someuser -C -F p -b -v -f mydb.backup mydb

Создание бекапа базы mydb, в сжатом виде, с таблицами которые содержат в имени payments

pg_dump -h localhost -p 5432 -U someuser -F c -b -v -t *payments* -f payment_tables.backup mydb

Дамп данных только одной, конкретной таблицы. Если нужно создать резервную копию нескольких таблиц, то имена этих таблиц перечисляются с помощью ключа -t для каждой таблицы.

pg_dump -a -t table_name -f file_name database_name

Создание резервной копии с сжатием в gz

pg_dump -h localhost -O -F p -c -U postgres mydb | gzip -c > mydb.gz

Список наиболее часто используемых опций:

  • -h host — хост, если не указан то используется localhost или значение из переменной окружения PGHOST.
  • -p port — порт, если не указан то используется 5432 или значение из переменной окружения PGPORT.
  • -u — пользователь, если не указан то используется текущий пользователь, также значение можно указать в переменной окружения PGUSER.
  • -a, —data-only — дамп только данных, по-умолчанию сохраняются данные и схема.
  • -b — включать в дамп большие объекты (blog’и).
  • -s, —schema-only — дамп только схемы.
  • -C, —create — добавляет команду для создания БД.
  • -c — добавляет команды для удаления (drop) объектов (таблиц, видов и т.д.).
  • -O — не добавлять команды для установки владельца объекта (таблиц, видов и т.д.).
  • -F, —format {c|t|p} — выходной формат дампа, custom, tar, или plain text.
  • -t, —table=TABLE — указываем определенную таблицу для дампа.
  • -v, —verbose — вывод подробной информации.
  • -D, —attribute-inserts — дамп используя команду INSERT с списком имен свойств.

Бекап всех баз данных используя команду pg_dumpall.

pg_dumpall > all.sql

Восстановление таблиц из резервных копий (бэкапов):

psql — восстановление бекапов, которые хранятся в обычном текстовом файле (plain text);
pg_restore — восстановление сжатых бекапов (tar);

Восстановление всего бекапа с игнорированием ошибок

psql -h localhost -U someuser -d dbname -f mydb.sql

Восстановление всего бекапа с остановкой на первой ошибке

psql -h localhost -U someuser —set ON_ERROR_STOP=on -f mydb.sql

Для восстановления из tar-арихива нам понадобиться сначала создать базу с помощью CREATE DATABASE mydb; (если при создании бекапа не была указана опция -C) и восстановить

pg_restore —dbname=mydb —jobs=4 —verbose mydb.backup

Восстановление резервной копии БД, сжатой gz

gunzip mydb.gz
psql -U postgres -d mydb -f mydb

Инициализация

Ставьте версию от postgrespro. Настройте PG, поменяйте pg_hba.conf так, чтобы пароль не был нужен для подключения с localhost. Определитесь с местонахождением папки с программой и архивами, в моём случае это C:\Backup, но желательно переносить её на тот диск, на котором есть место под архивы. (Заготовка для папки под статьёй)

Это укажет, что home именно там и нигде иначе, и указать cygwin где вообще находится корень, чтобы он мог найти etc/nsswitch.conf.

Если правильно указали ключи и настроили права на C:\Backup\home\.ssh, то ssh ключи должны попасть в эту папку по нажатию C:\Backup\bin\ssh-keygen.exe.

Включите архивацию в файле postgresql.conf

Основные команды PostgreSQL в интерактивном режиме:

  • \connect db_name – подключиться к базе с именем db_name
  • \du – список пользователей
  • \dp (или \z) – список таблиц, представлений, последовательностей, прав доступа к ним
  • \di – индексы
  • \ds – последовательности
  • \dt – список таблиц
  • \dt+ — список всех таблиц с описанием
  • \dt *s* — список всех таблиц, содержащих s в имени
  • \dv – представления
  • \dS – системные таблицы
  • \d+ – описание таблицы
  • \o – пересылка результатов запроса в файл
  • \l – список баз данных
  • \i – читать входящие данные из файла
  • \e – открывает текущее содержимое буфера запроса в редакторе (если иное не указано в окружении переменной EDITOR, то будет использоваться по умолчанию vi)
  • \d “table_name” – описание таблицы
  • \i запуск команды из внешнего файла, например \i /my/directory/my.sql
  • \pset – команда настройки параметров форматирования
  • \echo – выводит сообщение
  • \set – устанавливает значение переменной среды. Без параметров выводит список текущих переменных (\unset – удаляет).
  • \? – справочник psql
  • \help – справочник SQL
  • \q (или Ctrl+D) – выход с программы

Пользователи (роли)

Вместо привычного понятия пользователей, PostgreSQL использует концепцию ролей. Несмотря на определенные отличия, в целом можно определять роли как пользователей базы данных. 

В зависимости от настройки, роль можно рассматривать как пользователя базы данных или как группу пользователей. Роли могут владеть объектами базы данных (например, таблицами) и выдавать другим ролям разрешения на доступ к этим объектам. Также можно предоставить одной роли членство в другой роли (схоже с добавлением пользователя в группу), чтобы одна роль могла использовать привилегии другой роли.

Как отмечалось выше, во время установки была автоматически создана роль postgres. Вы можете работать с СУБД из-под нее. Для этого переключитесь на сессию данного пользователя:

sudo su - postgres

После чего запустите консоль Postgres:

psql

После завершения работы вы сможете выйти из консоли Postgres командой :

postgres=# \q

Так как для каждой созданной роли Postgres предполагает наличие базы данных с таким же именем и по умолчанию подключается именно к ней, имеет смысл создавать новую роль для каждой базы. Кроме того, если имя роли совпадает с именем пользователя, созданного в системе Linux, подключение к БД также упрощается.

Создание новой роли

Создать роль из консоли системы (не psql) можно с помощью команды:

createuser -P --interactive

Ключ позволит сразу задать пароль пользователю, а запустит интерактивный режим для указания дополнительных параметров.

Система поочередно запросит имя новой роли, ее пароль и повтор пароля, а также позволит указать привилегии: сделать ли роль суперпользователем, должны ли быть права на создание баз данных и создание других ролей. Нажимайте y / n и Enter для выбора.

Создать роль из консоли Postgres можно с помощью команды CREATE ROLE.

При использовании этой команды без дополнительных опций пользователь будет создан без каких-либо привилегий, поэтому желательно сразу при создании роли указывать нужные привилегии. Полный список доступных опций можно просмотреть, выполнив:

\h CREATE ROLE

Чтобы создать новую роль выполните:

CREATE ROLE имя_роли WITH LOGIN CREATEDB CREATEROLE;

Далее задайте новому пользователю пароль:

\password имя_роли

Просмотр существующих ролей

Чтобы просмотреть созданных пользователей и их привилегии, перейдите в консоль Postgres:

psql

И выполните команду:

\du

Пример вывода:

                                   List of roles
 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 tmweb     | Create role, Create DB                                     | {}
 tweb      | Create role, Create DB                                     | {}

Нажмите q, чтобы закрыть вывод, и \q, если нужно выйти из консоли Postgres.

dropuser имя_роли

Либо команду в консоли Postgres:

DROP ROLE имя_роли;

Смена пароля пользователя

Для смены пароля одной из ролей подключитесь к Postgres от суперпользователя (postgres или другой роли с такими привилегиями), после чего выполните:

ALTER USER имя_роли WITH PASSWORD 'новый_пароль';

Обратите внимание, что эта операция сохранится в файле  вместе с паролем в открытом виде. Из соображений безопасности рекомендуется удалить соответствующую запись из файла

Как правило, файл размещается в директории . Проверить его расположение можно в терминале системы с помощью: 

grep postgres /etc/passwd | cut -d ':' -f 6

Откройте файл, указав корректный путь к нему:

sudo nano /var/lib/postgresql/.psql_history

Удалите запись с паролем и сохраните изменения.

Параметры и конфигурационные файлы

Узнать расположение конфигурационного файла (как правило, размещается по пути: ) можно с помощью:

SHOW config_file;

Узнать значение какого-либо параметра Postgres:

SHOW параметр;

Получить расширенную информацию о параметре можно из представления : будет выведено не только установленное значение, но также файл, в котором он назначен, максимальные и минимальные значения.

SELECT * FROM pg_settings WHERE name = 'параметр';
 
# Например:
SELECT * FROM pg_settings WHERE name = 'max_connections';

Чтобы вывести информацию в удобном для восприятия формате, можно сменить представление командой \x:

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Все про сервера
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: