PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Aktualizacja PostgreSQL 11 do PostgreSQL 13 z TimescaleDB i PostGIS w systemie Linux przy użyciu pg_upgrade

Firmy i przedsiębiorstwa korzystające ze starych wersji PostgreSQL (PG) stają przed wyzwaniami podczas aktualizacji przynajmniej do najnowszej stabilnej wersji z PostgreSQL 12 lub PostgreSQL 13. Istnieje wiele powodów, dla których aktualizacja do najnowszej wersji jest musi. Niektóre z głównych powodów takiego stanu rzeczy to wykorzystanie krytycznych ulepszeń wbudowanych funkcji, aktualizacji zabezpieczeń, ulepszeń wydajności i nowych wdrożeń korzystnych dla zarządzania bazami danych.

Aktualizacja PostgreSQL wiąże się z kilkoma wyzwaniami, ponieważ nie jest tak łatwa w porównaniu z innymi popularnymi bazami danych. Jeśli masz do czynienia z tego rodzaju problemem, nie martw się. PostgreSQL nie blokuje Cię na konkretnej wersji do użycia. W tym blogu omówimy przykład tego wyzwania, mając zainstalowane TimescaleDB i PostGIS na istniejącym hoście PostgreSQL 11.

Dlaczego pg_upgrade?

pg_upgrade istnieje od bardzo dawna jako narzędzie do uaktualniania głównych wersji PostgreSQL. Korzystanie z tego narzędzia nie jest wymagane w przypadku pomniejszych aktualizacji wersji, co oznacza, że ​​aktualizacja bieżącej wersji 11.9 do 11.13 nie jest konieczna.

Podczas aktualizacji PostgreSQL do głównej wersji za pomocą pg_upgrade, narzędzie działa, umożliwiając aktualizację danych przechowywanych w plikach danych PostgreSQL do późniejszej głównej wersji PostgreSQL. Działa to bez potrzeby zrzutu/przeładowania danych, co może zająć trochę czasu, jeśli masz duży zestaw danych.

Teraz zaczyna się zamieszanie. Wiadomo, że PostgreSQL, zwłaszcza w przypadku głównych wersji, zawiera nowe funkcje, które często zmieniają układ tabel systemowych, ale format wewnętrznego przechowywania danych rzadko się zmienia. pg_upgrade wykorzystuje ten fakt do przeprowadzania szybkich aktualizacji poprzez tworzenie nowych tabel systemowych i ponowne wykorzystywanie starych plików danych użytkownika. Jeśli przyszłe główne wydanie zmieni kiedykolwiek format przechowywania danych w sposób, który sprawi, że stary format danych będzie nieczytelny, pg_upgrade nie będzie nadawał się do takich uaktualnień. (Społeczność będzie starała się unikać takich sytuacji).

Niektórzy mogą uznać pg_upgrade za niebezpieczne, szczególnie dla środowiska produkcyjnego. Cóż, to narzędzie było szeroko stosowane w innych miejscach, od kontroli jakości, przez programistów, po środowiska produkcyjne. Ma swoje ograniczenia lub zastrzeżenia, takie jak znany Unicode lub zestawy znaków przechowywane w zestawie danych. W takim przypadku możesz rozważyć użycie pg_dump/pg_restore, ale może to zająć trochę czasu, w zależności od tego, jak duże są twoje dane. W przypadku nowszych wersji PostgreSQL, takich jak PG 14.0, możesz wykonać tylko zrzut/przywrócenie (lub eksport/import) lub replikację logiczną, w przeciwnym razie użyj pg_upgrade.

W przypadku większych zbiorów danych użycie pg_upgrade wymaga uruchomienia go na tym samym hoście, który domyślnie stosuje kopię wszystkich plików fizycznych z katalogu danych. W takim przypadku pg_upgrade obsługuje opcję -k lub --link, co oznacza, że ​​użyje twardych dowiązań zamiast kopiowania plików do nowego klastra.

pg_upgrade dokłada wszelkich starań, aby upewnić się, że stare i nowe klastry są kompatybilne z plikami binarnymi, np. sprawdzając kompatybilne ustawienia czasu kompilacji, w tym 32/64-bitowe pliki binarne. Ważne jest również, aby zewnętrzne moduły były kompatybilne binarnie, chociaż nie można tego sprawdzić przez pg_upgrade.

pg_upgrade obsługuje aktualizacje z wersji 8.4.X i nowszych do bieżącej głównej wersji PostgreSQL, w tym wersje migawkowe i beta.

Oto sytuacja…

W tej konfiguracji użyłem ClusterControl do wdrożenia klastra bazy danych PostgreSQL 11 dla pojedynczego węzła. Poniższe zostały przetestowane na Centos 7 i 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)

Więc mam następujące,

Wersja serwera PostgreSQL: 11.13

Wersja bazy danych Timescale: 2.3.1

Wersja PostGIS: 3.1.4

Jeśli chcesz przetestować to za pomocą ClusterControl, istnieją dwa sposoby na posiadanie bazy danych TimescaleDB. Możesz wdrożyć klaster TimescaleDB lub mieć PostgreSQL i włączyć wtyczkę TimescaleDB.

Konfigurowanie PostgreSQL 13

Korzystanie z konfiguracji menedżera pakietów dla środowiska Linux z repozytorium PostgreSQL i TimescaleDB jest łatwiejsze. Oto kroki, aby to zrobić:

Skonfiguruj wymagane repozytoria

Najpierw dodajmy repozytorium PostgreSQL.

Dla CentOS/RHEL/Oracle Linux

Musisz upewnić się, że masz odpowiednie repozytorium. W przypadku Enterprise Linux (EL) 7 możesz wykonać następujące czynności:

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

Dla innych architektur możesz bazować tutaj https://download.postgresql.org/pub/repos/yum/reporpms/ i zastąpić podkatalog EL-7-x86_64.

Dodajmy również repozytorium TimescaleDB.

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

Następnie dodaj następującą zawartość tego pliku,

[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

Wystarczy odpowiednio zmienić bazowy adres URL, jeśli używasz wersji innej niż EL 7.

Dla Ubuntu/Debian

Dodaj repozytorium PG dla Ubuntu Focal:

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

W przypadku innych dystrybucji Ubuntu/Debian wystarczy odpowiednio zamienić focal, który można znaleźć tutaj http://apt.postgresql.org/pub/repos/apt/dists/. Na przykład zamień focal-pgdg na buster-pgdg.

Teraz dodajmy repozytorium dla 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"

Zaimportuj breloczek,

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

i zaktualizuj listy pakietów dla uaktualnień dla pakietów, które wymagają aktualizacji, a także nowych pakietów, które właśnie pojawiły się w repozytoriach.

sudo apt-get update

Możesz zastąpić podkatalog w adresie URL, jeśli używasz Debiana z Ubuntu.

Teraz, gdy mamy gotowe repozytorium, możemy ruszać.

Zainstaluj PostgreSQL w wersji 13 z TimescaleDB i PostGIS

Instalację PostgreSQL 13 można przeprowadzić na tym samym hoście. Po pierwsze, musisz upewnić się, że elementy takie jak port bazy danych są unikalne. Innymi słowy, musi się różnić od obecnego PostgreSQL 11 zainstalowanego na tym samym hoście.

Dla CentOS/RHEL/Oracle Linux

Uruchom poniższe polecenie, aby zainstalować PostgreSQL 13 i zależne od niego pakiety: 

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

Następnie zainicjuj klaster bazy danych i wymaganą kolekcję baz danych, uruchamiając poniższe polecenie:

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

W tym momencie powinny istnieć dwa katalogi danych zarówno dla PG 11, jak i 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

Teraz, gdy jesteśmy dobrzy z PostgreSQL 13, zainstalujmy TimescaleDB. Musimy się upewnić, że wtyczka do zainstalowania jest tej samej wersji na PostreSQL 11.

Pamiętaj, że aby mieć pewność, że pg_upgrade będzie działać bezproblemowo, wtyczki źródła i wersji głównej powinny być w tej samej wersji. Dzieje się tak, ponieważ pg_upgrade będzie szukał wyznaczonych bibliotek połączonych z wtyczkami lub rozszerzeniami, które zostały załadowane lub używane przez twoją starą lub źródłową wersję bazy danych PostgreSQL. Możesz to zweryfikować w swoim Enterprise Linux, uruchamiając showduplicates lub weryfikując za pomocą informacji, tak jak poniżej, za pomocą dnf lub 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

Lub zweryfikuj to za pomocą opcji informacji:

$ 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

Teraz jesteśmy gotowi do zainstalowania pakietu TimescaleDB dla wersji 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

Po zainstalowaniu możesz spróbować uruchomić narzędzie timescaledb-tune, aby dostroić plik konfiguracyjny postgresql.conf. Po prostu uruchom poniższe polecenie:

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

Teraz zainstalujmy również pakiet PostGIS dla wersji PG 13.

$ yum install -y postgis31_13.x86_64 

Dla Ubuntu/Debian

Po prostu uruchom:

$  apt install postgresql-client-13 postgresql-13

Wspaniałą rzeczą w dystrybucjach Ubuntu/Debian jest to, że istnieją narzędzia dla PostgreSQL, które są bardzo przydatne do zarządzania klastrami PostgreSQL, takie jak pg_lsclusters, pg_ctlcluster itp.

Możesz zweryfikować zainstalowane dostępne klastry.

$ 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

W Ubuntu/Debian nie ma potrzeby zmiany portu, ponieważ będzie on obsługiwany podczas fazy instalacji i odpowiednio wykrywa i ustawia go w unikalny sposób.

Teraz zainstalujmy TimescaleDB.

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

Opcjonalnie możesz uruchomić narzędzie timescaledb-tune, aby dostroić plik konfiguracyjny postgresql.conf, po prostu wywołując narzędzie w następujący sposób:

$ timescaledb-tune

Teraz jesteśmy gotowi do zainstalowania pakietu PostGIS dla PG 13.

$ apt install postgresql-13-postgis-3-scripts postgresql-13-postgis-3

Przejrzyj swój postgresql.conf

Zawsze lepiej przejrzeć plik konfiguracyjny postgresql.conf. W wersjach Enterprise Linux możesz zlokalizować plik postgresql.conf w ścieżce data_directory lub PGDATA. Natomiast w przypadku Ubuntu/Debian możesz go znaleźć w /etc/postgresql///postgresql.conf. Upewnij się, że w twoim postgresql.conf następujące wiersze są poprawnie skonfigurowane:

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.

Najlepszą praktyką jest porównywanie starych i nowych wersji plików konfiguracyjnych PostgreSQL, aby upewnić się, że plik postgresql.conf jest identyczny z wymaganym i ustawionym.

Przed przejściem do następnego kroku, musimy również sprawdzić, czy twoja wersja PostgreSQL 13 jest odpowiednio załadowana. Upewnij się, że masz najnowszą wersję nabytą lub zainstalowaną na hoście. Uruchom bazę danych i upewnij się, że uruchamia się i działa poprawnie.

Aby rozpocząć w dystrybucjach EL, uruchom poniższe polecenie:

$ 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

lub w przypadku Ubuntu/Debian uruchom poniższe polecenie:

$ 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

lub użyj narzędzia pg_ctlcluster, aby uruchomić, ponownie uruchomić lub zatrzymać klaster PG.

Gdy wszystko gotowe, uruchom pg_upgrade…

Zanim przejdziesz dalej, najpierw upewnij się, że zawsze masz gotową i dostępną kopię zapasową ze starego serwera. Zawsze stosuj logiczną i fizyczną kopię zapasową jako dobrą praktykę przed przystąpieniem do większej aktualizacji.

Teraz, kiedy jesteś gotowy, możesz uruchomić pg_upgrade. W praktyce, przed przejściem do głównej procedury pg_upgrade należy najpierw uruchomić pg_upgrade ze sprawdzeniem, aby określić niezgodność i problemy. Przed uruchomieniem pg_upgrade upewnij się, że zarówno PG 11, jak i PG 13 nie działają podczas wykonywania tego procesu. Oznacza to po prostu przestój w tym procesie.

W tym celu uruchom następujące polecenie z opcją --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

Zastąp odpowiednio wartość --old-datadir lub plik config_file, jeśli różni się od Twojej konfiguracji.

Spowoduje to uruchomienie sprawdzania zgodności, tak jak poniższy wynik:

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*

Jeśli wszystkie testy sygnalizują „ok”, oznacza to pomyślne sprawdzenie, a dolny komunikat pokazuje, że klastry są kompatybilne, powinieneś być gotowy.

Na koniec uruchom polecenie ponownie bez opcji --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

W zależności od rozmiaru zestawu danych może to zająć trochę czasu. W powyższym przykładzie polecenie kopiuje dzienniki transakcji, które są plikami fizycznymi. Jednakże, jeśli twój dysk jest mały, możesz użyć opcji -k lub --link, która używa twardych dowiązań. Jeśli wszystko pójdzie dobrze, powinieneś otrzymać komunikaty, takie jak powyższe, informujące o pełnej aktualizacji i powiadomienia o aktualizacji rozszerzeń, które możesz mieć. W tej konfiguracji wszystko idzie gładko. Plik update_extensions.sql zawiera tylko następujące elementy:

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

Jak zauważyłeś, pg_upgrade wykonuje szereg działań. Analizuje wszystkie wiersze z klastra źródłowego, kopiując dzienniki metadanych transakcji oraz dane o stanie wielu transakcji i resztę.

Gdy zorientujesz się, że wszystko wygląda dobrze, uruchom skrypt analysis_new_cluster.sh, który powinien uruchomić

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

Pamiętaj, że powinieneś określić port swojego PostgreSQL 13, aby próżniadb działała poprawnie na właściwym serwerze docelowym.

W tym przypadku wynik aktualizacji z włączonymi rozszerzeniami TimescaleDB i PostGIS idzie dobrze. Gdy wszystko pojawi się w porządku, uruchom serwer i wykonaj serię testów i sprawdzeń.

Przetestuj proces aktualizacji

Zawsze testuj i przeglądaj proces aktualizacji. Oto kilka tabel i zdefiniowana przez użytkownika baza danych, która zawiera hipertabele i tabele PostGIS, które opierają się na wykorzystaniu typów i funkcji przestrzennych geometrii i geografii.

$ 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)

Sprawdzam niektóre z moich PostGIS i hipertabel:

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)

Teraz wszystko wygląda na gotowe, by służyć jako mój nowy klaster.

Gdy już wszystko zacznie się działać, możesz uruchomić:

$ sudo -iu postgres ./delete_old_cluster.sh

Upewnij się, że uruchamiasz tylko skrypt, ponieważ jest to bardzo niebezpieczny skrypt, ponieważ usunie wszystkie pliki ze starego klastra PostgreSQL.

Wnioski

pg_upgrade to świetne narzędzie do zarządzania i uaktualniania serwera bazy danych PostgreSQL. Może obsługiwać złożone konfiguracje, takie jak włączone rozszerzenia TimescaleDB lub PostGIS. Chociaż to narzędzie ma swoje ograniczenia, nie można przestać go używać, szczególnie w przypadku pracy z administratorami baz danych i na serwerach produkcyjnych, z wyjątkiem środowisk QA i programistycznych.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Połącz się ze zdalną bazą danych PostgreSql za pomocą Powershell

  2. Użytkownik Postgresa nie istnieje?

  3. Jak wykonać operacje aktualizacji na kolumnach typu JSONB w Postgresie 9.4?

  4. Rekurencyjne CTE łączą pola z rodzicami z dowolnego punktu

  5. Zapomniałem hasła, które wprowadziłem podczas instalacji postgres