1c 8 postgresql log как чистить

1c 8 postgresql log как чистить

Akina

эта папка прописанна как папка логов в фале конфигов postgresql.conf

Добавлено 20.10.09, 10:31
select * from pg_current_xlog_location()
где это вбивать я в скуле полный ноль.

Добавлено 20.10.09, 10:32
pg_xlog есть там такая папка но она весит гораздо меньше весго 200 метров

negram

тонкое место: каких именно логов?
Беглым взглядом я не нашел где задаётся место хранение логов транзакций. Какими конкретно параметрами это в postgresql.conf задано это место?

ps: Про pg_current_xlog_location() — это я лажанулся. Это немного не то

я не могу разобраться vacuum в скуле что выполняет вроде как тоже базу в порядок приводит, просто я по форумам полазил пришел к выводу ето тоже для профилактити полезно.

Добавлено 20.10.09, 10:48
log_destination = ‘stderr’
logging_collector = on
log_directory = ‘pg_log’
log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log’
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10Mb

вот кусок конфа

negram

Отлично! Все файлы, в именах которых не фигурирует текущая дата можно смело удалять (хотя, с точки зрения администрирования, лучше забекапить). Эти файлы точно уже давно закрыты и никак не повредят работе сервера.

vacuum действительно полезно периодически запускать, однако, к логам это не имеет никакого отношения

Источник

1С и Linux

Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.

понедельник, 20 августа 2018 г.

Бэкап и восстановление базы 1С в бд postgresql, обслуживание базы, чистка логов PostgreSQL

Может возникнуть ситуация при которой файл .dt будет выгружаться средствами 1с,
но при обратной загрузке или загрузке в файловую базу, загружаться не будет (при ошибках в базе).
Файл .dt может считаться бэкапом только при условии проверки загрузки!
Поэтому необходимо организовать бэкап средствами базы данных.
/home/user/test/ — папка с доступом по ftp (test test) (ранее подготовлена)

Подготовка:
$ sudo mkdir /home/user/test/backup
$ sudo chmod -R 777 /home/user/test/backup
$ sudo apt-get -y install pigz

Бэкап с архивированием:
$ sudo su — postgres
$ pg_dump demo | pigz > /home/user/test/backup/demo.sql.gz

Разархивирование с сохранением архива
$ sudo su — postgres
$ unpigz -c /home/user/test/backup/demo.sql.gz > /home/user/test/backup/demo.sql

Создадим базу demotest (если еще не создана)
$ sudo su — postgres
$ createdb —username postgres -T template0 demotest

Восстановим в базу demotest:
$ psql -l
$ unpigz -c /home/user/test/backup/demo.sql.gz > /home/user/test/backup/demo.sql
$ psql demotest > /home/user/test/backup/backup.log
du -h -s /var/lib/postgresql/9.6/main/base >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log
# Записываем информацию в лог с секундами
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start backup demo» >> /home/user/test/backup/backup.log

# Бэкапим базу данных demo и сразу сжимаем
/usr/bin/pg_dump demo | pigz > /home/user/test/backup/$DATA-demo.sql.gz

echo «`date +»%Y-%m-%d_%H-%M-%S»` End backup demo» >> /home/user/test/backup/backup.log

# Записываем информацию в лог с секундами
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuumdb demo» >> /home/user/test/backup/backup.log

vacuumdb —verbose —analyze —full —quiet —dbname=demo

echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuumdb demo» >> /home/user/test/backup/backup.log

echo «——————————————-» >> /home/user/test/backup/backup.log
echo «`date +»%Y-%m-%d_%H-%M-%S»` Size database file: » >> /home/user/test/backup/backup.log
du -h -s /var/lib/postgresql/9.6/main/base >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log

Тестовый запуск:
#$ cd /home/user/test/backup/
$ sudo su — postgres
$ sh /home/user/test/backup/backup-sql.sh

$ sudo su — postgres
$ crontab -e
Добавить в конец (сработает в 2:01):

Смотреть задания:
$ crontab -l

Регулярно восстанавливайте и проверяйте Бекапы средствами 1С!

Смотреть лог:
$ sudo su — postgres
$ nano /home/user/test/backup/backup.log

Если мы хотим тот же скрипт выполнить от root
модернизируем его предварительно отключив от postgres

$ sudo su — postgres
$ crontab -e
Закомментировать:
$ exit

Теперь заменим скрипт на следующий:
$ nano /home/user/test/backup/backup-sql.sh

#!/bin/sh
set -e
# останавливаем сервер 1С
systemctl stop srv1cv83.service
systemctl status srv1cv83.service >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log
# Устанавливаем дату
DATA=`date +»%Y-%m-%d_%H-%M»`
echo «`date +»%Y-%m-%d_%H-%M-%S»` Size database file: » >> /home/user/test/backup/backup.log
du -h -s /var/lib/postgresql/9.6/main/base >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log
# Записываем информацию в лог с секундами
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start backup demo» >> /home/user/test/backup/backup.log

# Бэкапим базу данных demo и сразу сжимаем
cd /home/user/test/backup/
/bin/su postgres -c «/usr/bin/pg_dump demo | pigz > /home/user/test/backup/$DATA-demo.sql.gz»
echo «`date +»%Y-%m-%d_%H-%M-%S»` End backup demo» >> /home/user/test/backup/backup.log
sleep 2
echo «——————————————-» >> /home/user/test/backup/backup.log
# Записываем информацию в лог с секундами
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuumdb demo» >> /home/user/test/backup/backup.log
/bin/su postgres -c «/usr/bin/vacuumdb —verbose —analyze —full —quiet —username postgres —dbname=demo»
echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuumdb demo» >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log
echo «`date +»%Y-%m-%d_%H-%M-%S»` Size database file: » >> /home/user/test/backup/backup.log
du -h -s /var/lib/postgresql/9.6/main/base >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log
# запускаем сервер 1Сsystemctl start srv1cv83.service
systemctl status srv1cv83.service >> /home/user/test/backup/backup.log
echo «——————————————-» >> /home/user/test/backup/backup.log

$ sudo -i
# crontab -e
Добавить в конец (сработает в 2:01):

Источник

pg_log, pg_xlog, pg_clog: с чем их едят

— Я тут типа удалил несколько Гб лог-файлов из каталога pg_xlog, чтобы освободить место на диске. Теперь моя база данных не взлетает.

— Ой-вей! Кхе-кхе… А когда говорите в последний раз резервную копию делали?

Именно в такой форме несколько раз взывали заказчики и пользователи о помощи на нашем IRC-канале. Учитывая легкость повторения этой ошибки, я решил выложить некоторую информацию о системных каталогах PostgreSQL.

Существует три директории в каталоге $PGDATA при его создании, которые имеют вид «pg_*log».

pg_log

$PGDATA/pg_log является по умолчанию местом, где хранятся журналы деятельности. Они включают в себя сообщения об ошибках, записи о запросах, и сообщения во время старта\выключения СУБД. Именно здесь следует искать информацию в случае, если PostgreSQL не запускается. Многие дистрибутивы Linux грешат тем, что могут переместить этот каталог куда-нибудь в /var/log/postgresql.

Вы можете свободно удалять, переименовывать, сжимать и перемещать файлы из pg_log без опаски, при условии что пользователь postgres имеет право на запись в каталог. Если pg_log раздувается за счет больших файлов, то вероятно, вам следует урезать список журналируемых вещей, изменив настройки в postgresql.conf.

pg_xlog

$PGDATA/pg_xlog — это место, где PostgreSQL хранит журнал транзакций. Этот набор бинарных файлов, с названиями вида ‘00000001000000000000008E’, которые содержат образы данных последних транзакций. Эти журналы также используются при бинарной репликации.

Если репликация, архивирование или PITR (Point-In-Time-Recovery) отказывают, этот каталог рискует стать раздутым гигабайтами логов, которые сервер пишет на случай, если архивирование возобновится. Это может стать причиной переполнения дискового пространства.

В отличие от pg_log, вы не можете свободно удалять, перемещать или сжимать файлы в этом каталоге. Удаление файлов из pg_xlog может привести к невосстановимому повреждению базы данных.

Если вы окажетесь в ситуации, когда у вас есть 100 ГБ файлов в pg_xlog и база данных не запускается, и вы уже отключили архивирование/репликацию, и уже попытались очистить дисковое пространство любым другим способом, то, пожалуйста, сделайте два шага:

  1. Переместите файлы из pg_xlog на диск для резервного копирования или общий сетевой диск, но ни в коем случае не удаляйте их.
  2. Скопируйте обратно в pg_xlog только несколько наиболее старых файлов. Этого достаточно, чтобы PostgreSQL стартовал в штатном режиме.

pg_clog

$PGDATA/pg_clog содержит журналы метаданных транзакций. Этот журнал говорит серверу, какие транзакции завершены, а какие нет. Этот каталог мал и нету каких-либо предпосылок для его вздувания. Скорее всего вам никогда не придется его трогать.

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

Стоит отметить, что если вы предпочитаете создавать резервные копии файлов в каталоге $PGDATA, вам следует убедиться, что каталоги pg_clog и pg_xlog также архивируются. В противном случае вы можете обнаружить, что резервная копия бесполезна.

Источник

1c 8 postgresql log как чистить

negram

Akina

эта папка прописанна как папка логов в фале конфигов postgresql.conf

Добавлено 20.10.09, 10:31
select * from pg_current_xlog_location()
где это вбивать я в скуле полный ноль.

Добавлено 20.10.09, 10:32
pg_xlog есть там такая папка но она весит гораздо меньше весго 200 метров

negram

тонкое место: каких именно логов?
Беглым взглядом я не нашел где задаётся место хранение логов транзакций. Какими конкретно параметрами это в postgresql.conf задано это место?

ps: Про pg_current_xlog_location() — это я лажанулся. Это немного не то

я не могу разобраться vacuum в скуле что выполняет вроде как тоже базу в порядок приводит, просто я по форумам полазил пришел к выводу ето тоже для профилактити полезно.

Добавлено 20.10.09, 10:48
log_destination = ‘stderr’
logging_collector = on
log_directory = ‘pg_log’
log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log’
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10Mb

вот кусок конфа

negram

Отлично! Все файлы, в именах которых не фигурирует текущая дата можно смело удалять (хотя, с точки зрения администрирования, лучше забекапить). Эти файлы точно уже давно закрыты и никак не повредят работе сервера.

vacuum действительно полезно периодически запускать, однако, к логам это не имеет никакого отношения

Источник

Читайте также:  Какую модель лазерного принтера выбрать
Поделиться с друзьями
КомпСовет
Adblock
detector
negram