Переустановка postgresql на windows с сохранением баз

Как переустановить postgresql с сохранением существующих баз данных?

Здравствуйте, нужно полностью переустановить postgresql, но с сохранением существующих баз данных

Дамп не подходит, т.к база не работает в принципе, в логах написано, что ошибка в файле конфигурации, но туда никто даже не заходил
OS: UBUNTU

• Вопрос задан более двух лет назад
• 711 просмотров

postgresql@10-main.service: Can’t open PID file /var/run/postgresql/10-main.pid (yet?) after start: No such file or directory

Вот такая ошибка вылетает

проверить что есть такая дирекория существует и есть права на запись у посгреса /var/run/postgresql/

показать полный лог посгреса после рестарта постгреса

вообще, в логе постгреса только это

FATAL: configuration file «/etc/postgresql/10/main/postgresql.conf» contains errors

Права на запись есть

0) Сработает для «простой» инсталляции без стендбай серверов или мультимастера.
1) Сделать холодный бэкап базы (скопировать файлы в PGDATA).
2) Потом Попробовать запустить PG на дефолтном конфиге.
3) Если получится — снимать дамп (на всякий случай).
4) Если не работает, попробовать во временной папке создать новый кластер через initdb, проверить что с ним работает.

Если ошибка в конфиге есть надежда что это действительно ошибка в конфиге, а не критические повреждения файлов. Тут проще всего исправить конфиг. Если же умерли файлы БД, то это долго и печально восстанавливать.

ЕМНИП при старте PG проверяет файл конфигурации и явно говорит строку с ошибочным параметром.

Источник

Как переустановить postgresql с сохранением баз

pg_upgrade -b oldbindir [ -B newbindir ] -d oldconfigdir -D newconfigdir [ option . ]

Description

pg_upgrade (formerly called pg_migrator ) allows data stored in PostgreSQL data files to be upgraded to a later PostgreSQL major version without the data dump/restore typically required for major version upgrades, e.g., from 9.5.8 to 9.6.4 or from 10.7 to 11.2. It is not required for minor version upgrades, e.g., from 9.6.2 to 9.6.3 or from 10.1 to 10.2.

Major PostgreSQL releases regularly add new features that often change the layout of the system tables, but the internal data storage format rarely changes. pg_upgrade uses this fact to perform rapid upgrades by creating new system tables and simply reusing the old user data files. If a future major release ever changes the data storage format in a way that makes the old data format unreadable, pg_upgrade will not be usable for such upgrades. (The community will attempt to avoid such situations.)

pg_upgrade does its best to make sure the old and new clusters are binary-compatible, e.g., by checking for compatible compile-time settings, including 32/64-bit binaries. It is important that any external modules are also binary compatible, though this cannot be checked by pg_upgrade .

pg_upgrade supports upgrades from 9.2.X and later to the current major release of PostgreSQL , including snapshot and beta releases.

Options

pg_upgrade accepts the following command-line arguments:

the old PostgreSQL executable directory; environment variable PGBINOLD

-B bindir
—new-bindir= bindir

the new PostgreSQL executable directory; default is the directory where pg_upgrade resides; environment variable PGBINNEW

check clusters only, don’t change any data

-d configdir
—old-datadir= configdir

the old database cluster configuration directory; environment variable PGDATAOLD

-D configdir
—new-datadir= configdir

the new database cluster configuration directory; environment variable PGDATANEW

number of simultaneous processes or threads to use

use hard links instead of copying files to the new cluster

By default, pg_upgrade will wait for all files of the upgraded cluster to be written safely to disk. This option causes pg_upgrade to return without waiting, which is faster, but means that a subsequent operating system crash can leave the data directory corrupt. Generally, this option is useful for testing but should not be used on a production installation.

-o options
—old-options options

options to be passed directly to the old postgres command; multiple option invocations are appended

-O options
—new-options options

options to be passed directly to the new postgres command; multiple option invocations are appended

the old cluster port number; environment variable PGPORTOLD

the new cluster port number; environment variable PGPORTNEW

retain SQL and log files even after successful completion

directory to use for postmaster sockets during upgrade; default is current working directory; environment variable PGSOCKETDIR

-U username
—username= username

cluster’s install user name; environment variable PGUSER

enable verbose internal logging

display version information, then exit

Use efficient file cloning (also known as “ reflinks ” on some systems) instead of copying files to the new cluster. This can result in near-instantaneous copying of the data files, giving the speed advantages of -k / —link while leaving the old cluster untouched.

File cloning is only supported on some operating systems and file systems. If it is selected but not supported, the pg_upgrade run will error. At present, it is supported on Linux (kernel 4.5 or later) with Btrfs and XFS (on file systems created with reflink support), and on macOS with APFS.

show help, then exit

Usage

These are the steps to perform an upgrade with pg_upgrade :

Optionally move the old cluster

If you are using a version-specific installation directory, e.g., /opt/PostgreSQL/15 , you do not need to move the old cluster. The graphical installers all use version-specific installation directories.

If your installation directory is not version-specific, e.g., /usr/local/pgsql , it is necessary to move the current PostgreSQL install directory so it does not interfere with the new PostgreSQL installation. Once the current PostgreSQL server is shut down, it is safe to rename the PostgreSQL installation directory; assuming the old directory is /usr/local/pgsql , you can do:

to rename the directory.

For source installs, build the new version

Build the new PostgreSQL source with configure flags that are compatible with the old cluster. pg_upgrade will check pg_controldata to make sure all settings are compatible before starting the upgrade.

Install the new PostgreSQL binaries

Install the new server’s binaries and support files. pg_upgrade is included in a default installation.

For source installs, if you wish to install the new server in a custom location, use the prefix variable:

Initialize the new PostgreSQL cluster

Initialize the new cluster using initdb . Again, use compatible initdb flags that match the old cluster. Many prebuilt installers do this step automatically. There is no need to start the new cluster.

Install extension shared object files

Many extensions and custom modules, whether from contrib or another source, use shared object files (or DLLs), e.g., pgcrypto.so . If the old cluster used these, shared object files matching the new server binary must be installed in the new cluster, usually via operating system commands. Do not load the schema definitions, e.g., CREATE EXTENSION pgcrypto , because these will be duplicated from the old cluster. If extension updates are available, pg_upgrade will report this and create a script that can be run later to update them.

Copy custom full-text search files

Copy any custom full text search files (dictionary, synonym, thesaurus, stop words) from the old to the new cluster.

Adjust authentication

pg_upgrade will connect to the old and new servers several times, so you might want to set authentication to peer in pg_hba.conf or use a

Stop both servers

Make sure both database servers are stopped using, on Unix, e.g.:

or on Windows, using the proper service names:

Streaming replication and log-shipping standby servers can remain running until a later step.

Prepare for standby server upgrades

If you are upgrading standby servers using methods outlined in section Step 11, verify that the old standby servers are caught up by running pg_controldata against the old primary and standby clusters. Verify that the “ Latest checkpoint location ” values match in all clusters. (There will be a mismatch if old standby servers were shut down before the old primary or if the old standby servers are still running.) Also, make sure wal_level is not set to minimal in the postgresql.conf file on the new primary cluster.

Run pg_upgrade

Always run the pg_upgrade binary of the new server, not the old one. pg_upgrade requires the specification of the old and new cluster’s data and executable ( bin ) directories. You can also specify user and port values, and whether you want the data files linked or cloned instead of the default copy behavior.

If you use link mode, the upgrade will be much faster (no file copying) and use less disk space, but you will not be able to access your old cluster once you start the new cluster after the upgrade. Link mode also requires that the old and new cluster data directories be in the same file system. (Tablespaces and pg_wal can be on different file systems.) Clone mode provides the same speed and disk space advantages but does not cause the old cluster to be unusable once the new cluster is started. Clone mode also requires that the old and new data directories be in the same file system. This mode is only available on certain operating systems and file systems.

The —jobs option allows multiple CPU cores to be used for copying/linking of files and to dump and restore database schemas in parallel; a good place to start is the maximum of the number of CPU cores and tablespaces. This option can dramatically reduce the time to upgrade a multi-database server running on a multiprocessor machine.

For Windows users, you must be logged into an administrative account, and then start a shell as the postgres user and set the proper path:

and then run pg_upgrade with quoted directories, e.g.:

Once started, pg_upgrade will verify the two clusters are compatible and then do the upgrade. You can use pg_upgrade —check to perform only the checks, even if the old server is still running. pg_upgrade —check will also outline any manual adjustments you will need to make after the upgrade. If you are going to be using link or clone mode, you should use the option —link or —clone with —check to enable mode-specific checks. pg_upgrade requires write permission in the current directory.

Obviously, no one should be accessing the clusters during the upgrade. pg_upgrade defaults to running servers on port 50432 to avoid unintended client connections. You can use the same port number for both clusters when doing an upgrade because the old and new clusters will not be running at the same time. However, when checking an old running server, the old and new port numbers must be different.

If an error occurs while restoring the database schema, pg_upgrade will exit and you will have to revert to the old cluster as outlined in Step 17 below. To try pg_upgrade again, you will need to modify the old cluster so the pg_upgrade schema restore succeeds. If the problem is a contrib module, you might need to uninstall the contrib module from the old cluster and install it in the new cluster after the upgrade, assuming the module is not being used to store user data.

Upgrade streaming replication and log-shipping standby servers

If you used link mode and have Streaming Replication (see Section 27.2.5) or Log-Shipping (see Section 27.2) standby servers, you can follow these steps to quickly upgrade them. You will not be running pg_upgrade on the standby servers, but rather rsync on the primary. Do not start any servers yet.

If you did not use link mode, do not have or do not want to use rsync , or want an easier solution, skip the instructions in this section and simply recreate the standby servers once pg_upgrade completes and the new primary is running.

Install the new PostgreSQL binaries on standby servers

Make sure the new binaries and support files are installed on all standby servers.

Make sure the new standby data directories do not exist

Make sure the new standby data directories do not exist or are empty. If initdb was run, delete the standby servers’ new data directories.

Install extension shared object files

Install the same extension shared object files on the new standbys that you installed in the new primary cluster.

Stop standby servers

If the standby servers are still running, stop them now using the above instructions.

Save configuration files

Save any configuration files from the old standbys’ configuration directories you need to keep, e.g., postgresql.conf (and any files included by it), postgresql.auto.conf , pg_hba.conf , because these will be overwritten or removed in the next step.

Run rsync

When using link mode, standby servers can be quickly upgraded using rsync . To accomplish this, from a directory on the primary server that is above the old and new database cluster directories, run this on the primary for each standby server:

where old_cluster and new_cluster are relative to the current directory on the primary, and remote_dir is above the old and new cluster directories on the standby. The directory structure under the specified directories on the primary and standbys must match. Consult the rsync manual page for details on specifying the remote directory, e.g.,

You can verify what the command will do using rsync ‘s —dry-run option. While rsync must be run on the primary for at least one standby, it is possible to run rsync on an upgraded standby to upgrade other standbys, as long as the upgraded standby has not been started.

What this does is to record the links created by pg_upgrade ‘s link mode that connect files in the old and new clusters on the primary server. It then finds matching files in the standby’s old cluster and creates links for them in the standby’s new cluster. Files that were not linked on the primary are copied from the primary to the standby. (They are usually small.) This provides rapid standby upgrades. Unfortunately, rsync needlessly copies files associated with temporary and unlogged tables because these files don’t normally exist on standby servers.

If you have tablespaces, you will need to run a similar rsync command for each tablespace directory, e.g.:

If you have relocated pg_wal outside the data directories, rsync must be run on those directories too.

Configure streaming replication and log-shipping standby servers

Configure the servers for log shipping. (You do not need to run pg_backup_start() and pg_backup_stop() or take a file system backup as the standbys are still synchronized with the primary.) Replication slots are not copied and must be recreated.

Restore pg_hba.conf

If you modified pg_hba.conf , restore its original settings. It might also be necessary to adjust other configuration files in the new cluster to match the old cluster, e.g., postgresql.conf (and any files included by it), postgresql.auto.conf .

Start the new server

The new server can now be safely started, and then any rsync ‘ed standby servers.

Post-upgrade processing

If any post-upgrade processing is required, pg_upgrade will issue warnings as it completes. It will also generate script files that must be run by the administrator. The script files will connect to each database that needs post-upgrade processing. Each script should be run using:

The scripts can be run in any order and can be deleted once they have been run.

Caution

In general it is unsafe to access tables referenced in rebuild scripts until the rebuild scripts have run to completion; doing so could yield incorrect results or poor performance. Tables not referenced in rebuild scripts can be accessed immediately.

Statistics

Because optimizer statistics are not transferred by pg_upgrade , you will be instructed to run a command to regenerate that information at the end of the upgrade. You might need to set connection parameters to match your new cluster.

Delete old cluster

Once you are satisfied with the upgrade, you can delete the old cluster’s data directories by running the script mentioned when pg_upgrade completes. (Automatic deletion is not possible if you have user-defined tablespaces inside the old data directory.) You can also delete the old installation directories (e.g., bin , share ).

Reverting to old cluster

If, after running pg_upgrade , you wish to revert to the old cluster, there are several options:

If the —check option was used, the old cluster was unmodified; it can be restarted.

If the —link option was not used, the old cluster was unmodified; it can be restarted.

If the —link option was used, the data files might be shared between the old and new cluster:

If pg_upgrade aborted before linking started, the old cluster was unmodified; it can be restarted.

If you did not start the new cluster, the old cluster was unmodified except that, when linking started, a .old suffix was appended to $PGDATA/global/pg_control . To reuse the old cluster, remove the .old suffix from $PGDATA/global/pg_control ; you can then restart the old cluster.

If you did start the new cluster, it has written to shared files and it is unsafe to use the old cluster. The old cluster will need to be restored from backup in this case.

Notes

pg_upgrade creates various working files, such as schema dumps, stored within pg_upgrade_output.d in the directory of the new cluster. Each run creates a new subdirectory named with a timestamp formatted as per ISO 8601 ( %Y%m%dT%H%M%S ), where all its generated files are stored. pg_upgrade_output.d and its contained files will be removed automatically if pg_upgrade completes successfully; but in the event of trouble, the files there may provide useful debugging information.

pg_upgrade launches short-lived postmasters in the old and new data directories. Temporary Unix socket files for communication with these postmasters are, by default, made in the current working directory. In some situations the path name for the current directory might be too long to be a valid socket name. In that case you can use the -s option to put the socket files in some directory with a shorter path name. For security, be sure that that directory is not readable or writable by any other users. (This is not supported on Windows.)

All failure, rebuild, and reindex cases will be reported by pg_upgrade if they affect your installation; post-upgrade scripts to rebuild tables and indexes will be generated automatically. If you are trying to automate the upgrade of many clusters, you should find that clusters with identical database schemas require the same post-upgrade steps for all cluster upgrades; this is because the post-upgrade steps are based on the database schemas, and not user data.

For deployment testing, create a schema-only copy of the old cluster, insert dummy data, and upgrade that.

pg_upgrade does not support upgrading of databases containing table columns using these reg* OID-referencing system data types:

regcollation

regconfig

regdictionary

regnamespace

regoper

regoperator

regproc

regprocedure

( regclass , regrole , and regtype can be upgraded.)

If you want to use link mode and you do not want your old cluster to be modified when the new cluster is started, consider using the clone mode. If that is not available, make a copy of the old cluster and upgrade that in link mode. To make a valid copy of the old cluster, use rsync to create a dirty copy of the old cluster while the server is running, then shut down the old server and run rsync —checksum again to update the copy with any changes to make it consistent. ( —checksum is necessary because rsync only has file modification-time granularity of one second.) You might want to exclude some files, e.g., postmaster.pid , as documented in Section 26.3.3. If your file system supports file system snapshots or copy-on-write file copies, you can use that to make a backup of the old cluster and tablespaces, though the snapshot and copies must be created simultaneously or while the database server is down.

See Also

Submit correction

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.

Copyright © 1996-2022 The PostgreSQL Global Development Group

Источник

Обычно можно сделать так.
1.

On Май 1st, 2010 admin says:

1. 07-12-2016, 01:33 PM

   
   

   #1

   

   
   Member
   

   ---

   Я сделал копии своих старых баз(нужно было переустановить windows)
   А именно: 1)папку data (из c:postgresql)
   2)папку из каталога %appdata%HoldemManagerDatabase

   Теперь воткнул их обратно(после переустановки windows)
   НО при входе в ХМ у меня открывается просто чистая база,старых рук нет.
   Как быть?

   ---

2. 07-12-2016, 01:58 PM

   
   

   #2

   

   
   Holdem Manager Support
   

   

   ---

   
   

   Во-первых, надо было делать Backup (средствами самого ХМ2).
   Во-вторых: можно узнать подробности вот этого «воткнул обратно» по отношению postgres-части базы данных?
   Как именно делал?

   ---

3. 07-12-2016, 02:21 PM

   
   

   #3

   

   
   Member
   

   ---

   
   

   В c:postgresql поменял все файлы в папке Data на старую весом 40 гиг
   Более подробно Data переименовал в Data2 чтобы подменить ее на
   старую Data весом 40 гиг в c:postgresql

   Скопировал папку старую HoldemManager(вес тоже около 30-40гб) в %appdata%HoldemManagerDatabase с заменой всех файлов

   При включении Holdem Manager пришлось вручную запускать сервис postgresql-8.4 — PostgreSQL Server 8.4 тк не коннектилоcь.
   Действительно нужно было как ты написал сделать я что то тупанул.

   ---

4. 07-12-2016, 02:31 PM

   
   

   #4

   

   
   Holdem Manager Support
   

   

   ---

   
   

   Originally Posted by mishkanaservere
   

   В c:postgresql поменял все файлы в папке Data на старую весом 40 гиг
   Более подробно Data переименовал в Data2 чтобы подменить ее на
   старую Data весом 40 гиг в c:postgresql

   Примерно этого я и опасался.
   Так делать было нельзя!

   Единственным способом задействовать старую папку Data может быть только вот что:
   в ходе установки PostgreSQL (естественно, той же версии) на одном из этапов надо указать инсталлятору местоположение этой самой «старой Data» как location of database cluster
   Только в этом случае содержимое старой Data воспримется как существующая(ие) базы данных.

   ---

5. 07-12-2016, 02:33 PM

   
   

   #5

   

   
   Holdem Manager Support
   

   

   ---

   
   

   А теперь еще вопрос:
   одинаковое ли значение имеет системная переменная %appdata%
   на старой Винде и на новой?

   ---

6. 07-12-2016, 03:17 PM

   
   

   #6

   

   
   Member
   

   ---

   
   

   была win7 стала win 8
   путь такой же если я правильно понял вопрос

   ---

7. 07-12-2016, 03:32 PM

   
   

   #7

   

   
   Holdem Manager Support
   

   

   ---

   
   

   Если такой же — тогда с ЭТОЙ частью БД проблемы быть не должно. Просто положить ее где была.
   А вот если путь отличается — значит, надо новый путь прописать в одной из таблиц базы данных (settings), делается из PGadmin.

   ---

8. 07-12-2016, 03:33 PM

   
   

   #8

   

   
   Holdem Manager Support
   

   

   ---

   
   

   И, кстати: а почему Вин8, а не сразу Вин10? Она же лучше 8, и пока бесплатно.

   ---

9. 07-12-2016, 03:41 PM

   
   

   #9

   

   
   Member
   

   ---

   
   

   Всё просто,была только win 8 под рукой =)
   Думал над 10,но меня всем устраивает 8

   ---

	Я
KosmoSTAR 24.11.09 — 23:50	Привет!! Работала база нормально. Админ переустановил винду и теперь для меня остались лишь файлы PostgreSQL в папке прграм файлс… Подскажите как мне правильно установить PostgreSQL и восстановить старую базу??? Помогите, очень нужно. Спасибо заранее!
IamAlexy 1 — 24.11.09 — 23:54	писец подкрался незаметно.. горячий привет админу.. зы: добро пожаловать в мир бесплатного софта
KosmoSTAR 2 — 24.11.09 — 23:56	(1) Как можно восстановить??
IamAlexy 3 — 24.11.09 — 23:57	(2) я как то пару лет назад пытался — не нашел решения. хотя может плохо пытался
Aleksey_3 4 — 24.11.09 — 23:57	Правильно выгрузить  в dt. А после переустановки загрузить обратно из dt
IamAlexy 5 — 24.11.09 — 23:58	(4) гы гы гы ага щас.. база была на диске ДЕ. операционка на диске ЦЕ операционку переставили тупо.. базы остались там где они были.. бекапов понятное дело — двухнедельной давности..
KosmoSTAR 6 — 24.11.09 — 23:59	(4) Как я это сделаю если база только в файлах??? (5)Ты прав, только винда и сервер СКЛ были на диске с!
IamAlexy 7 — 25.11.09 — 00:01	(6) да без разницы.. прикол в том что подключение файлов базы к другому серверу в постгри более чем неочевидно… я вот действительно несмог найти. для меня проще и безопаснее оказалось пользовать триал от ентерпрайза 2005го… пока лицензию не купили
KosmoSTAR 8 — 25.11.09 — 00:05	(7)Задача не решается??
IamAlexy 9 — 25.11.09 — 00:07	(8) я не решил. + на мисте пару веток уже на эту тему проскакивало.. вот понимаю что должно быть решение.. ну не может не быть в СУБД такого уровня отсутствие такой возможности… но не нашел нифига
KosmoSTAR 10 — 25.11.09 — 00:09	Блин… это очень очень плохо(((
Варвар 11 — 25.11.09 — 00:14	восстанавливается вооще очень просто pg_restore вот тока для этого бекапы должны быть. А базы то где хранились? остались?
Варвар 12 — 25.11.09 — 00:16	да, и на sql.ru ты уже спросил? Что там ответили?
KosmoSTAR 13 — 25.11.09 — 00:22	(11) бэкапов нет… только две недели… а это много.
KosmoSTAR 14 — 25.11.09 — 00:33	Стоп.. перефразирую задачу.. оказывается винду не сносисили, проблема в том что при запуске службы PostgreSQL она запускалась и тут же остановаливалась, написано что ей делать нечего и из за этого не получается подключится к серверу. Сто можно сделать в этом случаи?
IamAlexy 15 — 25.11.09 — 00:34	(14) почитать логи постгри. выявить проблему посредством манов/факов/скульру/гугль найти решение проблемы. может вся проблема в одной строчке конфигфайла.. и все лечится за 3 минуты.. а может 0дмин взял и перекрыл сетевой доступ приложению постгри ?
KosmoSTAR 16 — 25.11.09 — 00:36	(15) брендмауэр и антивирусы, сетевые экраны выключены.. Подскажи как поглядеть лог?? я в этих делах туго разбираюсь…
IamAlexy 17 — 25.11.09 — 00:38	(16) поройся гденить тут: http://postgresql.ru.net/node/213920

HOWTO: Обновление версии PostgreSQL

Мы рекомендуем выполнять процедуру обновления сервера квалифицированным сотрудником используя официальную инструкцию: https://postgrespro.ru/docs/postgresql/11/upgrading.

Обновление в пределах основной версии (например, с 11.1 на 11.3) осуществляется без каких либо дополнительных действий.

Существует несколько способов обновления. Здесь будет рассмотрен способ с полным дампом перед восстановлением и затем восстановлением из дампа после обновления. Также процедура будет описана для ОС Debian и ее производных (Ubuntu и т.д.). Для других дистрибутивов и ОС процедура практически точно такая же, но используются другие утилиты, специфичные для конкретного дистрибутива или ОС.

Предполагается, что установка PostgreSql осуществлялась по этой инструкции и в систему добавлены репозитории PostgreSql, предоставляющие доступ к различным версиям PostgreSql и расширениям, а также установка производилась по этой инструкции и был установлен пакет postgresql-9.6, а не метапакет postgresql. Если у вас установлен метапакет, то обновление должно произойти автоматически при обновлении метапакета, но не факт, что оно пройдет корректно. Мы рекомендуем использовать конкретные пакеты (с указанием версии) вместо метапакетов.

Если в процессе обновления не удается успешно выполнить какую-то команду, пожалуйста, не продолжайте выполнять остальные пункты, пока не решите проблему. К сожалению, мы не являемся специалистами по всем проблемам PostgreSql, а также остальных служб, поэтому не всегда сможем дать квалифицированный ответ.

1. Остановите работу всех систем, использующих базу данных. Остановите работу php-fpm или apache2, а также временно отключите задачи в cron и остановите работающие модули usm_*.

2. Проверьте, какие версии PostgreSql и PostGis у вас установлены на данный момент:

3. Обновите текущие версии, а также, если у вас установлен PostGis 2.4, установите PostGis 2.5 и обновите это расширение в базе данных, затем убедитесь, что расширение в базе данных обновлено:

4. Установите новую версию PostgreSql и PostGis не удаляя старой(!).

5. Выполните запасное резервное копирование всех баз данных сервера (в данном случае будет использоваться последняя версия утилиты pg_dumpall, но база данных будет использоваться все еще прежняя):

6. Посмотрите, как выглядят ваши кластеры. Сейчас вы должны видеть две версии, обе в состоянии онлайн:

Вы должны увидеть таблицу:

7. При установке PostgreSql, установщик автоматически создает кластер с конфигурацией и базами данных, чтобы можно было начинать работу с базой данных сразу же. В случае обновления это лишняя операция и кластер для 11 версии нужно удалить. Мы будем его создавать на основе кластера версии 9.6:

8. Остановите работу службы

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

10. Запустите процедуру создания нового кластера на основе старого (обновление версии кластера):

11. Запустите службу:

12. Посмотрите, как выглядят ваши кластеры:

Теперь вы должны увидеть вот такую таблицу, в которой версия 9.6 находится в состоянии down:

13. Проверьте версии:

14. Запустите все службы, которые вы остановили в п.1 и проверьте работу USERSIDE и модулей. Убедитесь, что всё работает корректно.

15. После того, как вы убедились, что всё работает корректно, можно удалить временные резервные копии, а также старые пакеты:

Источник

Postgresql как обновить версию на windows

pg_upgrade — обновить экземпляр сервера PostgreSQL

Синтаксис

Описание

Программа pg_upgrade (ранее называвшаяся pg_migrator ) позволяет обновить данные в каталоге базы данных PostgreSQL до последней основной версии PostgreSQL без операции выгрузки/перезагрузки данных, обычно необходимой при обновлениях основной версии, например, при переходе от 9.5.8 к 9.6.4 или от 10.7 к 11.2. Эти действия не требуются при установке корректирующей версии, например, при переходе от 9.6.2 к 9.6.3 или от 10.1 к 10.2.

С выходом новых основных версий в PostgreSQL регулярно добавляются новые возможности, которые часто меняют структуру системных таблицы, но внутренний формат хранения меняется редко. Учитывая этот факт, pg_upgrade позволяет выполнить быстрое обновление, создавая системные таблицы заново, но сохраняя старые файлы данных. Если при обновлении основной версии формат хранения данных изменится так, что данные в старом формате окажутся нечитаемыми, pg_upgrade не сможет произвести такое обновление. (Сообщество разработчиков постарается не допустить подобных ситуаций.)

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

Параметры

pg_upgrade принимает следующие аргументы командной строки:

показать справку, а затем завершиться

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

Далее описан план обновления с использованием pg_upgrade :

Переместить старый кластер (необязательно)

Собрать новую версию при установке из исходного кода

Установить новые исполняемые файлы PostgreSQL

Установите новые исполняемые файлы сервера и вспомогательные файлы. Программа pg_upgrade включена в инсталляцию по умолчанию.

При установке из исходного кода, если вы хотите разместить сервер в нестандартном каталоге, воспользуйтесь переменной prefix :

Инициализировать новый кластер PostgreSQL

Установить разделяемые объектные файлы расширения

Скопируйте пользовательские файлы полнотекстового поиска

Скопировать пользовательские файлы полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов) из старого кластера в новый.

Настроить аутентификацию

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

Остановить оба сервера

Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:

А в Windows, с соответствующими именами служб:

Ведомые серверы с потоковой репликацией и трансляцией журнала могут продолжать работать до последнего шага.

Подготовиться к обновлению ведомых серверов

Запустить pg_upgrade

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

Если выбрать вариант со ссылкой на данные, обновление выполнится гораздо быстрее (так как файлы не копируются) и потребует меньше места на диске, но вы лишитесь возможности обращаться к вашему старому кластеру, запустив новый после обновления. Этот вариант также требует, чтобы каталоги данных старого и нового кластера располагались в одной файловой системе. (Табличные пространства и pg_wal могут находиться в других файловых системах.) Вариант с клонированием работает так же быстро и экономит место на диске, но позволяет сохранить рабочее состояние старого кластера при запуске нового. Для этого варианта тоже требуется, чтобы старый и новый каталоги данных находились в одной файловой системе. Клонирование возможно только в некоторых операционных системах с определёнными файловыми системами.

Наконец, запустить pg_upgrade с путями каталогов в кавычках, например, так:

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

Обновить ведомые серверы с потоковой репликацией и трансляцией журнала

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

Установите новые исполняемые файлы PostgreSQL на ведомых серверах

Убедитесь в том, что на всех ведомых серверах установлены новые исполняемые и вспомогательные файлы.

Убедитесь в том, что новые каталоги данных на ведомых серверах не существуют

Установить разделяемые объектные файлы расширения

Установите на новых ведомых серверах те же разделяемые объектные файлы расширения, что вы установили в новом ведущем кластере.

Остановите ведомые серверы

Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.

Сохраните файлы конфигурации

Запустите rsync

Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств, например:

Если вы вынесли pg_wal за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.

Настройте ведомые серверы с потоковой репликацией и трансляцией журнала

Настройте серверы для трансляции журнала. (Запускать pg_start_backup() и pg_stop_backup() или делать копию файловой системы не нужно, так как ведомые серверы остаются синхронизированными с ведущим.)

Восстановить pg_hba.conf

Запустить новый сервер

Действия после обновления

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

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

Внимание

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

Статистика

Удалить старый кластер

Возврат к старому кластеру

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

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

Замечания

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

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

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

Если вы используете старый сервер версии до 9.1, работающий с нестандартным каталогом Unix-сокетов, либо его стандартное расположение отличается от принятого в новой версии, задайте в PGHOST расположение сокета старого сервера. (К Windows это не относится.)

Источник

Postgresql как обновить версию на windows

pg_upgrade — обновить экземпляр сервера Postgres Pro

Синтаксис

Описание

Программа pg_upgrade (ранее называвшаяся pg_migrator ) позволяет обновить данные в каталоге базы PostgreSQL или Postgres Pro до последней основной версии Postgres Pro без операции выгрузки/перезагрузки данных, обычно необходимой при обновлениях основной версии, например, при переходе от 9.5.8 к 9.6.4 или от 10.7 к 11.2. Эти действия не требуются при установке корректирующей версии, например, при переходе от 9.6.2 к 9.6.3 или от 10.1 к 10.2.

С выходом новых основных версий в Postgres Pro регулярно добавляются новые возможности, которые часто меняют структуру системных таблицы, но внутренний формат хранения меняется редко. Учитывая этот факт, pg_upgrade позволяет выполнить быстрое обновление, создавая системные таблицы заново, но сохраняя старые файлы данных. Если при обновлении основной версии формат хранения данных изменится так, что данные в старом формате окажутся нечитаемыми, pg_upgrade не сможет произвести такое обновление. (Сообщество разработчиков постарается не допустить подобных ситуаций.)

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

Параметры

pg_upgrade принимает следующие аргументы командной строки:

показать справку, а затем завершиться

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

Далее описан план обновления с использованием pg_upgrade :

Переместить старый кластер (необязательно)

Установить новые исполняемые файлы Postgres Pro

Установите новые исполняемые файлы сервера и вспомогательные файлы. Программа pg_upgrade включена в инсталляцию по умолчанию.

Инициализировать новый кластер Postgres Pro

Установить разделяемые объектные файлы расширения

Скопируйте пользовательские файлы полнотекстового поиска

Скопировать пользовательские файлы полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов) из старого кластера в новый.

Настроить аутентификацию

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

Остановить оба сервера

Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:

А в Windows, с соответствующими именами служб:

Ведомые серверы с потоковой репликацией и трансляцией журнала могут продолжать работать до последнего шага.

Подготовиться к обновлению ведомых серверов

Запустить pg_upgrade

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

Если выбрать вариант со ссылкой на данные, обновление выполнится гораздо быстрее (так как файлы не копируются) и потребует меньше места на диске, но вы лишитесь возможности обращаться к вашему старому кластеру, запустив новый после обновления. Этот вариант также требует, чтобы каталоги данных старого и нового кластера располагались в одной файловой системе. (Табличные пространства и pg_wal могут находиться в других файловых системах.) Вариант с клонированием работает так же быстро и экономит место на диске, но позволяет сохранить рабочее состояние старого кластера при запуске нового. Для этого варианта тоже требуется, чтобы старый и новый каталоги данных находились в одной файловой системе. Клонирование возможно только в некоторых операционных системах с определёнными файловыми системами.

Наконец, запустить pg_upgrade с путями каталогов в кавычках, например, так:

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

Обновить ведомые серверы с потоковой репликацией и трансляцией журнала

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

Установите новые исполняемые файлы Postgres Pro на ведомых серверах

Убедитесь в том, что на всех ведомых серверах установлены новые исполняемые и вспомогательные файлы.

Убедитесь в том, что новые каталоги данных на ведомых серверах не существуют

Установить разделяемые объектные файлы расширения

Установите на новых ведомых серверах те же разделяемые объектные файлы расширения, что вы установили в новом ведущем кластере.

Остановите ведомые серверы

Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.

Сохраните файлы конфигурации

Запустите rsync

Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств, например:

Если вы вынесли pg_wal за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.

Настройте ведомые серверы с потоковой репликацией и трансляцией журнала

Настройте серверы для трансляции журнала. (Запускать pg_start_backup() и pg_stop_backup() или делать копию файловой системы не нужно, так как ведомые серверы остаются синхронизированными с ведущим.)

Восстановить pg_hba.conf

Запустить новый сервер

Действия после обновления

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

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

Внимание

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

Статистика

Удалить старый кластер

Возврат к старому кластеру

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

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

Замечания

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

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

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

Если вы используете старый сервер версии до 9.1, работающий с нестандартным каталогом Unix-сокетов, либо его стандартное расположение отличается от принятого в новой версии, задайте в PGHOST расположение сокета старого сервера. (К Windows это не относится.)

Источник

Обновление сервера на PostgreSQL 11 под ОС Windows

Архив лог-файлов для передачи в службу поддержки:

Данный процесс предусматривает перевод сервера PostgreSQL с версии 9.4 до версии 11. Обращаем ваше внимание на то, что, обновление сервера PostgreSQL должно осуществляться опытными ИТ-специалистами.

Подготовка к обновлению

1. Перевод на новую версию PostgreSQL 11 осуществляется только для 64-х битных операционных систем.

2. Внимание! Перед началом процедур по переводу на новую версию PostgreSQL, обязательно обновите вашу операционную систему.

4. Проводите обновление только на официально-активированной версии ОС Windows.

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

3. Обязательно проверьте наличие свободного дискового пространства, оно должно быть достаточным, в зависимости от размеров вашей БД, так как в следующих шагах восстановление базы данных будет в новую версию сервера СУБД PostgreSQL 11, и при этом, версия PostgreSQL 9.4 будет установлена на момент развертывания архивов БД.

На данном изображении достаточно места для проведения операции обновления.

4. На время обновления PostgreSQL 9.4 на версию 11 не планируйте никаких работ на продуктивной среде так и с сервером магазина.

5. Следуйте только шагам описанным в данной инструкции!

Обновление PostgreSQL для ОС Windows

Все шаги выполняются только от пользователя с локальными правами администратора.

1. Разархивируйте файл UPGRADEvXX.zip.

2. Выберите пусть распаковки → нажмите Извлечь.

3. В папке со скриптами обновления откройте на редактирование optionfile любым текстовым редактором.

4. Отредактируйте следующие параметры для установки PostgreSQL 11, если требуется:

Создавать ярлык на PgAdmin4 на рабочем столе:

Полный путь установки программных компонентов PostgreSQL 11.

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

Полный путь установки файлов для хранения данных БД PostgreSQL 11

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

5. Откройте на редактирование в любом текстовом редакторе файл passwordfile для установки пароля доступа к серверу PostgreSQL 9.4.

6. Установите пароль → сохраните файл.

7. Запустите файл backup.cmd с правами администратора для создания архива текущего сервера баз данных.

8. Начнется выполнение операции по сохранению резервной копии баз данных СУБД PostgreSQl 9.4.

Не закрывайте окно. Дождитесь окончания операции.

9. Когда операция бэкапирования завершится, появится сообщение о том, что оно успешно закончено и окно можно закрыть → нажмите любую клавишу.

10. Перейдите в папку current для проверки созданных резервных копий баз данных PostgreSQL 9.4.

11. Проверьте, что все файлы резервных копий, что созданы следующие файлы резервных копий СУБД:

11. Откройте папку log для проверки лог-файлов.

12. Откройте файл status.txt для просмотра статуса завершения операции бэкапирования.

14. Откройте лог-файл backup.txt.

15. Просмотрите, что во время процесса бэкапирования службы PostgreSQL 9.4. успешно запускались и останавливались.

16. Также откройте любой из лог-файлов с наименованием баз данных SetRetail/SetCentrum.

17. Проверьте, что процесс резервного копирования не содержит ошибок.

18. Запустите скрипт обновления upgrade.cmd с правами администратора.

19. Проверьте еще раз правильность путей для установки PostgreSQL 11, если они корректны введите Y → нажмите ENTER.

Для отмены установки введите N → нажмите ENTER.

20. Начнётся установка необходимых компонентов для запуска установщика PostgreSQL 11.

21. После установки компонентов откроется окно процесса инсталляции СУБД PostgreSQL 11.

22. Во время выполнения скрипта сервер баз данных будет перезапускаться, а также автоматически произойдет восстановление баз данных на новую версию сервера СУБД всех резервных копий.

23. Когда в окне интерпретатора отобразится сообщение Обновление прошло успешно → нажмите любую клавишу.

24. Проверьте в оснастке служб, что сервис postgresql-x64-11 в статусе Работает.

25. Посмотрите лог-файл upgrade.txt.

26. Убедитесь, что он не содержит критичных ошибок обновления.

27. Обновление завершено.

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

29. Запустите командную строку и наберите команду для проверки актуального пути установленного сервера СУБД PostgreSQL 11.

Должен отобразится актуальный путь к СУБД PostgreSQL 11!

Внимание! Если, после обновления и стабильной работы сервера отображается старый путь установки СУБД, тогда выполните команду для установки актуального пути в переменную среды PostgreSQL → перезапустите службу МУК.

Очистка места на диске после обновления

Выполняйте этот шаг, если:

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

2. Откройте сеанс командной строки от имени администратора и выполните команду на удаление службы PostgreSQL 9.4

Источник

Adblock
detector

Параметр
superaccount	Имя пользователя с глобальным с правами для сервера СУБД PostgreSQl 11.
superpassword	Пароль пользователя с глобальным с правами для сервера СУБД PostgreSQl 11.
create_shortcuts