Свободное общество dataved.ru: Резервное копирование и восстановление в PostgreSQL

Восстановление базы данных PostgreSQL из WAL-бэкапа с пропуском части записей / Habr

Вводная

В СУБД PostgreSQL есть такое интересное техническое решение — перед тем как собственно начать что то менять в файлах самой базы данных СУБД пишет уже переведенные во внутренний формат команды в специальный журнал — Write-Ahead Log, а после успешного завершения транзакции делает в этом журнале пометку. Сделано это было для восстановления после сбоев, но в итоге пытливый ум разработчиков дошел до идеи использовать этот журнал для резервирования и репликации. В принципе логично, все ходы в нём записаны, более того можно не просто восстановить данные из бэкапа, но и восстановить состояние базы на определенный момент времени, прервав проигрывание записей WAL-лога в нужный момент. Однако давайте рассмотрим такой сценарий — допустим в понедельник вы сделали базовый бэкап и запустили архивацию WAL-логов, в среду вы выполнили запрос на удаление с ошибочной маской, а обнаружили это только в пятницу, когда менеджер сообщил об исчезновении какой то нужной ему записи. В данной ситуации мы можем только восстановиться из бэкапа до среды, потеряв всю работу менеджеров за четверг и пятницу. Возникает логичный вопрос, а нельзя ли сделать проигрывание WAL-логов с понедельника по пятницу, при этом исключив наш «ошибочный» запрос? В обычной ситуации я ограничился бы вопросом на форум, но у меня было 2 дистрибутива FreeBSD, 10 тарболлов с исходниками PostgreSQL разных версий, 10Гб места на винте, gcc, две относительно незагруженных недели, а также текила, ром, ящик пива и обрывочные воспоминания о синтаксисе языка C. Не то чтобы это был необходимый запас для решения, но раз уж заглянул в исходные коды, то сложно остановиться… Итак, для экспериментов взяты FreeBSD 10 и PostgreSQL 9.2.8 из её портов. Клиент соответствующей версии можно поставить с помощью pkg, в нем ничего менять не нужно. Заранее извиняюсь за возможное капитанство, но текст писался как для новичков, так и для того чтобы быстро всё освежить в голове в случае необходимости, поэтому все команды расписаны подробно.

Установка и базовая настройка сервера

[email protected]> cd /usr/ports/databases/postgresql92-server [email protected]> make fetch [email protected]> make extract 

Скачанный файл с исходниками разворачивается в папку work в директории порта. Я честно говоря так и не понял как пересобирать исходники после изменений, какого то make rebuild вроде нету, make clean в свою очередь просто сносит эту папку со всеми изменениями. Поэтому я просто скопировал папку work в свою домашнюю директорию, вносил изменения там, затем копировал в папку порта и запускал make install. Пока что ничего не меняем, просто ставим постгрес:

[email protected]> make install 

Создаем папки для архивов:

[email protected]> mkdir -p /usr/db_archive/wal [email protected]> mkdir -p /usr/db_archive/data [email protected]> chown -R pgsql:wheel /usr/pg_archive 

Постгрес требует чтобы у директории с данными был доступ только для юзера поэому меняем права:

[email protected]> chmod 0700 /usr/pg_archive/data 

Делаем примитивную настройку. Здесь имеет смысл перейти под постгресовую учетку pgsql чтобы было меньше возни с правами на файлы.

[email protected]> su - pgsql [email protected]> initdb -D /usr/local/pgsql/data 

Раскомментируем и правим параметры архивации WAL-логов в /usr/local/pgsql/data/postgresql.conf: archive_mode=on wal_level = archive archive_command = ‘test! -f /usr/db_archive/wal/%f && cp %p /usr/db_archive/wal/%f’ (пример там рядом в камментах) max_wal_senders = 1 В /usr/local/pgsql/data/pg_hba.conf раскомментируем строку local replication pgsql trust Стартуем сервер

[email protected]> /usr/local/etc/rc.d/postgresql start 

Делаем базовый бэкап

[email protected]> pg_basebackup -D /usr/db_archive/data/ 

Проверяем, в папке /usr/db_archive/data/ должна лежать копия директории данных, в /usr/db_archive/wal/ должны лежать WAL файлы вида примерно 000000010000000000000003 Копируем в папку с бэкапом директории данных конфиг для восстановления

cp /usr/local/share/postgresql/recovery.conf.sample /usr/db_archive/data/recovery.conf 

и в нём раскомменитруем и правим команду восстановления (пример тоже рядом в комментах). restore_command = ‘cp /usr/db_archive/data/%f %p’ Вносим записи:

[email protected]> psql -U pgsql -d postgres 
postgres=# CREATE TABLE z (z_id serial, z_text character(50)); postgres=# INSERT INTO z (z_text) VALUES ('Karlin'); postgres=# INSERT INTO z (z_text) VALUES ('Petrov'); postgres=# INSERT INTO z (z_text) VALUES ('Ivanov'); postgres=# INSERT INTO z (z_text) VALUES ('Kaplan'); postgres=# INSERT INTO z (z_text) VALUES ('Karas'); postgres=# INSERT INTO z (z_text) VALUES ('Bukova'); postgres=# INSERT INTO z (z_text) VALUES ('Sidorova'); postgres=# INSERT INTO z (z_text) VALUES ('Karman'); postgres=# INSERT INTO z (z_text) VALUES ('Nikolaev'); 

Удаляем записи:

postgres=# DELETE FROM z WHERE z_text ILIKE 'Ka%'; 

Изменяем записи, вносим новые, дискотека

postgres=# UPDATE z SET z_text='Petrova' WHERE z_text='Sidorova'; postgres=# INSERT INTO z (z_text) VALUES ('Kruglov'); postgres=# UPDATE z SET z_text='Alexeeva' WHERE z_text='Bukova'; postgres=# INSERT INTO z (z_text) VALUES ('Kvadrat'); 

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

[email protected]> /usr/local/etc/rc.d/postgresql stop [email protected]> exit [email protected]> 

и начинаем думать что же делать.

Идём в исходники

Как вы помните, после make extract я скопировал папку work из директории порта в свою домашнюю папку, и делал изменения в ней. Поэтому переходим туда. Если кто то может подсказать как делать изменения в исходниках в самой папке порта чтобы всё нормально пересобиралось после внесённых в код изменений буду крайне благодарен. Вначале я поставил себе цель найти то место где считываются из файла записи WAL-логов. Файл с кодом относящимся к WAL я нашел с помощью поиска строки «WAL» в содержимом файлов директории work/postgresql-9.2.8/src и здравого смысла, это оказался файл xlog.c Я не умею в трассировку программ на C, поэтому просто в начале каждой функции добавил запись её названия в файл, собрал и запустил. В файле получился такой вот результат:

bool check_wal_buffers(int *newval, void **extra, GucSource source)  void assign_xlog_sync_method(int new_sync_method, void *extra)  Size XLOGShmemSize(void)  static int XLOGChooseNumBuffers(void)  bool check_wal_buffers(int *newval, void **extra, GucSource source)  void XLOGShmemInit(void)  Size XLOGShmemSize(void)  static void ReadControlFile(void)  void StartupXLOG(void)  static void ReadControlFile(void)  static char * str_time(pg_time_t tnow)  static void ValidateXLOGDirectoryStructure(void)  static void readRecoveryCommandFile(void)  static List * readTimeLineHistory(TimeLineID targetTLI)  static bool read_backup_label(XLogRecPtr *checkPointLoc, bool *backupEndRequired,       bool *backupFromStandby)  static XLogRecord * ReadCheckpointRecord(XLogRecPtr RecPtr, int whichChkpt)  static XLogRecord * ReadRecord(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt)  static bool XLogPageRead(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt,     bool randAccess)  static int XLogFileReadAnyTLI(uint32 log, uint32 seg, int emode, int sources)  ... static XLogRecord * ReadRecord(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt)  static bool XLogPageRead(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt,     bool randAccess)  static bool RecordIsValid(XLogRecord *record, XLogRecPtr recptr, int emode)  static bool recoveryStopsHere(XLogRecord *record, bool *includeThis)  static void CheckRecoveryConsistency(void)  static XLogRecord * ReadRecord(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt)  static bool XLogPageRead(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt,     bool randAccess)  ... 

В общем, у меня сложилось впечатление что основное действие происходит в цикле ReadRecord -> XLogPageRead -> RecordIsValid -> RecoveryStopsHere -> CheckRecoveryConsistency. Более близкое знакомтсво с функицей ReadRecord показало что она возвращает запись в двух местах — как return record и как return (XLogRecord *) buffer, вышеуказанным нехитрым способом уточняем что в процессе восстановления с WAL-логов возврат идёт через return (XLogRecord *) buffer. Прекрасно! Пишем результат в файл. Структуру типа XLogRecord можно посмотреть в файле xlog.h и она достаточно лаконична:

typedef struct XLogRecord { pg_crc32xl_crc;/* CRC for this record */ XLogRecPtrxl_prev;/* ptr to previous record in log */ TransactionId xl_xid;/* xact id */ uint32xl_tot_len;/* total len of entire record */ uint32xl_len;/* total len of rmgr data */ uint8xl_info;/* flag bits, see below */ RmgrIdxl_rmid;/* resource manager for this record */ /* ACTUAL LOG DATA FOLLOWS AT END OF STRUCT */ } XLogRecord; 

Отлично, если у нас есть длина, то и используем её для вывода содержимого записи в файл, перед return (XLogRecord *) buffer добавляем:

FILE *pf2 = fopen("/usr/local/pgsql/data/log3.txt", "a"); char *buf_poi = buffer; for (uint32 i=0; i xl_tot_len; i++) {fputc(*buf_poi, pf2); buf_poi++;} fprintf(pf2, "n crc32: %u n xl_xid=%i n", record->xl_crc, record->xl_xid);  fclose(pf2); 

Сносим старый Постгрес, собираем и устаналиваем новый:

[email protected]> cd /usr/ports/databases/postgresql92-server [email protected]> make deinstall 

Напоминаю что мы скопировали директорию work в домашнюю папку и все изменения кода вносили там. Теперь копируем её на место папки work в директории порта.

[email protected]> rm -R /usr/ports/databases/postgresql92-server/work [email protected]> cp -R ~/work /usr/ports/databases/postgresql92-server/work [email protected]> make install 

Удаляем файлы базы данных и копируем на их место базовый бэкап. WAL-файлы сами подтянутся.

[email protected]> su - pgsql [email protected]> /usr/local/etc/rc.d/postgresql stop [email protected]> rm -R /usr/local/pgsql/data [email protected]> cp -R /usr/db_archive/data /usr/local/pgsql/data   [email protected]> /usr/local/etc/rc.d/postgresql start  [email protected]> psql -U pgsql -d postgres 
postgres=# select * from z; postgres=# q 
[email protected]> /usr/local/etc/rc.d/postgresql stop 

Смотрим содержимое файла log3.txt, вначале идем много больших записей, видимо создание служебных таблиц и данных, ближе к концу видим:

Г#{Ы####РT##к###r###R#### ##########0###@#######e###########gNikolaev                                           crc32: 3682278083  l_xid=1002  W# М#####U##к###,### ###`#######Т›ЩЌ%ћ###### crc32: 3423214679  xl_xid=1002  r"Х ####xU##л###5######## ##########0###@########Я## crc32: 2698322546  xl_xid=1003  #Щ%2####ЁU##л###5######## ##########0###@########Я## crc32: 841341184  xl_xid=1003  ь#Wз####аU##л###5######## ##########0###@########Я## crc32: 3881244668  xl_xid=1003  Z7#р#####V##л###5######## ##########0###@########Я## crc32: 4028315482  xl_xid=1003  µЄЈђ####PV##л###,### ###`########ЄЩЌ%ћ###### crc32: 2426645173  xl_xid=1003  Уњ-B####€V##м###y###Y###@ ##########0###@########I##### ####Ђ#(######gPetrova                                            crc32: 1110285523  xl_xid=1004 

Видим что между знакомыми фамилиями Николаев и Петрова есть 4 похожие записи и одна непохожая, под одним номером транзакции. Видимо, это команды удаления, значит в WAL-лог записываются уже команды типа «стереть строку 50 в таблице 64822». В принципе, как и ожидалось. Дописываем проверку, которая при значении xl_xid=1003 вместо записи возвращает NULL. Опять удаляем старый Постгрес, собираем и устанавливаем новый, запускаем восстановление… Удаленные записи на месте! Правда все что должно было произойти после удаления не произошло 🙁 Что ж, с наскока взять не получилось. В общем то понятно, ведь перед проигрыванием записи проходят проверки целостности и всего такого. Значит цель номер 2 — найти где идет «проигрывание» записи. Быстрый поиск использования readRecord в том же файле привел меня к функции void StartupXLOG(void)… И вот тут я отчетливо понял что до сего момента шел не тем путем, потому что почти сразу после второго-третьего появления в этой функции вызова readRecord (они там рядом) сразу идёт во первых шикарный диагностический кусок, а во вторых, сразу после комментария «Now apply the WAL record itself» — команда проигрыша записи RmgrTable[record->xl_rmid].rm_redo(EndRecPtr, record); Изменим этот кусок кода на

if (record->xl_xid==1003) {} else RmgrTable[record->xl_rmid].rm_redo(EndRecPtr, record); 

Опять пересобираем, запускаем, проверяем… Победа! Удаленные записи на месте и изменения, сделанные после удаления тоже на месте!

Ориентируемся на местности

Что ж, это, несомненно, хорошо, но задачу мы решили на крайне ограниченном наборе данных, а вот как найти нужную запись в логах рабочей базы? Вернемся к упомянутому шикарному диагностическому куску в функции StartupXLOG:

#ifdef WAL_DEBUG if (XLOG_DEBUG ||  (rmid == RM_XACT_ID && trace_recovery_messages <= DEBUG2) || (rmid != RM_XACT_ID && trace_recovery_messages xl_rmid].rm_desc(&buf,    record->xl_info,  XLogRecGetData(record)); elog(LOG, "%s", buf.data); pfree(buf.data); } #endif 

Можно просто включить вывод в логи, раскомментировав #define WAL_DEBUG в pg_config_manual.h и добавив wal_debug=on в файл postgresql.conf, но я, по привычке, направил вывод в отдельный файл. Этот кусок, как я понял, выводит описание команды с помощью функции rm_desc (в данном случае RmgrTable является массивом функций?), выглядит оно примерно так:

REDO @ 0/3015500; LSN 0/3015578: prev 0/30154D0; xid 1002; len 82: Heap - insert: rel 1663/12318/16386; tid 0/9  REDO @ 0/3015578; LSN 0/30155A8: prev 0/3015500; xid 1002; len 12: Transaction - commit: 2014-06-06 08:38:27.537874+00   REDO @ 0/30155A8; LSN 0/30155E0: prev 0/3015578; xid 1003; len 21: Heap - delete: rel 1663/12318/16386; tid 0/1  REDO @ 0/30155E0; LSN 0/3015618: prev 0/30155A8; xid 1003; len 21: Heap - delete: rel 1663/12318/16386; tid 0/4  REDO @ 0/3015618; LSN 0/3015650: prev 0/30155E0; xid 1003; len 21: Heap - delete: rel 1663/12318/16386; tid 0/5  REDO @ 0/3015650; LSN 0/3015688: prev 0/3015618; xid 1003; len 21: Heap - delete: rel 1663/12318/16386; tid 0/8  REDO @ 0/3015688; LSN 0/30156B8: prev 0/3015650; xid 1003; len 12: Transaction - commit: 2014-06-06 08:38:27.54153+00   REDO @ 0/30156B8; LSN 0/3015738: prev 0/3015688; xid 1004; len 89: Heap - hot_update: rel 1663/12318/16386; tid 0/7; new 0/10  

Это уже знакомый нам кусок с номером транзакции 1003, и по нему мы можем увидеть что да, это четыре команды на удаление и одно подтверждение транзакции. В командах на удаление мы видим rel — идентификатор таблицы в формате «oid пространства имен/oid базы данных/oid таблицы». Соответствующие циферки можно получить запросами SELECT oid, spcname FROM pg_catalog.pg_tablespace; SELECT oid, datname FROM pg_catalog.pg_database; и, внезапно, SELECT oid, relname FROM pg_catalog.pg_class; Второй ориентир — в описании транзакции есть отметка времени. Ну, тут ничего объяснять не надо, если мы знаем когда этот самый crime был commited, то и соответсвующие записи найдем. Ну и, как альтернативный способ, можно вернуться к просмотру записей в кракозябрах, и ориентироваться по обрывкам текстов которые были переданы как параметры командам INSERT и UPDATE, если мы помним запросы с какими параметрами делались незадолго до или после искомого «ошибочного» запроса. В случае UPDATE, правда, можно найти только те, строки которые использовались как новое значение, если строка использовалась для поиска записей, то в WAL-логах она не встречается. Ну и напоследок могу отметить что в контрибах PostgreSQL 9.3 появилась утилита pg_xlogdump, которая, вроде бы, как раз нацелена на решение задачи предоставления содержимого WAL-логов в человекочитаемом виде. Если вы заинтересованы в каких то фичах то имеет смысл писать разработчикам. Вполне возможно что использование этого метода на архивах рабочей БД будет иметь какие то подводные камни. Например как отработают UPDATE-ы, если мы «пропустим» удаление части записей на базе данных в которой используется частое вакуумирование? Я не проверял. Но в любом случае в случае лучше иметь хоть какую то надежду исправить ошибку, чем совсем никакой.

66

14.6k


66

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

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

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate
. Курс стоящий, все подробности читайте по ссылке. Есть бесплатные курсы.

Данная статья является частью единого цикла статьей про сервер Debian.

Введение

Ранее я рассказывал о том, как установить и настроить postgresql для работы с 1С, а затем как провести анализ производительности базы 1С и по возможности увеличить быстродействие. После успешного выполнения первых двух задач, мы можем приступать к эксплуатации системы. Когда рабочая база 1С уже на сервере, обязательно нужно настроить ее регулярный бэкап. Желательно так же периодически проводить очистку и переиндексацию sql базы. Это увеличит ее быстродействие. Выполнять эти операции лучше всего автоматически, в нерабочее время. Именно этим мы и займемся в этой статье.

Бэкап и восстановление базы 1C в бд postgresql

Способов бэкапа базы данных postgresql много. Я буду использовать самый простой — выгрузка базы данных в обычный текстовый sql скрипт с помощью pg_dump
. Подробно о работе этой утилиты и ее настройках можно прочитать вот тут — https://postgrespro.ru/docs/postgrespro/9.6/app-pgdump. В сети много примеров и готовых скриптов для решения вопроса архивации баз postgresql. Например, есть вот такой скрипт. Когда я его увидел, мне просто стало лень с ним разбираться. Написать простенький свой мне гораздо проще.

Прежде чем делать непосредственно архив 1С базы, нам нужно разрешить подключаться локально к серверу бд без авторизации. Я единственный пользователь сервера, доступа к нему никто больше не имеет, в интернет он не опубликован, поэтому я сознательно иду на этот шаг, чтобы упростить себе работу. Если для вас этот вариант не подходит, то все дальнейшие скрипты вам нужно будет самим изменить, добавив в них авторизацию. Это не сложно, в описании команд все есть. Я буду все команды выполнять локально от пользователя root.

Редактируем в файле /etc/postgresql/9.6/main/pg_hba.conf
строку, приведя ее к такому виду:

local   all             all                                     trust

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

# systemctl restart postgresql

Бэкап базы данных выполняется простой командой:

# pg_dump -U postgres base1c | pigz > /backup/base1c.sql.gz
postgres имя пользователя базы данных
base1c название бд с 1С
pigz архиватор
base1c.sql.gz файл, куда будет сохранена резервная копия

Обращаю внимание на архиватор pigz
. Я его использую, потому что он умеет жать данные, нагружая все ядра процессора, в отличие от gzip. Прирост производительности 2-3 раза. Рекомендую. На debian он ставится из стандартного репозитория:

# apt-get -y install pigz

В centos из epel:

# yum -y install epel-release # yum -y install pigz

Попробуйте вручную в консоли выполнить команду и посмотреть на результат. Вы должны получить заархивированный файл с текстовыми sql командами в открытом виде. Теперь попробуем восстановить базу данных 1С из архива. Тут будут нюансы. Первым делом разархивируем файл:

# unpigz /backup/base1c.sql.gz

Файл будет распакован, а архив удален. Чтобы сохранить архив, можно использовать такую команду:

# unpigz -c /backup/base1c.sql.gz > base1c.sql

Создадим на сервере новую базу данных, в которую будем восстанавливать резервную копию. Перед этим посмотрим список баз данных на сервере:

# psql -U postgres -l

Создаем новую базу данных:

# createdb --username postgres -T template0 base1c-restored

Смотрим, что получилось:

Базу данных создали. Теперь загружаем в нее наш бэкап 1с:

# psql -U postgres base1c-restored < /backup/base1c.sql

Ждем приличное время. Оно будет зависеть от размера базы. После того, как восстановление завершено, можно идти в консоль кластера 1С и добавлять новую базу, указывая в качестве базы postgresql только что созданную базу с загруженным архивом.

Я сначала пошел по другому пути. Создал в консоли пустую базу, загрузил в нее бэкап через консоль postgresql. Архив вроде бы загрузился, но в базу я не мог войти, не проходила авторизация. То есть возникли какие-то проблемы. Когда сделал, как описал выше, без проблем все заработало сразу. Проверил базу, все было в порядке.

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

# cat /root/bin/backup-sql.sh
#!/bin/sh  # Устанавливаем дату DATA=`date +"%Y-%m-%d_%H-%M"`  # Записываем информацию в лог с секундами echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup base1c" >> /var/log/postgresql/service.log  # Бэкапим базу данных base1c и сразу сжимаем /usr/bin/pg_dump -U postgres base1c | pigz > /backup/$DATA-base1c.sql.gz  echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup base1c" >> /var/log/postgresql/service.log  # Удаляем в папке с бэкапами архивы старше 3-х дней /usr/bin/find /backup -type f -mtime +3 -exec rm -rf {} ;

Я указал в названии файла с бэкапом 1с базы использовать текущую дату с точностью до минуты. В лог я пишу информацию с точностью до секунды, чтобы было точно видно, сколько длился бэкап. Просто для справки информация, можно обойтись и без лога совсем. В конце удаляю из папки все архивы старше 3-х дней. Я обычно сервером с бэкапами забираю информацию с целевых хостов. То есть я буду подключаться к sql серверу и забирать с него архивы и уже на сервере бэкапов буду их хранить и ротировать в зависимости от желаемой глубины архива. А здесь я удаляю почти сразу архивы, не храню их, чтобы не занимать место. Если вы будете хранить их долгосрочно на этом же сервере, то просто измените цифру 3 на нужное вам число дней, за которые вы хотите иметь архивную копию своей базы 1С.

Использование программы PostgreSQL Backup

Для бэкапа базы данных постгрес есть удобная и бесплатная для двух баз программа под windows — PostgreSQL Backup. Я ее установил, проверил, сделал бэкап, потом восстановил из бэкапа. Все отлично работает. Из полезных функций:

  • встроенный планировщик
  • автоматическое сжатие бэкапа
  • отправка оповещений на email

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

Обновление статистики и реиндексация в postgresql

С бэкапами разобрались, теперь настроим регламентные операции на уровне субд, чтобы поддерживать быстродействие базы данных. Тут особых комментариев не будет, в интернете очень много информации на тему регламентных заданий для баз 1С. Я просто приведу пример того, как это выглядит в postgresql.

Выполняем очистку и анализ базы данных 1С:

# vacuumdb --full --analyze --username postgres --dbname base1c

Реиндексация таблиц базы данных:

# reindexdb --username postgres --dbname base1c

Завернем все это в скрипт с логированием времени выполнения команд:

# cat /root/bin/service-sql.sh
#!/bin/sh  # Записываем информацию в лог echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuum base1c" >> /var/log/postgresql/service.log # Выполняем очистку и анализ базы данных /usr/bin/vacuumdb --full --analyze --username postgres --dbname base1c echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuum base1c" >> /var/log/postgresql/service.log  sleep 2  echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindex base1c" >> /var/log/postgresql/service.log # Переиндексирвоать базу /usr/bin/reindexdb --username postgres --dbname base1c echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindex base1c" >> /var/log/postgresql/service.log

Сохраняем скрипт и добавляем в планировщик. Хотя я для удобства сделал еще один скрипт, который объединяет бэкап и обслуживание и уже его добавил в cron:

# cat all-sql.sh
#!/bin/sh  /root/bin/backup-sql.sh sleep 2 /root/bin/service-sql.sh

Добавялем в /etc/crontab
:

# Бэкап и обслуживание БД 1 3 * * * root /root/bin/all-sql.sh

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

Описанные выше операции очистки и переиндексации можно делать в ручном режиме в программе под windows — pgAdmin. Рекомендую ее установить на всякий случай. Достаточно удобно и быстро можно посмотреть информацию или выполнить какие-то операции с базой данных посгрес.

Заключение

Вот и все, что я хотел рассказать по поводу бэкапа и обслуживания баз postgresql в связке с 1С. Если у кого есть еще полезная информация, прошу поделиться в комментариях. Возможно с бэкапом есть какие-то нюансы, особенно на больших базах. Но мне негде тестировать, больших рабочих баз более 10 гб у меня нет под рукой, а с теми что были, все отлично работает.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Онлайн курс Основы сетевых технологий

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

  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.

Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Помогла статья? Есть возможность отблагодарить автора

Как восстановить базу данных PostgreSQL из архива

Пришло время поговорить о восстановлении базы данных PostgreSQL
из архива, так как к тому времени, когда Вы с этим столкнетесь, Вы уже должны будите уметь это делать, для того чтобы оперативно восстановить работу базы и соответственно всех приложений, которые работают с ней. Иначе Вы можете получить всякого рода выговоры от руководства за простой процесса производства. Чуть ранее мы с Вами рассмотрели возможность создания резервной копии базы данных PostgreSQL в материале Как создать архив базы PostgreSQL, а теперь пора научиться восстанавливать базы из backup. Если Вы знаете, как создается backup в PostgreSQL, то понимаете, что это делается достаточно просто, поэтому и восстановить базу
также не составит труда. Мы с Вами рассматривали два варианта создания архива, через графический интерфейс pgAdmin и через командную строку, поэтому и восстанавливать мы будем также двумя способами. Только в отличие от создания backup, через батник (для ежедневной автоматической архивации) который нам был нужен практически только для того, чтобы автоматизировать этот процесс и забыть про него, при восстановлении нам такая автоматизация не нужна, так как не каждый день приходится восстанавливать базу данных. Но мы все равно рассмотрим вариант через bat-файл, только для того чтобы Вы знали, как это делается и в случае необходимости оперативно восстановили базу, путем простого запуска батника, так как через графический интерфейс, согласитесь, займет немного больше времени. Итак, приступим, если Вы помните, что при архивации использовалась утилита pg_dump.exe, то при восстановлении используется утилита pg_restore.exe
Примечание!
Как и при создании архива, в качестве примера мы использовали локальный сервер PostgreSQL 8.4, на Windows 7, так и сегодня мы будем использовать именно данные версии СУБД и ОС.

Восстанавливаем базу через pgAdmin

Открываем pgAdmin, подключаемся к серверу, выбираем правой кнопкой мыши базу, и щелкаем «Восстановить
» Затем открывается окно восстановления базы, где Вы можете задать параметры восстановления, в частности выбрать архив, я здесь поставил галочку «Очистить перед восстановлением
» так как если ее не ставить достаточно часто база восстанавливается с ошибкой (но все равно восстанавливается), и жмем «ОК» После Вам останется, дождаться восстановления и нажать кнопку «Завершить
»

Восстанавливаем базу с помощью батника

Для этого открываем блокнот (удобней Notepad++) и вставляем в него следующие команды (символ ^ это перенос строки):

 "C:/Program Files/PostgreSQL/8.4/binpg_restore.exe" ^   --host localhost --port 5432 --username postgres ^   --dbname test --clean --verbose "C:temptest_backup.backup"    

Где, не трудно догадаться  первая строка это запуск утилиты, вторая это подключение к серверу, третья выбор базы для восстановления, параметры восстановления и соответственно из чего это все восстанавливать. Только одно замечание, при восстановлении проверьте путь к архиву, т.е. необходимо выбрать актуальный архив на момент восстановления, чтобы не получилось ситуации, когда Вы якобы восстановили базу, только скажем прошлогодней версии, а пользователи смотрят и удивляются:) Нам останется только сохранить этот текстовый документ с расширением .bat и проверить его работу. Как видите, восстанавливать базу не так страшно как кажется. На сегодня все, в следующих статьях мы будем рассматривать, как можно создавать и восстанавливать backup базы данных, но только уже на СУБД MSSql 2008.

Ссылка на основную публикацию
Похожие публикации