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/
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.