Что такое код pg_copy_from

Содержание

FPublisher

Web-технологии: База знаний

Документация PHP

pg_copy_from

(PHP 4 >= 4.2.0, PHP 5)

pg_copy_from — Insert records into a table from an array

Описание

bool pg_copy_from ( resource $connection , string $table_name , array $rows [, string $delimiter [, string $null_as ]] )

pg_copy_from() inserts records into a table from rows . It issues a COPY FROM SQL command internally to insert records.

Список параметров

PostgreSQL database connection resource.

Name of the table into which to copy the rows .

An array of data to be copied into table_name . Each value in rows becomes a row in table_name . Each value in rows should be a delimited string of the values to insert into each field. Values should be linefeed terminated.

The token that separates values for each field in each element of rows . Default is TAB.

How SQL NULL values are represented in the rows . Default is \N («\\N»).

Возвращаемые значения

Возвращает TRUE в случае успешного завершения или FALSE в случае возникновения ошибки.

Примеры

Пример #1 pg_copy_from() example

= pg_connect ( «dbname=publisher» ) or die( «Could not connect» );

$rows = pg_copy_to ( $db , $table_name );

pg_query ( $db , «DELETE FROM $table_name» );

pg_copy_from ( $db , $table_name , $rows );
?>

Иллюстрированный самоучитель по PostgreSQL

Копирование данных между файлами и таблицами.

  • BINARY. Ключевое слово BINARY означает, что при сохранении и чтении данных командой COPY должен использоваться внутренний двоичный формат PostgreSQL (вместо текстового). При использовании двоичного формата ключевые слова WITH NULL и DELIMITERS неприменимы.
  • таблица. Имя существующей таблицы, в которую (или из которой) копируются данные.
  • FROM. Ключевое слово FROM означает, что команда COPY копирует данные из файла или стандартного ввода в таблицу.
  • ТO. Ключевое слово ТO означает, что команда COPY копирует данные из таблицы в файл или стандартный вывод.
  • WITH OIDS. Необязательный признак копирования идентификатора объекта (OID). Означает, что при выборке или вставке (в зависимости от разновидности команды, COPY FROM или COPY TO) записи сохраняют исходное значение OID.
  • файл. Абсолютный путь к файлу, используемому для ввода пли вывода (например, /usr/local/pgsql/data/employeetable).
  • stdin. Если вместо имени файла указано ключевое слово stdin, данные не загружаются из файла, а передаются клиентским приложением. Если ввод данных осуществляется в клиенте psql, то при вызове команды COPY FROM с ключевым словом stdin вам будет предложено ввести нужный текст.
  • stdout. Направление данных в стандартный вывод. Если вместо имени файла указано ключевое слово stdout, данные не направляются в файл, а передаются непосредственно клиентской программе (например, psql).
  • разделитель. Символ, разделяющий значения полей. При выполнении команды COPY FROM PostgreSQL предполагает, что этот символ разделяет значения полей во входных данных. При выполнении команды COPY TO символ разделяет значения полей в выходных данных. Если разделитель не задан, по умолчанию используется символ табуляции (\t). Разделитель должен состоять из одного символа. Если заданное значение состоит из нескольких символов, PostgreSQL использует только первый символ.
  • строка_null. Последовательность символов, идентифицирующая псевдозначение NULL. По умолчанию используется \N, но вы можете выбрать другое представление, в большей степени соответствующее вашим целям. При копировании данных в таблицу все строки, совпадающие с этой строкой, интерпретируются как NULL, поэтому очень важно, чтобы строковое представление NULL при импортировании и экспортировании данных совпадало и никогда не использовалось в других целях.
  • COPY. Сообщение выдается при успешном выполнении команды COPY.
  • NOTICE: ERROR. Ошибка – процедура копирования завершилась неудачей (с объяснением причины).

Описание

Команда COPY используется для обмена данных между таблицами баз PostgreSQL и файлами в файловой системе. Существует два варианта команды: COPY TO и COPY FROM.

Команда COPY TO направляет все содержимое таблицы в файл или в стандартный вывод (то есть клиенту, подключенному к базе данных). Команда COPY FROM импортирует данные из стандартного файла или из стандартного ввода (то есть от клиента).

Примечание
He путайте команду SQL COPY с командой psql \copy. Команда \copy выполняет операцию COPY FROM stdin или COPY TO stdout, при этом данные хранятся в файле, доступном для psql. Следовательно, права доступа к файлу определяются клиентом, а не серверным процессом postmaster
.

За дополнительной информацией об этой команде обращайтесь к разделу «Добавление данных командами INSERT и COPY» в главе 4.

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

Резервное копирование PostgreSQL

В данной инструкции рассмотрены варианты создания резервных копий и восстановления баз СУБД PostgreSQL.

Все команды, которые приводятся ниже, должны выполняться из командной строки. В Linux — это окно терминала, в Windows — командная строка (cmd.exe) с переходом в папку установки PostgreSQL.

Создание резервных копий

Базовая команда

pg_dump users > /tmp/users.dump

Пользователь и пароль

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

pg_dump -U dmosk -W users > /tmp/users.dump

* где dmosk — имя учетной записи; опция W потребует ввода пароля.

Сжатие данных

Для экономии дискового пространства или более быстрой передачи по сети можно сжать наш архив:

pg_dump users | gzip > users.dump.gz

Скрипт для автоматического резервного копирования

PGPASSWORD=password
export PGPASSWORD
pathB=/backup
dbUser=dbuser
database=db

find $pathB \( -name «*-1[^5].*» -o -name «*-[023]?.*» \) -ctime +61 -delete
pg_dump -U $dbUser $database | gzip > $pathB/pgsql_$(date «+%Y-%m-%d»).sql.gz

* где password — пароль для подключения к postgresql; /backup — каталог, в котором будут храниться резервные копии; dbuser — имя учетной записи для подключения к БУБД.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После при помощи утилиты pg_dump будет выполнено подключение и резервирование базы db. Пароль экспортируется в системную переменную на момент выполнения задачи.

Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:

3 0 * * * /scripts/postgresql_dump.sh

* наш скрипт будет запускаться каждый день в 03:00.

На удаленном сервере

Если сервер баз данных находится на другом сервере, просто добавляем опцию -h:

pg_dump -h 192.168.0.15 users > /tmp/users.dump

* необходимо убедиться, что сама СУБД разрешает удаленное подключение. Подробнее читайте инструкцию Как настроить удаленное подключение к PostgreSQL.

Дамп определенной таблицы

Запускается с опцией -t или —table= :

pg_dump -t students users > /tmp/students.dump

* где students — таблица; users — база данных.

Размещение каждой таблицы в отдельный файл

Также называется резервированием в каталог. Данный способ удобен при больших размерах базы или необходимости восстанавливать отдельные таблицы. Выполняется с ипользованием ключа -d:

pg_dump -d customers > /tmp/folder

* где /tmp/folder — путь до каталога, в котором разместяться файлы дампа для каждой таблицы.

Только схемы

Для резервного копирования без данных (только таблицы и их структуры):

pg_dump —schema-only users > /tmp/users.schema.dump

Только данные

pg_dump —data-only users > /tmp/users.data.dump

Использование pgAdmin

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

Запускаем pgAdmin — подключаемся к серверу — кликаем правой кнопкой мыши по базе, для которой хотим сделать дамп — выбираем Резервная копия:

В открывшемся окне выбираем путь для сохранения данных и настраиваемый формат:

При желании, можно изучить дополнительные параметры для резервного копирования:

После нажимаем Резервная копия — ждем окончания процесса и кликаем по Завершено.

Не текстовые форматы дампа

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

Что такое код pg_copy_from

COPY FROM / COPY TO for node-postgres. Stream from one database to another, and stuff.

Did you know the all powerful PostgreSQL supports streaming binary data directly into and out of a table? This means you can take your favorite CSV or TSV or whatever format file and pipe it directly into an existing PostgreSQL table. You can also take a table and pipe it directly to a file, another database, stdout, even to /dev/null if you’re crazy!

Илон Маск рекомендует:  Что такое код mcal_snooze

What this module gives you is a Readable or Writable stream directly into/out of a table in your database. This mode of interfacing with your table is very fast and very brittle. You are responsible for properly encoding and ordering all your columns. If anything is out of place PostgreSQL will send you back an error. The stream works within a transaction so you wont leave things in a 1/2 borked state, but it’s still good to be aware of.

If you’re not familiar with the feature (I wasn’t either) you can read this for some good helps: http://www.postgresql.org/docs/9.3/static/sql-copy.html

pipe from a table to stdout

pipe from a file to table

Important: Even if pg-copy-streams.from is used as a Writable (via pipe ), you should not listen for the ‘finish’ event and expect that the COPY command has already been correctly acknowledged by the database. Internally, a duplex stream is used to pipe the data into the database connection and the COPY command should be considered complete only when the ‘end’ event is triggered.

This module only works with the pure JavaScript bindings. If you’re using require(‘pg’).native please make sure to use normal require(‘pg’) or require(‘pg.js’) when you’re using copy streams.

Before you set out on this magical piping journey, you really should read this: http://www.postgresql.org/docs/current/static/sql-copy.html, and you might want to take a look at the tests to get an idea of how things work.

Take note of the following warning in the PostgreSQL documentation:

COPY stops operation at the first error. This should not lead to problems in the event of a COPY TO, but the target table will already have received earlier rows in a COPY FROM. These rows will not be visible or accessible, but they still occupy disk space. This might amount to a considerable amount of wasted disk space if the failure happened well into a large copy operation. You might wish to invoke VACUUM to recover the wasted space.

The COPY command is commonly used to move huge sets of data. This can put some pressure on the node.js loop, the amount of CPU or the amount of memory used. There is a bench/ directory in the repository where benchmark scripts are stored. If you have performance issues with pg-copy-stream do not hesitate to write a new benchmark that highlights your issue. Please avoid to commit huge files (PR won’t be accepted) and find other ways to generate huge datasets.

If you have a local instance of postgres on your machine, you can start a benchmark for example with

In order to launch the test suite, you need to have a local instance of postgres running on your machine.

Instead of adding a bunch more code to the already bloated node-postgres I am trying to make the internals extensible and work on adding edge-case features as 3rd party modules. This is one of those.

Please, if you have any issues with this, open an issue.

Better yet, submit a pull request. I love pull requests.

Generally how I work is if you submit a few pull requests and you’re interested I’ll make you a contributor and give you full access to everything.

Since this isn’t a module with tons of installs and dependent modules I hope we can work together on this to iterate faster here and make something really useful.

version 2.x — published YYYY-MM-DD

version 2.2.2 — published 2020-07-22

  • Bugfix copy-to could pause the client connection, preventing re-use

version 2.2.1 — published 2020-07-22

  • Bugfix copy-from was not correctly unpiped from the the connection stream

version 2.2.0 — published 2020-03-21

  • Small refactor in copy-from passing from 3 push to 2 push in every chunk transform loop
  • Add bench/ directory for benchmarks
  • Add benchmark to compare performance of pg-copy-stream wrt psql during copy-from
  • Add benchmark to measure memory usage of copy-from

version 2.1.0 — published 2020-03-19

  • Change README to stop using the pg pool singleton (removed after pg 7.0)
  • Do not register copy-to.pushBufferIfNeeded on the instance itself (avo >

version 2.0.0 — published 2020-03-14

This version’s major change is a modification in the COPY TO implementation. In the previous version, when a chunk was received from the database, it was analyzed and every row contained within that chunk was pushed individually down the stream pipeline. Small rows could lead to a «one chunk» / «thousands of row pushed» performance issue in node. Thanks to @rafatower & CartoDB for the patch. This is considered to be a major change since some people could be relying on the fact that each outgoing chunk is an individual row.

Other changes in this version

  • Use Strict
  • Travis deprecation of old node version (0.12, 0.4). Support LTS 6, 8, 10 and Current 11
  • Update dev dependencies (pg, lodash)
  • Stop using deprecated Buffer constructor
  • Add package-lock.json

The MIT License (MIT)

Copyright (c) 2013 Brian M. Carlson

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the «Software»), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED «AS IS», WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Save PL/pgSQL output from PostgreSQL to a CSV file

What is the easiest way to save PL/pgSQL output from a PostgreSQL database to a CSV file?

I’m using PostgreSQL 8.4 with pgAdmin III and PSQL plugin where I run queries from.

17 Answers 17

Do you want the resulting file on the server, or on the client?

Server side

If you want something easy to re-use or automate, you can use Postgresql’s built in COPY command. e.g.

This approach runs entirely on the remote server — it can’t write to your local PC. It also needs to be run as a Postgres «superuser» (normally called «root») because Postgres can’t stop it doing nasty things with that machine’s local filesystem.

That doesn’t actually mean you have to be connected as a superuser (automating that would be a security risk of a different kind), because you can use the SECURITY DEFINER option to CREATE FUNCTION to make a function which runs as though you were a superuser.

The crucial part is that your function is there to perform additional checks, not just by-pass the security — so you could write a function which exports the exact data you need, or you could write something which can accept various options as long as they meet a strict whitelist. You need to check two things:

  1. Which files should the user be allowed to read/write on disk? This might be a particular directory, for instance, and the filename might have to have a suitable prefix or extension.
  2. Which tables should the user be able to read/write in the database? This would normally be defined by GRANT s in the database, but the function is now running as a superuser, so tables which would normally be «out of bounds» will be fully accessible. You probably don’t want to let someone invoke your function and add rows on the end of your “users” table…
Илон Маск рекомендует:  Что такое код hw_api >insertanchor

I’ve written a blog post expanding on this approach, including some examples of functions that export (or import) files and tables meeting strict conditions.

Client side

The other approach is to do the file handling on the client side, i.e. in your application or script. The Postgres server doesn’t need to know what file you’re copying to, it just spits out the data and the client puts it somewhere.

The underlying syntax for this is the COPY TO STDOUT command, and graphical tools like pgAdmin will wrap it for you in a nice dialog.

The psql command-line client has a special «meta-command» called \copy , which takes all the same options as the «real» COPY , but is run inside the client:

Note that there is no terminating ; , because meta-commands are terminated by newline, unlike SQL commands.

Do not confuse COPY with the psql instruction \copy. \copy invokes COPY FROM STDIN or COPY TO STDOUT, and then fetches/stores the data in a file accessible to the psql client. Thus, file accessibility and access rights depend on the client rather than the server when \copy is used.

Your application programming language may also have support for pushing or fetching the data, but you cannot generally use COPY FROM STDIN / TO STDOUT within a standard SQL statement, because there is no way of connecting the input/output stream. PHP’s PostgreSQL handler (not PDO) includes very basic pg_copy_from and pg_copy_to functions which copy to/from a PHP array, which may not be efficient for large data sets.

Что такое код pg_copy_from

WARNING: nonstandard use of \\ in a string literal
LINE 1: copy log from ‘c:\\log_log1.txt’ NULL AS ‘null’ DELIMITER A.
^
HINT: Use the escape string syntax for backslashes, e.g., E’\\’.
WARNING: nonstandard use of escape in a string literal
LINE 1: . from ‘c:\\log_log1.txt’ NULL AS ‘null’ DELIMITER AS ‘\n’;
^
HINT: Use the escape string syntax for escapes, e.g., E’\r\n’.

ERROR: COPY delimiter cannot be newline or carriage return

ERROR: COPY delimiter cannot be newline or carriage return
SQL state: 22023

WARNING: nonstandard use of \\ in a string literal
LINE 1: copy log from ‘c:\\log_log.txt’
^
HINT: Use the escape string syntax for backslashes, e.g., E’\\’.

Query returned successfully: 50 rows affected, 15 ms execution time.

КА 1.1.107.4 — проблемы с архивацией на СУБД Postgres

Исходные данные :
КА 1.1.107.4 с мелкими доработками
Платформа 8.3.9.2170
СУБД Postgres Pro 9.4

Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.

Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :

pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р’Р?Р?: invalid memory alloc request size 1174829507
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified,attributes, datasize, binarydata) TO stdout;

Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) — результат тот же, pg_dump не может нормально создать архив.

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

Как можно решить проблему?

Cool_Profi

(2) Вроде как у Postgres лимиты не маленькие :

Максимальный размер таблицы — 32 TB

(0)
Покажи скрипт, как бэкап делается.

[проблемы с архивацией]
не путаешь понятия дампа и архива? Проблемы именно с архивацией?

(18) немного не так — если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть.

з.ы. Трабл именно при снятии с «замка» и при сохранении поддержки

(19) [если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть]

А что за ограничение в этом случае срабатывает?

(25) твой же пост:
-*-
Вроде как у Postgres лимиты не маленькие :

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

з.ы. Все-таки я думаю, что в КА 1.1 там не прямая зависимость с размером, а с самим наличием «второй копии» конфигурации, которая конфликтует с «первой» при запихивании ее в БЛОБ платформой — просто глючит в данном случае при попытке архивации баз, а так оно и в других событиях глючит тоже. При накатывании обновлений из Поддержка-Обновить конфигурацию, например.

(42) [pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р’Р?Р?: invalid memory alloc request size 1174829507]

таблицы «config invalid memory alloc request size 1174829507

можно и дальше позаниматься флюдом, но тема закрыта

т.е. дело однозначно в размере cf

BLOB побился явно. Перезагрузить конфу прямой загрузкой.

(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения — в результате cf размером 1,2 Гб.

Архивация проходит без проблем.

(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 — с остальными проблем нет. с КА 2.4 тоже проблем нет.

(79) этому косяку уже много лет.

МимохожийОднако МимохожийОднако

(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg — описанная выше ошибка

При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле — 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.

Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.

Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) — ошибка не исчезла.

Настройка непрерывного архивирования в PostgreSQL 9.6

Для возможности восстановления кластера СУБД PostgreSQL и его баз данных на момент времени необходимо обеспечить наличие:

  • Базовой резервной копии

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

Наиболее простым способом получения базовой резервной копии является утилита pg_basebackup , создающая копию файловой системы всего кластера.

  • Непрерывного архива WAL — журнала транзакций

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

Настройка и выполнение резервного копирования

1 — Включаем архивирование WAL на уровне сервера.

В конфигурационном файле postgresql.conf меняем настройки:

wal_level = replica
archive_mode = on
archive_command = ‘copy «%p» «C:\\PostgreSQLBackup\\%f»‘

— команда, которая будет выполняться при архивировании WAL в момент переключения на его следующий сегмент. Параметр %p автоматически заменяется полным путём к файлу, подлежащему архивации (. \pg_xlog), а %f — именем файла. C:\PostgreSQLBackup\ в данном примере — путь к директории, куда будет производиться архивирование WAL.

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

archive_command = ‘local_backup_script.sh «%p» «%f»‘

В случае, если переключение на следующий сегмент лога и последующее архивирование происходит слишком редко ввиду невысокой интенсивности работы кластера, можно установить значение параметра:

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

(значение по умолчанию — 0, значение 5 указано в качестве примера и технически может быть любым, отличным от 0)

Необходимо обратить внимание, что в случае, если для кластера существует hot_standby -реплика, которая уже является получателем WAL-архивов, значение параметра max_wal_senders , определяющего количество процессов, выполняющих передачу WAL, должно быть не менее 2.

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

host replication postgres ::1/128 md5
host replication postgres 127.0.0.1/32 md5

Выполняем перезапуск службы сервера.

2 — Приступаем к созданию базовых резервных копий.

Интервал создания копии выбирается индивидуально исходя из того, сколько места на диске может быть выделено для хранения файлов WAL, и их размера — необходимо будет хранить все файлы с момента создания последней резервной копии. Копии в примере будут создаваться с помощью утилиты pg_basebackup (подробно об ее использовании и опциях можно прочитать в документации PostgreSQL https://www.postgresql.org/docs/9.6/static/app-pgbasebackup.html). Выполнять резервное копирование можно без остановки работы кластера, однако процесс может привести к повышенной нагрузке на CPU и дисковую подсистему, поэтому лучше делать это в периоды с наименьшей нагрузкой.

Если для кластера включена hot_standby-реплика, лучше использовать именно её для создания резервных копий, чтобы не нагружать master-сервер. Алгоритм выполнения на ведомом сервере будет таким же, но есть несколько настроек, которые необходимо дополнительно выполнить на slave-сервере (описаны в документации к утилите pg_basebackup ).

pg_basebackup -D «D:\Backup» -X fetch — F tar

-D — директория, куда будет скопировано содержимое каталога ..\data. Она должна быть пустой

-F — формат. В данном примере значение tar означает, что содержимое будет добавлено в архив

-X — метод копирования файлов WAL, созданных в процессе создания копии. Значение fetch означает, что файлы будут скопированы в конце процесса.

Выполнение восстановления

Для выполнения восстановления с использованием полной резервной копии и архива WAL необходимо:

1. Остановить сервер баз данных PostgreSQL.

2. Удалить (а лучше — скопировать во временную директорию) содержимое текущего каталога кластера баз данных (. \data).

3. Восстановить (скопировать) файлы необходимой архивной копии, созданной ранее, в текущий каталог данных кластера (…\data). Файлы WAL в директории \ pg_xlog нужно удалить (или заменить на содержимое каталога, скопированного в п.2)

4. Создать конфигурационный фай recovery.conf. В качестве основы можно взять расположенный обычно в директории …\share файл recovery.conf.sample. В нем необходимо выполнить настройку:

restore_command = ‘copy «C:\\PostgreSQLBackup\\%f» «%p»‘

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

После запуска сервера получение архивов и их воспроизведение (с помощью команды выше) по умолчанию будет выполняться до последнего файла WAL. Если нужно выполнить восстановление на конкретную точку, эту точку нужно указать в файле recovery.conf .

Например, для восстановления на момент времени:

recovery_target_time = ‘2020-03-15 12:00:00’

Или для восстановления на именованную точку:

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

5. Запустить сервер баз данных. Он будет запущен в режиме recovery и начнет процесс восстановления. По завершении сервер переименует файл recovery.conf в recovery.done и начнет работать в обычном режиме, в том числе разрешит подключения к нему. Если на время выполнения проверки после восстановления нужно запретить соединения с сервером, это лучше всего сделать в конфигурационном файле pg_hba.conf.

Обеспечение возможности быстрого возврата системы в состояние «до изменений»

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

Один из самых простых возможных сценариев решения такой задачи предполагает использование функции резервного копирования pg_start_backup() , которая вместе с pg_stop_backup() используется в утилите pg_basebackup , описанной выше, с той разницей, что утилита автоматически выполняет физическое копирование кластера в соответствии с параметрами, а ручной вызов возлагает ответственность за создание копии на администратора системы и позволяет физическое копирование «пропустить».

Перед выполнением изменений системы :

1. Убеждаемся, что архивирование WAL включено.

2. Подключаемся к серверу баз данных в контексте любой из баз и выполняем запрос:

select pg_start_backup(‘our_label’, true);

Первым параметром указываем имя метки, которое потом будем использовать при восстановлении. Второй параметр означает, что checkpoint будет осуществлен как можно скорее независимо от настроек параметра checkpoint_completion_target.

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

В случае необходимости отката изменений далее действия не будут отличаться от алгоритма восстановления, описанного выше, за тем исключением, что не нужно удалять каталог кластера и копировать на его место резервную копию — достаточно просто запустить сервер в режиме восстановления, указав в файле recovery.conf созданную метку в качестве recovery_target_name .

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

Утилиты pg_dump и pg_restore: ошибки в работе и кракозябры в отчетах

при помощи pg_dump делаю бинарный бэкап:

все ок, он успешно изготавливается.

далее, прибиваю базу:

все ок. база дохнет.

далее восстанавливаю базу из бинарного бэкапа:

при этом, обратите внимание:
я перенаправляю выхлоп о ходе работы и об ошибках в текстовые файлы.

далее, оказывается, что stdout.txt полностью пустой.

а вот stderr.txt содержит кучу ошибок.

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

я что-то такое слышал, что какие то ошибки могут быть при восстановлении.
но это якобы не критично.

вопросы следущие:
1.
как устранить кракозябры из отчетов программ-утилит?

2.
с чем связанные данные ошибки?
где об этом можно почитать?
как различать «ложные ошибки» от «настоящих» ?

3.
гуи-приложение запускает утилиту, как дочерний процесс,
перехватывая её вывод.

при этом, используется функция winapi ::ReadFile,
которая работает с обычными байтами.

у меня в программе UNICODE.
я ничего не делаю: никаких преобразований.

23.07.2015, 15:23

Ошибки в отчетах и обработках
В чем проблема: 2 разных машины; идентичная база на обоих; на одном обработки проходят нормально.

Кракозябры при работе с облаком тегов
Добрый день. Вот сайт bureaudesign.ru , на главной странице внизу есть модуль «Облако тегов».

Редактор JCE (ошибки кодировки — кракозябры -после русификации)
Добрый день, дорогие друзья! Установил на Joomla 3.0 редактор JCE. Но при Переходе по иконке.

Pg_restore
Знаю что на этом форуме очень задается вопрос и мой будет уже тысячный но все же, не получается.

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

26.01.2020, 15:04 2

База-то работает, но если попытаться выгрузить ее после этого в конфигураторе, получим
42703: ERROR: column «filename» does not exist
LINE тралала

Я получил первую ошибку
pg_restore: [архиватор (БД)] could not execute query: Р?РЁР?Р’Р?Р?: С’РёРї «mchar» С?Р¶Рч С?С?С%РчС?С’Р?С?РчС’
Выполнялась команда: CREATE TYPE mchar;

И это притом, что база создается средствами консоли 1С, а постгря пропатченная для 1С, содержащая в себе библиотеку для поддержки специального типа данных mchar (mvchar, mvachar). Но если вы создаёте БД руками, этот тип данных в БД не прогружается как и его обвязка (CAST’ы и прочее). Поэтому при восстановлении pg_restore выдаёт ошибки — там используется данный тип, а как с ним работать СУБД не знает.

26.01.2020, 15:04

Pg_dump из php
Здравствуйте! Очень хочется запустить pg_dump через exec в php. Делаю так: exec(‘pg_dump -f.

Не работает exclude таблиц в pg_dump при запуске из bash скрипта
PostgreSQL 9.4, Debian 8.1 Так работает, делает sql дамп, исключая все таблицы loolz_* из базы.

Ошибки в работе ОС
Доброго времени суток, Скриншоты выложить не могу, потому что не мой компьютер. Проблема вот в.

Что такое код pg_copy_from

(PHP 4 >= 4.2.0, PHP 5)

pg_copy_from — Insert records into a table from an array

Description bool pg_copy_from ( resource connection, string table_name, array rows [, string delimiter [, string null_as]] )

pg_copy_from() inserts records into a table from rows . It issues a COPY FROM SQL command internally to insert records.

Parameters

PostgreSQL database connection resource.

Name of the table into which to copy the rows .

The token that separates values for each field in each element of rows . Default is TAB .

How SQL NULL values are represented in the rows . Default is \N («\\N»).

Return Values

Returns TRUE on success or FALSE on failure.

Илон Маск рекомендует:  Что такое код hw_changeobject
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL