PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Atualizando PostgreSQL 11 para PostgreSQL 13 com TimescaleDB e PostGIS no Linux usando pg_upgrade

Empresas e empresas que usam versões antigas do PostgreSQL (PG) enfrentam desafios ao atualizar pelo menos a versão estável mais recente do PostgreSQL 12 ou PostgreSQL 13. Há muitas razões pelas quais atualizar para a versão mais recente é uma devo. Algumas das principais razões para isso são aproveitar seus aprimoramentos críticos em suas funcionalidades internas, atualizações de segurança, melhorias de desempenho e novas implementações benéficas para o gerenciamento de banco de dados.

A atualização do PostgreSQL vem com alguns desafios, pois não é tão fácil em comparação com outros bancos de dados convencionais. Se você está enfrentando esse tipo de problema, não se preocupe. O PostgreSQL não bloqueia você em uma versão específica para usar. Neste blog, veremos um exemplo desse desafio enquanto temos um TimescaleDB e PostGIS instalados em um host PostgreSQL 11 existente.

Por que pg_upgrade?

pg_upgrade existe há muito tempo como uma ferramenta para atualizar as principais versões do PostgreSQL. O uso desta ferramenta não é necessário para atualizações de versões secundárias, o que significa que não é necessário atualizar sua versão atual de 11.9 para 11.13.

Ao atualizar seu PostgreSQL para uma versão principal com pg_upgrade, a ferramenta funciona permitindo que os dados armazenados em arquivos de dados PostgreSQL sejam atualizados para uma versão principal posterior do PostgreSQL. Isso funciona sem a necessidade de um despejo/recarregamento de dados, o que pode levar algum tempo se você tiver um grande conjunto de dados.

Agora vem a confusão. O PostgreSQL, especialmente para versões principais, é conhecido por ter novos recursos adicionados que geralmente alteram o layout das tabelas do sistema, mas o formato interno de armazenamento de dados raramente muda. O pg_upgrade usa esse fato para realizar atualizações rápidas criando novas tabelas de sistema e simplesmente reutilizando os antigos arquivos de dados do usuário. Se uma versão principal futura alterar o formato de armazenamento de dados de uma forma que torne o formato de dados antigo ilegível, o pg_upgrade não poderá ser usado para tais atualizações. (A comunidade tentará evitar tais situações.)

Alguns podem considerar o pg_upgrade perigoso, especialmente para o ambiente de produção. Bem, essa ferramenta tem sido amplamente utilizada em outros lugares, desde QA, dev, até ambientes de produção. Ele tem suas limitações ou ressalvas, como o Unicode conhecido ou conjuntos de caracteres armazenados em seu conjunto de dados. Nesse caso, você pode considerar usar pg_dump/pg_restore, mas pode levar algum tempo para terminar, dependendo do tamanho dos seus dados. Para versões mais recentes do PostgreSQL, como PG 14.0, você só pode fazer um dump/restauração (ou exportação/importação) ou replicação lógica, caso contrário, use pg_upgrade.

Para conjuntos de dados maiores, usar pg_upgrade exige que você execute isso no mesmo host, que por padrão aplica uma cópia de todos os seus arquivos físicos do diretório de dados. Nesse caso, pg_upgrade suporta a opção -k ou --link, o que significa que usará links físicos em vez de copiar arquivos para o novo cluster.

pg_upgrade faz o possível para garantir que os clusters antigos e novos sejam compatíveis com binários, por exemplo, verificando configurações de tempo de compilação compatíveis, incluindo binários de 32/64 bits. Também é importante que todos os módulos externos sejam compatíveis com binários, embora isso não possa ser verificado pelo pg_upgrade.

pg_upgrade suporta atualizações de 8.4.X e posteriores para a versão principal atual do PostgreSQL, incluindo versões de snapshot e beta.

Aqui está a situação…

Nesta configuração, usei o ClusterControl para implantar um cluster de banco de dados PostgreSQL 11 para um único nó. O seguinte foi testado no Centos 7 e Ubuntu Focal (20.04.1):

$ /usr/pgsql-11/bin/postgres --version
postgres (PostgreSQL) 11.13

postgres=# \dx
                                           List of installed extensions

          Name          | Version |   Schema   |                            Description

------------------------+---------+------------+-------------------------------------------------------------------
 fuzzystrmatch          | 1.1     | public     | determine similarities and distance between strings
 pg_stat_statements     | 1.6     | public     | track execution statistics of all SQL statements executed
 plpgsql                | 1.0     | pg_catalog | PL/pgSQL procedural language
 postgis                | 3.1.4   | public     | PostGIS geometry and geography spatial types and functions
 postgis_raster         | 3.1.4   | public     | PostGIS raster types and functions
 postgis_sfcgal         | 3.1.4   | public     | PostGIS SFCGAL functions
 postgis_tiger_geocoder | 3.1.4   | tiger      | PostGIS tiger geocoder and reverse geocoder
 postgis_topology       | 3.1.4   | topology   | PostGIS topology spatial types and functions
 timescaledb            | 2.3.1   | public     | Enables scalable inserts and complex queries for time-series data
(9 rows)

Então eu tenho o seguinte,

Versão do servidor PostgreSQL: 11.13

Versão do TimescaleDB: 2.3.1

Versão PostGIS: 3.1.4

Se você quiser testar isso com ClusterControl, há duas maneiras de ter TimescaleDB. Você pode implantar um cluster TimescaleDB ou ter PostgreSQL e habilitar o plugin TimescaleDB.


Configurando seu PostgreSQL 13

Usar a configuração do gerenciador de pacotes para o ambiente Linux com o repositório PostgreSQL e TimescaleDB é mais fácil. Aqui estão os passos para fazê-lo:

Configure os repositórios necessários

Primeiro, vamos adicionar o repositório PostgreSQL.

Para CentOS/RHEL/Oracle Linux

Você precisa ter certeza de que tem o repositório correto. Para Enterprise Linux (EL) 7, você pode fazer o seguinte:

sudo yum -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Para outra arquitetura, você pode basear aqui https://download.postgresql.org/pub/repos/yum/reporpms/ e substituir o subdiretório EL-7-x86_64.


Vamos adicionar o repositório TimescaleDB também.

vi /etc/yum.repos.d/timescale_timescaledb.repo

Em seguida, adicione o seguinte conteúdo para este arquivo,

[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/7/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

Basta substituir o baseurl de acordo se você estiver usando uma versão diferente do EL 7.

Para Ubuntu/Debian

Adicione o repositório PG para Ubuntu Focal:

deb http://apt.postgresql.org/pub/repos/apt/ focal-pgdg main

Para outras distribuições Ubuntu/Debian, apenas substitua o focal de acordo, que você pode encontrar aqui http://apt.postgresql.org/pub/repos/apt/dists/. Por exemplo, substitua focal-pgdg por buster-pgdg.


Agora, vamos adicionar o repositório para TimescaleDB,

sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/timescale.keyring] https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -c -s) main' > /etc/apt/sources.list.d/timescaledb.list"

Importar o chaveiro,

wget --quiet -O - https://packagecloud.io/timescale/timescaledb/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/timescale.keyring

e atualize as listas de pacotes para atualizações de pacotes que precisam de atualização, bem como novos pacotes que acabaram de chegar aos repositórios.

sudo apt-get update

Você pode substituir o subdiretório na URL se estiver usando o Debian do Ubuntu.

Agora que temos o repositório pronto, estamos prontos.

Instale o PostgreSQL versão 13 com TimescaleDB e PostGIS

A instalação do PostgreSQL 13 pode ser feita no mesmo host. Primeiro, você deve certificar-se de que coisas como a porta do banco de dados sejam exclusivas. Em outras palavras, deve ser diferente do PostgreSQL 11 atual instalado no mesmo host.

Para CentOS/RHEL/Oracle Linux

Execute o comando abaixo para instalar o PostgreSQL 13 e seus pacotes dependentes:

yum install postgresql13.x86_64 postgresql13-server.x86_64 postgresql13-contrib.x86_64 postgresql13-libs.x86_64  

Em seguida, inicialize o cluster de banco de dados e sua coleção de bancos de dados necessária executando o comando abaixo:

$ /usr/pgsql-13/bin/postgresql-13-setup initdb

Neste ponto, deve haver dois diretórios de dados para PG 11 e PG 13:

[[email protected] ~]# ls -alth /var/lib/pgsql/* -d
drwx------. 4 postgres postgres 51 Sep 22 14:19 /var/lib/pgsql/13
drwx------. 4 postgres postgres 33 Sep 21 18:53 /var/lib/pgsql/11

Agora que estamos bem com o PostgreSQL 13, vamos instalar o TimescaleDB. Precisamos ter certeza de que o plugin a ser instalado é a mesma versão do PostreSQL 11.

Observe que, para garantir que o pg_upgrade funcione sem problemas, os plug-ins de sua origem e destino da versão principal devem ser da mesma versão. Isso ocorre porque o pg_upgrade procurará suas bibliotecas designadas vinculadas aos plug-ins ou extensões que foram carregados ou usados ​​por sua versão antiga ou de origem do banco de dados do PostgreSQL. Você pode verificar isso em seu Enterprise Linux executando showduplicates ou verificando com informações como abaixo com dnf ou yum:

$ yum --showduplicates list timescaledb_13.x86_64 timescaledb-2-postgresql-13.x86_64 timescaledb-2-oss-postgresql-13.x86_64 timescaledb-2-loader-postgresql-13.x86_64|grep '2.3.1'
Repository pgdg-common is listed more than once in the configuration
timescaledb-2-loader-postgresql-13.x86_64  2.3.1-0.el7     timescale_timescaledb
timescaledb-2-oss-postgresql-13.x86_64     2.3.1-0.el7     timescale_timescaledb
timescaledb-2-postgresql-13.x86_64         2.3.1-0.el7     timescale_timescaledb

Ou verifique com a opção info:

$ yum info timescaledb-2-loader-postgresql-13-2.3.1-0.el7.x86_64 timescaledb-2-postgresql-13-2.3.1-0.el7.x86_64

Agora, estamos prontos para instalar o pacote TimescaleDB para a versão PG 13.
$ yum install timescaledb-2-loader-postgresql-13-2.3.1-0.el7.x86_64 timescaledb-2-postgresql-13-2.3.1-0.el7.x86_64

Depois de instalá-lo, você pode tentar executar a ferramenta timescaledb-tune para ajustar seu arquivo de configuração postgresql.conf. Basta executar o comando abaixo:

$  timescaledb-tune --pg-config=/usr/pgsql-13/bin/pg_config

Agora, vamos instalar o pacote PostGIS para a versão PG 13 também.

$ yum install -y postgis31_13.x86_64 

Para Ubuntu/Debian

Simplesmente execute:

$  apt install postgresql-client-13 postgresql-13

O melhor das distribuições Ubuntu/Debian é que existem ferramentas para PostgreSQL que são muito úteis para gerenciar seus clusters PostgreSQL, como pg_lsclusters,  pg_ctlcluster, etc.

Você pode verificar seus clusters disponíveis instalados.

$ pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
11  main    5432 online   postgres /var/lib/postgresql/11/main log/postgresql-%Y-%m-%d_%H%M%S.log
13  main    5433 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log

No Ubuntu/Debian, não há necessidade de alterar a porta, pois ela será tratada durante a fase de instalação e a detectará e a definirá de forma exclusiva, de acordo.

Agora, vamos instalar o TimescaleDB.

$ apt install timescaledb-2-loader-postgresql-13 timescaledb-2-postgresql-13

Opcionalmente, você pode executar a ferramenta timescaledb-tune para ajustar seu arquivo de configuração postgresql.conf simplesmente invocando a ferramenta da seguinte forma:

$ timescaledb-tune

Agora, estamos prontos para instalar o pacote PostGIS para PG 13.
$ apt install postgresql-13-postgis-3-scripts postgresql-13-postgis-3


Revise seu postgresql.conf

É sempre melhor revisar seu arquivo de configuração postgresql.conf. Nas versões Enterprise Linux, você pode localizar seu postgresql.conf em seu diretório data_directory ou no caminho PGDATA. Já para Ubuntu/Debian, você pode localizá-lo em /etc/postgresql///postgresql.conf. Certifique-se de que em seu postgresql.conf, as seguintes linhas estejam configuradas corretamente:

shared_preload_libraries = 'pg_stat_statements,timescaledb'     # pg_stat_statements is not required but if you are using ClusterControl, make sure this is appended.
port = 5532   # make sure that the port number is unique than the old version of your PostgreSQL

listen_address = *     # depends on your setup but if you need to specify the available network interfaces to its IP addresses (IPv4 or IPv6) set it accordingly.

É uma prática recomendada comparar suas versões antigas e novas de seus arquivos de configuração do PostgreSQL para garantir que seu postgresql.conf seja idêntico ao que é necessário e definido.

Antes de prosseguir com a próxima etapa, também precisamos verificar se o PostgreSQL versão 13 está carregado adequadamente. Certifique-se de ter a versão mais recente adquirida ou instalada em seu host. Inicie o banco de dados e certifique-se de que ele seja iniciado e executado corretamente.

Para iniciar em distribuições EL, execute o comando abaixo:

$ sudo -iu postgres /usr/pgsql-13/bin/pg_ctl -D /var/lib/pgsql/13/data/ -o "-c config_file=/var/lib/pgsql/13/data/postgresql.conf" start

ou para Ubuntu/Debian, execute o comando abaixo:

$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_ctl -D /var/lib/postgresql/13/main/ -o "-c config_file=/etc/postgresql/13/main/postgresql.conf" start

ou use a ferramenta pg_ctlcluster para iniciar, reiniciar ou parar seu cluster PG.


Quando estiver pronto, execute pg_upgrade…

Antes de prosseguir, primeiro certifique-se de ter sempre o backup do seu servidor antigo pronto e disponível. Sempre faça um backup lógico e um backup físico como boa prática antes de prosseguir com uma atualização importante.

Agora que você está pronto, pode executar o pg_upgrade. Na prática, você deve executar inicialmente o pg_upgrade com uma verificação para determinar a incompatibilidade e os problemas antes de prosseguir para o procedimento principal do pg_upgrade. Antes de executar o pg_upgrade, certifique-se de que tanto o PG 11 quanto o PG 13 estejam inativos durante este processo. Isso significa apenas que o tempo de inatividade é necessário para esse processo.

Para fazer isso, execute o seguinte comando com a opção --check:

$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_upgrade -o "-c config_file=/etc/postgresql/11/main/postgresql.conf" --old-datadir=/var/lib/postgresql/11/main/   -O "-c config_file=/etc/postgresql/13/main/postgresql.conf"  --new-datadir=/var/lib/postgresql/13/main/ --old-bindir=/usr/lib/postgresql/11/bin --new-bindir=/usr/lib/postgresql/13/bin --check

Substitua o valor --old-datadir ou config_file de acordo se for diferente da sua configuração.

Isso deve executar verificações de compatibilidade como o resultado abaixo:

Performing Consistency Checks

-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*

Se todas as verificações sinalizarem “ok”, isso significa uma verificação bem-sucedida e a mensagem inferior mostrar que os clusters são compatíveis, então você deve estar pronto.

Finalmente, execute o comando novamente sem a opção --check:

$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_upgrade -o "-c config_file=/etc/postgresql/11/main/postgresql.conf" --old-datadir=/var/lib/postgresql/11/main/   -O "-c config_file=/etc/postgresql/13/main/postgresql.conf"  --new-datadir=/var/lib/postgresql/13/main/ --old-bindir=/usr/lib/postgresql/11/bin --new-bindir=/usr/lib/postgresql/13/bin

Performing Consistency Checks

-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Creating dump of global objects                             ok
Creating dump of database schemas                           ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
Performing Upgrade

------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows in the new cluster                        ok
Deleting files from new pg_xact                             ok
Copying old pg_xact to new server                           ok
Setting oldest XID for new cluster                          ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluste                ok
Copying user relation files                                 ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok
Checking for extension updates                              notice
Your installation contains extensions that should be updated
with the ALTER EXTENSION command.  The file
    update_extensions.sql
when executed by psql by the database superuser will update
these extensions.

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

Dependendo do tamanho do seu conjunto de dados, pode demorar um pouco. No comando de exemplo acima, ele copia os logs de transações, que são de arquivos físicos. No entanto, se o tamanho do seu disco estiver apertado, você poderá usar a opção -k ou --link, que usa links físicos. Se tudo correr bem, ele deve fornecer mensagens como a acima, notificando-o sobre a atualização completa e avisos para atualizar as extensões que você possa ter. Nesta configuração, tudo vai bem. O update_extensions.sql contém apenas o seguinte:

$ cat update_extensions.sql
\connect postgres
ALTER EXTENSION "pg_stat_statements" UPDATE;

Como você notou, o pg_upgrade realiza uma série de ações. Ele analisa todas as linhas do cluster de origem, copiando logs de metadados de transações e seus dados de status de várias transações e o restante.

Depois de descobrir que tudo parece bem, execute o script analyze_new_cluster.sh, que deve ser executado

vacuumdb --all --analyze-only.
$ sudo -iu postgres PGPORT=5433 ./analyze_new_cluster.sh

Observe que você deve especificar a porta do seu PostgreSQL 13 para que o vácuodb seja executado corretamente no servidor de destino correto.

Neste caso, o resultado da atualização com as extensões TimescaleDB e PostGIS habilitadas vai bem. Quando tudo estiver em ordem, certifique-se de iniciar o servidor e fazer uma série de testes e verificações.


Teste o processo de atualização

Sempre teste e revise o processo de atualização. Aqui estão algumas tabelas e um banco de dados definido pelo usuário, que contém hipertabelas e tabelas PostGIS que dependem do uso de tipos e funções espaciais de geometria e geografia.

$ sudo -iu postgres psql -p5433
psql (13.4 (Ubuntu 13.4-1.pgdg20.04+1))
Type "help" for help.

postgres=# \l

                              List of databases

   Name    |  Owner   | Encoding | Collate |  Ctype  |   Access privileges

-----------+----------+----------+---------+---------+-----------------------
 mydb      | postgres | UTF8     | C.UTF-8 | C.UTF-8 |
 postgres  | postgres | UTF8     | C.UTF-8 | C.UTF-8 |
 template0 | postgres | UTF8     | C.UTF-8 | C.UTF-8 | =c/postgres          +
           |          |          |         |         | postgres=CTc/postgres
 template1 | postgres | UTF8     | C.UTF-8 | C.UTF-8 | postgres=CTc/postgres+
           |          |          |         |         | =c/postgres
(4 rows)

postgres=# \c mydb
You are now connected to database "mydb" as user "postgres".

mydb=# set search_path="$user",public;
SET
mydb=# \dt+
                                  List of relations

 Schema |      Name       | Type  |  Owner   | Persistence |    Size    | Description

--------+-----------------+-------+----------+-------------+------------+-------------
 public | conditions      | table | postgres | permanent   | 8192 bytes |
 public | global_points   | table | postgres | permanent   | 16 kB      |
 public | roads           | table | postgres | permanent   | 16 kB      |
 public | sample_table    | table | postgres | permanent   | 8192 bytes |
 public | spatial_ref_sys | table | postgres | permanent   | 6968 kB    |
(5 rows)

Verificando alguns dos meus PostGIS e hypertables:
mydb=# \d roads
                        Table "public.roads"

   Column   |         Type         | Collation | Nullable | Default
------------+----------------------+-----------+----------+---------
 road_id    | integer              |           |          |
 road_name  | character varying    |           |          |
 roads_geom | geometry(LineString) |           |          |

mydb=# \d sample_table
                                     Table "public.sample_table"

 Column |           Type           | Collation | Nullable |                 Default
--------+--------------------------+-----------+----------+------------------------------------------
 id     | integer                  |           | not null | nextval('sample_table_id_seq'::regclass)
 time   | timestamp with time zone |           | not null |
 name   | character varying        |           | not null |
Indexes:
   "sample_table_pkey" PRIMARY KEY, btree (id, "time")
    "sample_table_time_idx" btree ("time" DESC)
Triggers:
    ts_insert_blocker BEFORE INSERT ON sample_table FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Number of child tables: 371 (Use \d+ to list them.)

mydb=# \d conditions
                        Table "public.conditions"

   Column    |           Type           | Collation | Nullable | Default
-------------+--------------------------+-----------+----------+---------
 time        | timestamp with time zone |           | not null |
 location    | text                     |           | not null |
 location2   | character(10)            |           | not null |
 temperature | double precision         |           |          |
 humidity    | double precision         |           |          |
Indexes:
    "conditions_time_idx" btree ("time" DESC)
Triggers:
    ts_insert_blocker BEFORE INSERT ON conditions FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Number of child tables: 366 (Use \d+ to list them.)

mydb=# select count(*) from sample_table;
 count
-------
  2588
(1 row)



mydb=# SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);
  name

--------
 Town
 Forest
(2 rows)



mydb=# SELECT n, ST_AsEWKT(ST_GeometryN(the_geom, n)) As geomewkt
mydb-# FROM (
mydb(# VALUES (ST_GeomFromEWKT('MULTIPOINT(1 2 7, 3 4 7, 5 6 7, 8 9 10)') ),
mydb(# ( ST_GeomFromEWKT('MULTICURVE(CIRCULARSTRING(2.5 2.5,4.5 2.5, 3.5 3.5), (10 11, 12 11))') )
mydb(# )As foo(the_geom)
mydb-# CROSS JOIN generate_series(1,100) n
mydb-# WHERE n <= ST_NumGeometries(the_geom);
 n |                geomewkt

---+-----------------------------------------
 1 | POINT(1 2 7)
 1 | CIRCULARSTRING(2.5 2.5,4.5 2.5,3.5 3.5)
 2 | POINT(3 4 7)
 2 | LINESTRING(10 11,12 11)
 3 | POINT(5 6 7)
 4 | POINT(8 9 10)
(6 rows)

Agora tudo parece pronto para servir como meu novo cluster.

Depois de fazer as coisas acontecerem, você pode executar:

$ sudo -iu postgres ./delete_old_cluster.sh

Certifique-se de executar apenas o script, pois este é um script muito perigoso, pois ele excluirá todos os arquivos em seu cluster PostgreSQL antigo.

Conclusão


pg_upgrade é uma ótima ferramenta para gerenciar e atualizar seu servidor de banco de dados PostgreSQL. Ele pode lidar com configurações complexas, como as extensões TimescaleDB ou PostGIS habilitadas. Embora essa ferramenta tenha suas limitações, não há como parar de usá-la, especialmente para seu trabalho de DBA e em servidores de produção além de ambientes de controle de qualidade e desenvolvimento.