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

Pierwsze kroki z Postgresem 13 na Ubuntu 20.04

PostgreSQL 13, najnowsza wersja oprogramowania bazy danych Postgres, zawiera wiele ukrytych ulepszeń. Chociaż jest najpopularniejszym i najbardziej wszechstronnym RDBMS typu open source, nie jest najłatwiejszy w konfiguracji i rozpoczęciu pracy. Czytaj dalej, aby dowiedzieć się, jak możesz zacząć korzystać z najnowszej wersji Postgres na najnowszej wersji LTS Ubuntuserver.

Instalacja

Ubuntu 20.04 zawiera Postgres 12 ze swojego wszechświata magazyn. Ponieważ chcemy wersji 13, możemy bezpośrednio użyć oficjalnego repozytorium APT projektu PostgreSQL. To repozytorium zawiera binaria dla Ubuntu 20.04, a także zawiera pakiety dla różnych rozszerzeń, które możesz chcieć zainstalować później.

Skonfigurujmy repozytorium w ten sposób (zauważ, że „focal” to nazwa kodowa Ubuntu 20.04):

# add the repository
sudo tee /etc/apt/sources.list.d/pgdg.list <<END
deb http://apt.postgresql.org/pub/repos/apt/ focal-pgdg main
END

# get the signing key and import it
wget https://www.postgresql.org/media/keys/ACCC4CF8.asc
sudo apt-key add ACCC4CF8.asc

# fetch the metadata from the new repo
sudo apt-get update

Możemy teraz zainstalować serwer PostgreSQL i inne narzędzia wiersza poleceń za pomocą:

sudo apt-get install -y postgresql-13

Instalacja robi kilka rzeczy:

  • Instaluje serwer PostgreSQL, narzędzia i klienta wiersza poleceń o nazwie psql .
  • Tworzy użytkownika systemu Linux o nazwie postgres . Wszystkie pliki danych są własnością tego użytkownika, a wszystkie procesy działają jako ten użytkownik.
  • Tworzy klaster bazy danych (patrz poniżej). W tym klastrze tworzy bazę danych, zwaną także postgresem .
  • Tworzy jednego użytkownika PostgreSQL (nie użytkownik systemu Linux), zwany także postgresem . Ten użytkownik PostgreSQL ma uprawnienia superużytkownika.

Widać, że zaczyna to być zagmatwane!

Klastry baz danych

Jeśli chodzi o Postgres, mamy teraz działający jeden klaster bazy danych. Pojedynczy klaster baz danych może zawierać jedną lub więcej baz danych. W klastrze baz danych, który mamy teraz, znajduje się baza danych o nazwie „postgres”. (Istnieje również kilka baz danych „szablonów”, które możemy na razie zignorować.)

Klaster bazy danych jest zarządzany przez główny proces postgres zwany postmaster .Tworzy różne procesy potomne, które wykonują różne zadania systemowe lub obsługują przychodzące połączenia klientów. Spójrz na aktualnie uruchomione procesy:

alice@ubu:~$ ps -o uname,pid,ppid,cmd -H -U postgres
USER         PID    PPID CMD
postgres    4880       1 /usr/lib/postgresql/13/bin/postgres -D /var/lib/postgresql/13/main -c config_file=/etc/postgresql/13/main/postgresql.conf
postgres    4882    4880   postgres: 13/main: checkpointer
postgres    4883    4880   postgres: 13/main: background writer
postgres    4884    4880   postgres: 13/main: walwriter
postgres    4885    4880   postgres: 13/main: autovacuum launcher
postgres    4886    4880   postgres: 13/main: stats collector
postgres    4887    4880   postgres: 13/main: logical replication launcher

Tutaj proces postmaster to 4880 i zrodził 6 procesów podrzędnych, które obsługują różne czynności porządkowe. Możesz także zobaczyć lokalizację klastra (/var/lib/postgresql/13/main ) i lokalizację pliku konfiguracyjnego (/etc/postgresql/13/main/postgresql.conf ).

Ponowne ładowanie i ponowne uruchamianie

Czasami może być konieczne przeładowanie lub uruchom ponownie Twój serwer Postgres. Ponowne ładowanie powoduje, że Postgres ponownie sprawdza swoje pliki konfiguracyjne i stosuje zmiany. Jeśli nie ma zmian w plikach konfiguracyjnych, nic złego się nie dzieje. Ponowne ładowanie nie przeszkadza aktualnie podłączonym klientom. Aby ponownie załadować serwer Postgres, możesz:

sudo systemctl reload postgresql

Niektóre zmiany konfiguracji zaczną obowiązywać dopiero po ponownym uruchomieniu serwera. Jest to bardziej uciążliwe i powoduje rozłączenie wszystkich podłączonych klientów. Aby ponownie uruchomić, możesz:

sudo systemctl restart postgresql

Pliki dziennika

Jak widać, istnieje usługa systemd o nazwie postgresql które możesz wykorzystać do kontrolowania poczmistrza. Jeśli usługa się nie uruchamia, możesz sprawdzić jej stan, aby sprawdzić komunikaty o błędach:

alice@ubu:~$ sudo systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
     Active: active (exited) since Thu 2020-10-29 04:52:29 UTC; 25min ago
   Main PID: 4557 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 1075)
     Memory: 0B
     CGroup: /system.slice/postgresql.service

Oct 29 04:52:29 ubu systemd[1]: Starting PostgreSQL RDBMS...
Oct 29 04:52:29 ubu systemd[1]: Finished PostgreSQL RDBMS.

Serwer PostgreSQL zapisuje plik dziennika, w którym możesz sprawdzić bardziej szczegółowe komunikaty o błędach. Ten plik znajduje się w /var/log/postgresql/postgresql-13-main.log :

alice@ubu:~$ cat /var/log/postgresql/postgresql-13-main.log
2020-10-29 04:52:34.096 UTC [4880] LOG:  starting PostgreSQL 13.0 (Ubuntu 13.0-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, 64-bit
2020-10-29 04:52:34.097 UTC [4880] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2020-10-29 04:52:34.099 UTC [4880] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2020-10-29 04:52:34.106 UTC [4881] LOG:  database system was shut down at 2020-10-29 04:52:31 UTC
2020-10-29 04:52:34.112 UTC [4880] LOG:  database system is ready to accept connections

Łączenie z serwerem Postgres

Teraz, gdy mamy już działający serwer, spróbujmy się z nim połączyć. Domyślnie serwer nasłuchuje tylko:

  • Połączenia TCP z 127.0.0.1 na porcie 5432 i
  • Gniazda domeny uniksowej w /var/run/postgresql

Ze względu na domyślną konfigurację, jedynym sposobem na połączenie się z serwerem jest teraz poprzez gniazdo Unix z procesu działającego jako użytkownik systemowy postgres . Uruchommy standardowego klienta interaktywnego psql podobnie:

alice@ubu:~$ sudo -u postgres psql postgres
psql (13.0 (Ubuntu 13.0-1.pgdg20.04+1))
Type "help" for help.

postgres=#

Tutaj uruchamiamy psql jako postgres użytkownika systemowego („sudo -u postgres psql”) i łączymy się z bazą danych o nazwie „postgres” (ostatni „postgres” w wierszu poleceń). nazwa aktualnie połączonej bazy danych („postgres”) i czy mamy uprawnienia superużytkownika („#” w przeciwieństwie do „$”).

Połączenie odbywało się przez gniazda Unix (jest to domyślna metoda w psql). Ponieważ domyślnie użytkownik postgres nie ma hasła, a domyślna konfiguracja wymaga uwierzytelnienia hasłem dla połączeń TCP, nie można teraz połączyć się przez 127.0.0.1:5432 .

Zezwalanie na połączenia przychodzące z sieci wewnętrznej

Najpierw zmieńmy konfigurację, aby umożliwić połączenia z sieci wewnętrznej. Zakładając, że adres IP naszego serwera w tej sieci to 10.1.2.3, możemy edytować główny plik konfiguracyjny w /etc/postgresql/13/main/postgresql.conf i zmień linie:

#listen_addresses = 'localhost'         # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost'; use '*' for all

do:

listen_addresses = 'localhost,10.1.2.3'

Musimy również powiedzieć Postgresowi, aby używał uwierzytelniania hasła dla połączeń przychodzących z tych sieci. W tym celu edytuj inny plik konfiguracyjny o nazwie /etc/postgresql/13/main/pg_hba.conf i zmień linię:

host    all             all             127.0.0.1/32            md5

do:

host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             10.1.0.0/16             scram-sha-256

(Zakładając, że sieć wewnętrzna to 10.1.0.0/16.)

Zmieniliśmy również domyślny md5 metoda na nowszą i bezpieczniejsząscram-sha-256 . Wszystkie inne wystąpienia md5 w pliku należy również zastąpić scram-sha-256 . Jeśli Twoja aplikacja lub sterownik bazy danych nie obsługuje tej metody, nadal używaj md5 zamiast tego.

Aby zmiany zaczęły obowiązywać, musisz ponownie uruchomić serwer:

sudo systemctl restart postgresql

Tworzenie zwykłego użytkownika i bazy danych

Już prawie jesteśmy!

Możemy teraz stworzyć zwykłego użytkownika, z którym nasza aplikacja może się łączyć, oraz bazę danych, nad którą ma pełną kontrolę. Połącz się jako superużytkownik postgres lokalnie z serwera, aby to zrobić:

alice@ubu:~$ sudo -u postgres psql postgres
psql (13.0 (Ubuntu 13.0-1.pgdg20.04+1))
Type "help" for help.

postgres=# SET password_encryption = 'scram-sha-256';
SET
postgres=# CREATE USER alice PASSWORD 's3cr3tp@ss';
CREATE ROLE
postgres=#

(Pomiń pierwsze polecenie, jeśli chcesz użyć md5 zamiast tego). Spowodowało to utworzenie użytkownika o nazwie alice z hasłem s3cr3tp@ss . Stwórzmy również bazę danych, której właścicielem będzie ten użytkownik:

postgres=# CREATE DATABASE app1 OWNER alice;
CREATE DATABASE
postgres=#

Baza danych nazywa się app1 . Od alicji jest właścicielem tej bazy danych, wszystkie operacje w bazie danych (takie jak tworzenie tabel, wstawianie wierszy) są dozwolone, jeśli aplikacja łączy się jako użytkownik alice .

Spróbujmy połączyć się jako alice , przez sieć:

~$ psql -h 10.1.2.3 -U alice app1
Password for user alice:
psql (13.0 (Ubuntu 13.0-1.pgdg20.04+1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

app1=>

Fajny! Jesteśmy teraz połączeni z bazą danych app1 jako użytkownik alicja .

Usuwanie baz danych, tworzenie kopii zapasowych i przywracanie

Oto kilka sztuczek, które mogą pomóc w dalszej pracy z serwerem Postgresserver:

Usuwanie bazy danych

Możesz usunąć właśnie utworzoną bazę danych („app1”) w następujący sposób:

alice@ubu:~$ psql -h 127.0.0.1 -U alice app1
Password for user alice:
psql (13.0 (Ubuntu 13.0-1.pgdg20.04+1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

app1=> \c postgres
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
You are now connected to database "postgres" as user "alice".
postgres=> DROP DATABASE app1;
DROP DATABASE
postgres=>

Pamiętaj, że musisz najpierw przełączyć się do innej bazy danych za pomocą polecenia „\c” w psql.

Aby utworzyć kolejną bazę danych lub odtworzyć aplikację1 , połącz się jako superużytkownik i wykonaj „UTWÓRZ BAZĘ DANYCH” jak poprzednio.

Utwórz kopię zapasową bazy danych

Najprostszym sposobem na wykonanie kopii zapasowej danych w bazie danych jest użycie pg_dump podobnie:

alice@ubu:~$ pg_dump -h 127.0.0.1 -U alice -f backup.sql app1
Password:

Spowoduje to utworzenie pliku SQL o nazwie „backup.sql”, który zawiera wszystkie polecenia SQL wymagane do odtworzenia schematu i danych w bazie danych app1 , w formacie tekstowym. Możesz wykonać te polecenia w dowolnej bazie danych, a schemat i dane zostaną wprowadzone do tej bazy danych.

Przeczytaj więcej o pg_dump tutaj.

Przywracanie danych

Utworzony powyżej plik poleceń SQL można przywrócić w następujący sposób:

alice@ubu:~$ psql -h 127.0.0.1 -U alice app2
Password for user alice:
psql (13.0 (Ubuntu 13.0-1.pgdg20.04+1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

app2=> \i backup.sql
SET
SET
(..snip..)

Pamiętaj, że przywróciliśmy schemat i dane do innej bazy danych, app2 . Polecenie „\i” w psql umożliwia wykonywanie poleceń SQL z pliku.

Dalsze kroki

Istnieje cała masa artykułów, samouczków, filmów i kursów, które pomogą Ci lepiej posługiwać się PostgreSQL. Poświęć jednak trochę czasu, zapoznaj się z oficjalną dokumentacją, która zapewnia wiarygodne i obszerne omówienie wszystkich funkcji PostgreSQL, składni i dołączonych narzędzi.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Przywracanie kopii zapasowych PostgreSQL i TimescaleDB za pomocą ClusterControl CLI

  2. Programowo wyprodukuj obiekt `DataSource` dla Postgres JDBC

  3. Postgresql DROP TABLE nie działa

  4. Tabele tymczasowe PostgreSQL

  5. Czy usunięcie bazy danych nie musi odbywać się w żadnej transakcji?