Gdzie zacząć?
Najlepszym miejscem, jakie mogłem znaleźć na początek, była oficjalna dokumentacja. Istnieje również kanał GCP Youtube dla tych, którzy preferują multimedia. Gdy znalazłem się w krainie dokumentacji Cloud SQL, zwróciłem się do Concepts, gdzie obiecano nam „opracować głębokie zrozumienie” produktu.
Więc zacznijmy!
Funkcje PostgreSQL Google Cloud
Google Cloud SQL dla PostgreSQL oferuje wszystkie standardowe funkcje, jakich można oczekiwać od rozwiązania zarządzanego:wysoką dostępność z automatycznym przełączaniem awaryjnym, automatyczne tworzenie kopii zapasowych, szyfrowanie w stanie spoczynku i podczas przesyłania, zaawansowane rejestrowanie i monitorowanie oraz oczywiście bogaty interfejs API do interakcji ze wszystkimi usługami.
I trochę historii, wsparcie PostgreSQL rozpoczęło się w marcu 2017, do tego czasu jedynym obsługiwanym silnikiem bazy danych był MySQL.
Cloud SQL uruchamia PostgreSQL na platformie obliczeniowej Google drugiej generacji. Pełna lista funkcji dostępna jest tutaj oraz tutaj. Przeglądając to pierwsze, widać wyraźnie, że nigdy nie istniała platforma pierwszej generacji dla PostgreSQL.
Oczekuje się, że bazy danych działające na platformie drugiej generacji będą działać z prędkością 7 razy większą i korzystać z 20 razy większej pojemności pamięci masowej. Blog zapowiadający platformę drugiej generacji omawia szczegóły uruchomienia testu sysbench w celu porównania Google Cloud SQL z ówczesnym głównym konkurentem AWS w obu wcieleniach RDS i Aurora. Wyniki mnie zaskoczyły, ponieważ pokazują lepszą wydajność Cloud SQL, podczas gdy ostatnie testy przeprowadzone przy użyciu AWS Benchmark opublikowanego około rok później wykazały coś przeciwnego. Mniej więcej w tym samym czasie, kiedy dostępna była obsługa PostgreSQL. Chociaż nie mogę się doczekać pomysłu samodzielnego uruchomienia testu porównawczego, zgaduję, że istnieją dwa potencjalne czynniki, które mogły wpłynąć na wyniki:test sysbench Google używał różnych parametrów, a AWS mógł w tym czasie ulepszyć swoje produkty.
Kompatybilność GCP z PostgreSQL
Zgodnie z oczekiwaniami Google Cloud SQL dla PostgreSQL jest prawie bezpośrednim zamiennikiem wersji społecznościowej i obsługuje wszystkie języki proceduralne PL/pgSQL SQL.
Niektóre funkcje są niedostępne ze względów bezpieczeństwa, na przykład dostęp SUPERUSER. Inne funkcje zostały usunięte ze względu na potencjalne ryzyko związane ze stabilnością i wydajnością produktu. Wreszcie, niektórych opcji i parametrów nie można zmienić, chociaż prośby o zmianę tego zachowania można zgłaszać za pośrednictwem grupy dyskusyjnej Cloud SQL.
Cloud SQL jest również kompatybilny z protokołem PostgreSQL.
Jeśli chodzi o izolację transakcji, Cloud SQL postępuje zgodnie z domyślnym zachowaniem PostgreSQL, domyślnie na poziomie izolacji Read Committed.
W przypadku niektórych parametrów konfiguracyjnych serwera Cloud SQL implementuje różne zakresy z powodów niewyjaśnionych w dokumentacji, co jest nadal ważną rzeczą do zapamiętania.
Sieć
Istnieje wiele sposobów łączenia się z bazą danych, w zależności od tego, czy instancja znajduje się w sieci prywatnej czy publicznej (aplikacje łączące się z zewnątrz GCP). Wspólne dla obu przypadków jest predefiniowana sieć VPC zarządzana przez Google, w której znajdują się wszystkie instancje bazy danych Cloud SQL.
Prywatny adres IP
Klienci łączący się z prywatnym adresem IP są kierowani przez połączenie równorzędne między VPC hostującym klienta i odpowiednio instancją bazy danych. Chociaż nie jest to specyficzne dla PostgreSQL, ważne jest, aby przejrzeć wymagania sieciowe, aby uniknąć problemów z połączeniem. Jedna uwaga:po włączeniu nie można usunąć prywatnego adresu IP.
Łączenie z zewnętrznych aplikacji
Połączenia z aplikacji hostowanych poza GCP mogą i powinny być szyfrowane. Dodatkowo, aby uniknąć różnych ataków, połączenia klienckie i aplikacja muszą zainstalować dostarczony certyfikat klienta. Procedura generowania i konfigurowania certyfikatów jest nieco skomplikowana, wymaga niestandardowych narzędzi, aby zapewnić okresowe odnawianie certyfikatów. To może być jeden z powodów, dla których Google oferuje opcję korzystania z Cloud SQL Proxy.
Łączenie za pomocą serwera proxy Cloud SQL
Konfiguracja jest dość prosta, co w rzeczywistości, jak stwierdziłem, dotyczy wszystkich instrukcji w dokumentacji Google Cloud SQL. W związku z tym przesyłanie opinii o dokumentacji jest bardzo proste, a funkcja zrzutów ekranu była dla mnie pierwszą.
Istnieje wiele sposobów autoryzacji połączeń proxy i zdecydowałem się skonfigurować konto usługi, tak jak opisano w dokumentacji Cloud SQL Proxy.
Gdy wszystko będzie gotowe, czas uruchomić proxy:
~/usr/local/google $ ./cloud_sql_proxy -instances=omiday:us-west1:s9s201907141919=tcp:5432 -credential_file=omiday-427c34fce588.json
2019/07/14 21:22:43 failed to setup file descriptor limits: failed to set rlimit {&{8500 4096}} for max file descriptors: invalid argument
2019/07/14 21:22:43 using credential file for authentication; [email protected]
2019/07/14 21:22:43 Listening on 127.0.0.1:5432 for omiday:us-west1:s9s201907141919
2019/07/14 21:22:43 Ready for new connectionsAby połączyć się ze zdalną instancją, używamy teraz proxy, określając localhost zamiast publicznego adresu IP instancji:
~ $ psql "user=postgres dbname=postgres password=postgres hostaddr=127.0.0.1"
Pager usage is off.
psql (11.4, server 9.6.11)
Type "help" for help.Pamiętaj, że nie ma szyfrowania, ponieważ łączymy się lokalnie, a proxy zajmuje się szyfrowaniem ruchu przepływającego do chmury.
Częstym zadaniem DBA jest przeglądanie połączeń z bazą danych przez zapytanie pg_stat_activity. Dokumentacja stwierdza, że połączenia proxy będą wyświetlane jako cloudqlproxy~1.2.3.4, więc chciałem zweryfikować to twierdzenie. Otworzyłem dwie sesje jako postgres, jedną przez proxy, a drugą z mojego adresu domowego, więc wystarczy następujące zapytanie:
[email protected]:5432 postgres> select * from pg_stat_activity where usename = 'postgres';
-[ RECORD 1 ]----+-----------------------------------------------------------
datid | 12996
datname | postgres
pid | 924
usesysid | 16389
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2019-07-15 04:25:37.614205+00
xact_start | 2019-07-15 04:28:43.477681+00
query_start | 2019-07-15 04:28:43.477681+00
state_change | 2019-07-15 04:28:43.477684+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 8229
query | select * from pg_stat_activity where usename = 'postgres';
-[ RECORD 2 ]----+-----------------------------------------------------------
datid | 12996
datname | postgres
pid | 946
usesysid | 16389
usename | postgres
application_name | psql
client_addr | <MY_HOME_IP_ADDRESS>
client_hostname |
client_port | 60796
backend_start | 2019-07-15 04:27:50.378282+00
xact_start |
query_start |
state_change | 2019-07-15 04:27:50.45613+00
wait_event_type |
wait_event |
state | idle
backend_xid |
backend_xmin |
query |Wygląda na to, że połączenia proxy są zamiast tego identyfikowane jako client_port ==-1 i pusty client_addr. Można to dodatkowo potwierdzić, porównując sygnatury czasowe dla backend_start i dziennika proxy poniżej:
2019/07/14 21:25:37 New connection for "omiday:us-west1:s9s201907141919"Wysoka dostępność PostgreSQL w Google Cloud
Google Cloud SQL dla PostgreSQL zapewnia wysoką dostępność dzięki synchronizacji danych na niskim poziomie w pamięci masowej za pomocą regionalnych dysków stałych. Przełączenie awaryjne jest automatyczne, z interwałem sprawdzania pulsu wynoszącym jedną sekundę, a przełączenie awaryjne jest wyzwalane po około 60 sekundach.
Wydajność i monitorowanie
Sekcja dokumentacji dotycząca wydajności wskazuje ogólne zasady dotyczące chmury:trzymaj bazę danych (zarówno repliki piszące, jak i czytające) blisko aplikacji i skaluj instancję w pionie. Wyróżnia się zalecenie zapewnienia instancji z co najmniej 60 GB pamięci RAM, gdy ważna jest wydajność.
Stackdriver zapewnia monitorowanie i logowanie, a także dostęp do logów PostgreSQL:
Kontrola dostępu
Jest to zaimplementowane na poziomie projektu, instancji i bazy danych.
Kontrola dostępu do projektu
Kontrola dostępu do projektu to kontrola dostępu specyficzna dla chmury — wykorzystuje koncepcję ról uprawnień, aby umożliwić członkom projektu (użytkownikom, grupom lub kontom usług) dostęp do różnych zasobów Cloud SQL. Lista ról jest dość oczywista, szczegółowy opis każdej roli i powiązanych uprawnień można znaleźć w APIs Explorer lub Cloud SQL Admin API dla jednego z obsługiwanych języków programowania.
Aby zademonstrować, jak działają role uprawnień, utwórz konto usługi tylko do odczytu (przeglądającego):
Uruchom nową instancję serwera proxy na porcie 5433 przy użyciu konta usługi powiązanego z rola widza:
~/usr/local/google $ ./cloud_sql_proxy -instances=omiday:us-west1:s9s201907141919=tcp:5433 -credential_file=omiday-4508243deca9.json
2019/07/14 21:49:56 failed to setup file descriptor limits: failed to set rlimit {&{8500 4096}} for max file descriptors: invalid argument
2019/07/14 21:49:56 using credential file for authentication; [email protected]
2019/07/14 21:49:56 Listening on 127.0.0.1:5433 for omiday:us-west1:s9s201907141919
2019/07/14 21:49:56 Ready for new connectionsOtwórz połączenie psql z 127.0.0.1:5433:
~ $ psql "user=postgres dbname=postgres password=postgres hostaddr=127.0.0.1 port=5433"Polecenie kończy się za pomocą:
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.Ups! Sprawdźmy logi proxy:
2019/07/14 21:50:33 New connection for "omiday:us-west1:s9s201907141919"
2019/07/14 21:50:33 couldn't connect to "omiday:us-west1:s9s201907141919": ensure that the account has access to "omiday:us-west1:s9s201907141919" (and make sure there's no typo in that name). Error during createEphemeral for omiday:us-west1:s9s201907141919: googleapi: Error 403: The client is not authorized to make this request., notAuthorizedKontrola dostępu do instancji
Dostęp na poziomie instancji zależy od źródła połączenia:
Połączenie metod autoryzacji zastępuje wszechobecny pg_hba.conf.
Kopia zapasowa i odzyskiwanie
Domyślnie automatyczne kopie zapasowe są włączone:
Podczas gdy kopie zapasowe nie wpływają na operacje odczytu i zapisu bazy danych, mają wpływ na wydajność dlatego zaleca się planowanie tworzenia kopii zapasowych w okresach mniejszej aktywności.
W celu zapewnienia nadmiarowości kopie zapasowe mogą być przechowywane w dwóch regionach (obowiązują dodatkowe opłaty) z opcją wyboru niestandardowych lokalizacji.
Aby zaoszczędzić miejsce na dysku, użyj kompresji. Skompresowane pliki .gz są przywracane w sposób przezroczysty.
Cloud SQL obsługuje również klonowanie instancji. W przypadku najmniejszego zestawu danych operacja zajęła około 3 minut:
Czas rozpoczęcia klonowania 10:07:10:
Dzienniki PostgreSQL pokazują, że PostgreSQL stał się dostępny na sklonowanej instancji o godzinie 10:10:47:
To wciąż prostszy sposób tworzenia kopii niż tworzenie kopii zapasowej i przywracanie instancji do celów testowania, programowania lub rozwiązywania problemów.
Najlepsze praktyki Google Cloud dla PostgreSQL
- Skonfiguruj politykę aktywacji dla instancji, które nie muszą działać 24/7.
- Umieść instancję bazy danych w tej samej strefie lub regionie, co instancje Compute Engine i aplikacje App Engine, aby uniknąć opóźnień w sieci.
- Utwórz instancję bazy danych w tej samej strefie co Compute Engine. Jeśli używasz innego typu połączenia, zaakceptuj strefę domyślną.
- Użytkownicy utworzeni przy użyciu Cloud SQL są domyślnie superużytkownikami chmury. Użyj PostgreSQL ALTER ROLE, aby zmienić ich uprawnienia.
- Użyj najnowszej wersji serwera proxy Cloud SQL.
- Nazwy instancji powinny zawierać znacznik czasu, aby móc ponownie użyć nazwy podczas usuwania i odtwarzania instancji.
- pg_dump domyślnie uwzględnia duże obiekty. Jeśli baza danych zawiera obiekty BLOB-y, wykonaj zrzut w okresach niskiej aktywności, aby zapobiec przestawaniu odpowiedzi instancji.
- Użyj gcloud sql connect, aby szybko połączyć się z klienta zewnętrznego bez konieczności umieszczania adresu IP klienta na białej liście.
- Zapisz się, aby ogłaszać grupę, aby otrzymywać powiadomienia o aktualizacjach produktów i alerty, takie jak problemy podczas tworzenia instancji:
- Upewnij się, że aplikacje wdrażają techniki zarządzania połączeniami z bazą danych.
- Instancje zatrzymane na dłużej niż 90 dni zostaną usunięte, chyba że nie są w stanie zawieszenia.
- Wykonaj ręczne przełączanie awaryjne, aby przetestować zachowanie aplikacji i długość przestoju.
- Użyj domyślnej wersji silnika.
- Przestrzeń dyskowa dla instancji skonfigurowanych do automatycznego zwiększania pamięci będzie rosła o 25 GB. Ponieważ miejsca do przechowywania nie można odzyskać, ustaw limit wzrostu szacowanego rozmiaru bazy danych w następnym cyklu budżetowym i monitoruj niekontrolowane zapytania,
- Użyj „wcześniejszego” harmonogramu konserwacji dla instancji testowych:
- Aplikacje powinny używać aktywnych połączeń i wykładniczego wycofywania, aby szybko odzyskać sprawność po ponownym uruchomieniu instancji.
- Aplikacja polegająca na replikach do odczytu powinna rozważyć użycie 3 replik, aby uniknąć problemów spowodowanych awarią regionalnych dysków trwałych prowadzących do niedostępności obu replik.
- Skonfiguruj repliki do odczytu, aby poprawić wydajność odczytu.
- Ponowne uruchomienie instancji jest wymagane podczas aktualizowania listy adresów IP, które mają dostęp do publicznej instancji w celu rozłączenia istniejących połączeń.
- Przejrzyj dedykowaną grupę StackOverflow Cloud SQL, aby uzyskać dodatkowe informacje.
Lista kontrolna uruchamiania Cloud SQL
Sekcja z listą kontrolną w dokumentacji zawiera przegląd zalecanych działań podczas konfigurowania gotowej do produkcji instancji Cloud SQL dla PostgreSQL. W szczególności aplikacje muszą być zaprojektowane do obsługi ponownego uruchamiania Cloud SQL. Ponadto, chociaż nie ma limitów zapytań na sekundę, istnieją limity połączeń.
Obsługa rozszerzeń GCP PostgreSQL
Cloud SQL obsługuje większość rozszerzeń PostgreSQL. W chwili pisania tego tekstu z 52 rozszerzeń społeczności są 22 nieobsługiwane rozszerzenia i 2 nieobsługiwane rozszerzenia PostGIS.
postgis_raster
postgis_sfcgalW przypadku rozszerzeń PostgreSQL możemy albo przejrzeć repozytorium wpisów PostgreSQL, albo lepiej, porównać dane wyjściowe z pg_available_extensions:
W górę:
~ $ psql -U postgres -p 54396
Pager usage is off.
psql (11.4, server 9.6.14)
Type "help" for help.
[email protected][local]:54396 postgres# select * from pg_available_extensions order by name;
name | default_version | installed_version | comment
--------------------+-----------------+-------------------+----------------------------------------------------------------------
adminpack | 1.1 | | administrative functions for PostgreSQL
autoinc | 1.0 | | functions for autoincrementing fields
bloom | 1.0 | | bloom access method - signature file based index
btree_gin | 1.0 | | support for indexing common datatypes in GIN
btree_gist | 1.2 | | support for indexing common datatypes in GiST
chkpass | 1.0 | | data type for auto-encrypted passwords
citext | 1.3 | | data type for case-insensitive character strings
cube | 1.2 | | data type for multidimensional cubes
dblink | 1.2 | | connect to other PostgreSQL databases from within a database
dict_int | 1.0 | | text search dictionary template for integers
dict_xsyn | 1.0 | | text search dictionary template for extended synonym processing
earthdistance | 1.1 | | calculate great-circle distances on the surface of the Earth
file_fdw | 1.0 | | foreign-data wrapper for flat file access
fuzzystrmatch | 1.1 | | determine similarities and distance between strings
hstore | 1.4 | | data type for storing sets of (key, value) pairs
hstore_plperl | 1.0 | | transform between hstore and plperl
hstore_plperlu | 1.0 | | transform between hstore and plperlu
hstore_plpython2u | 1.0 | | transform between hstore and plpython2u
hstore_plpythonu | 1.0 | | transform between hstore and plpythonu
insert_username | 1.0 | | functions for tracking who changed a table
intagg | 1.1 | | integer aggregator and enumerator (obsolete)
intarray | 1.2 | | functions, operators, and index support for 1-D arrays of integers
isn | 1.1 | | data types for international product numbering standards
lo | 1.1 | | Large Object maintenance
ltree | 1.1 | | data type for hierarchical tree-like structures
ltree_plpython2u | 1.0 | | transform between ltree and plpython2u
ltree_plpythonu | 1.0 | | transform between ltree and plpythonu
moddatetime | 1.0 | | functions for tracking last modification time
pageinspect | 1.5 | | inspect the contents of database pages at a low level
pg_buffercache | 1.2 | | examine the shared buffer cache
pg_freespacemap | 1.1 | | examine the free space map (FSM)
pg_prewarm | 1.1 | | prewarm relation data
pg_stat_statements | 1.4 | | track execution statistics of all SQL statements executed
pg_trgm | 1.3 | | text similarity measurement and index searching based on trigrams
pg_visibility | 1.1 | | examine the visibility map (VM) and page-level visibility info
pgcrypto | 1.3 | | cryptographic functions
pgrowlocks | 1.2 | | show row-level locking information
pgstattuple | 1.4 | | show tuple-level statistics
plpgsql | 1.0 | 1.0 | PL/pgSQL procedural language
postgres_fdw | 1.0 | | foreign-data wrapper for remote PostgreSQL servers
refint | 1.0 | | functions for implementing referential integrity (obsolete)
seg | 1.1 | | data type for representing line segments or floating-point intervals
sslinfo | 1.2 | | information about SSL certificates
tablefunc | 1.0 | | functions that manipulate whole tables, including crosstab
tcn | 1.0 | | Triggered change notifications
timetravel | 1.0 | | functions for implementing time travel
tsearch2 | 1.0 | | compatibility package for pre-8.3 text search functions
tsm_system_rows | 1.0 | | TABLESAMPLE method which accepts number of rows as a limit
tsm_system_time | 1.0 | | TABLESAMPLE method which accepts time in milliseconds as a limit
unaccent | 1.1 | | text search dictionary that removes accents
uuid-ossp | 1.1 | | generate universally unique identifiers (UUIDs)
xml2 | 1.1 | | XPath querying and XSLTCloud SQL:
[email protected]:5432 postgres> select * from pg_available_extensions where name !~ '^postgis' order by name;
name | default_version | installed_version | comment
--------------------+-----------------+-------------------+--------------------------------------------------------------------
bloom | 1.0 | | bloom access method - signature file based index
btree_gin | 1.0 | | support for indexing common datatypes in GIN
btree_gist | 1.2 | | support for indexing common datatypes in GiST
chkpass | 1.0 | | data type for auto-encrypted passwords
citext | 1.3 | | data type for case-insensitive character strings
cube | 1.2 | | data type for multidimensional cubes
dict_int | 1.0 | | text search dictionary template for integers
dict_xsyn | 1.0 | | text search dictionary template for extended synonym processing
earthdistance | 1.1 | | calculate great-circle distances on the surface of the Earth
fuzzystrmatch | 1.1 | | determine similarities and distance between strings
hstore | 1.4 | | data type for storing sets of (key, value) pairs
intagg | 1.1 | | integer aggregator and enumerator (obsolete)
intarray | 1.2 | | functions, operators, and index support for 1-D arrays of integers
isn | 1.1 | | data types for international product numbering standards
lo | 1.1 | | Large Object maintenance
ltree | 1.1 | | data type for hierarchical tree-like structures
pg_buffercache | 1.2 | | examine the shared buffer cache
pg_prewarm | 1.1 | | prewarm relation data
pg_stat_statements | 1.4 | | track execution statistics of all SQL statements executed
pg_trgm | 1.3 | | text similarity measurement and index searching based on trigrams
pgcrypto | 1.3 | | cryptographic functions
pgrowlocks | 1.2 | | show row-level locking information
pgstattuple | 1.4 | | show tuple-level statistics
plpgsql | 1.0 | 1.0 | PL/pgSQL procedural language
sslinfo | 1.2 | | information about SSL certificates
tablefunc | 1.0 | | functions that manipulate whole tables, including crosstab
tsm_system_rows | 1.0 | | TABLESAMPLE method which accepts number of rows as a limit
tsm_system_time | 1.0 | | TABLESAMPLE method which accepts time in milliseconds as a limit
unaccent | 1.1 | | text search dictionary that removes accents
uuid-ossp | 1.1 | | generate universally unique identifiers (UUIDs)Nieobsługiwane rozszerzenia w Cloud SQL:
adminpack 1.1 administrative functions for PostgreSQL
autoinc 1.0 functions for autoincrementing fields
dblink 1.2 connect to other PostgreSQL databases from within a database
file_fdw 1.0 foreign-data wrapper for flat file access
hstore_plperl 1.0 transform between hstore and plperl
hstore_plperlu 1.0 transform between hstore and plperlu
hstore_plpython2u 1.0 transform between hstore and plpython2u
hstore_plpythonu 1.0 transform between hstore and plpythonu
insert_username 1.0 functions for tracking who changed a table
ltree_plpython2u 1.0 transform between ltree and plpython2u
ltree_plpythonu 1.0 transform between ltree and plpythonu
moddatetime 1.0 functions for tracking last modification time
pageinspect 1.5 inspect the contents of database pages at a low level
pg_freespacemap 1.1 examine the free space map (FSM)
pg_visibility 1.1 examine the visibility map (VM) and page-level visibility info
postgres_fdw 1.0 foreign-data wrapper for remote PostgreSQL servers
refint 1.0 functions for implementing referential integrity (obsolete)
seg 1.1 data type for representing line segments or floating-point intervals
tcn 1.0 Triggered change notifications
timetravel 1.0 functions for implementing time travel
tsearch2 1.0 compatibility package for pre-8.3 text search functions
xml2 1.1 XPath querying and XSLTLogowanie
Operacje wykonywane w Cloud SQL są rejestrowane na karcie Aktywność wraz ze wszystkimi szczegółami. Przykład tworzenia instancji, pokazujący wszystkie szczegóły instancji:
Migracja PostgreSQL do GCP
W celu zapewnienia migracji lokalnych instalacji PostgreSQL, Google korzysta z pgBouncer.
Pamiętaj, że nie ma kreatora konsoli GCP do migracji PostgreSQL.
DBA Uwaga!
Wysoka dostępność i replikacja
Węzeł główny nie może przejść awaryjnie do repliki do odczytu. W tej samej sekcji opisano inne ważne aspekty replik do odczytu:
- może zostać przeniesiony do trybu offline w dowolnym momencie w celu zainstalowania poprawek
- nie podążaj za węzłem głównym w innej strefie po przełączeniu awaryjnym — ponieważ replikacja jest synchroniczna, może to wpłynąć na opóźnienie replikacji
- nie ma równoważenia obciążenia między replikami, innymi słowy, nie można wskazać aplikacji pojedynczego punktu końcowego
- rozmiar instancji repliki musi wynosić co najmniej rozmiar węzła głównego
- brak replikacji między regionami
- nie można wykonać kopii zapasowej replik
- wszystkie repliki muszą zostać usunięte przed przywróceniem lub usunięciem instancji głównej z kopii zapasowej
- replikacja kaskadowa nie jest dostępna
Użytkownicy
Domyślnie „superużytkownik chmury” to postgres, który jest członkiem roli cloudqlsuperuser. Z kolei cloudqlsuperuser dziedziczy domyślne role PostgreSQL:
[email protected]:5432 postgres> \du+ postgres
List of roles
Role name | Attributes | Member of | Description
-----------+------------------------+---------------------+-------------
postgres | Create role, Create DB | {cloudsqlsuperuser} |
[email protected]:5432 postgres> \du+ cloudsqlsuperuser
List of roles
Role name | Attributes | Member of | Description
-------------------+------------------------+--------------+-------------
cloudsqlsuperuser | Create role, Create DB | {pg_monitor} |Pamiętaj, że role SUPERUSER i REPLICATION nie są dostępne.
Kopia zapasowa i odzyskiwanie
Kopie zapasowe nie mogą być eksportowane.
Kopie zapasowe nie mogą być używane do uaktualniania instancji, tj. przywracania do innego silnika PostgreSQL.
Funkcje takie jak PITR, replikacja logiczna i kompilacja JIT nie są dostępne. Prośby o nowe funkcje można składać w narzędziu Google Issue Tracker.
Szyfrowanie
Podczas tworzenia instancji SSL/TLS jest włączone, ale nie wymuszane:
W tym trybie można zażądać szyfrowania, jednak weryfikacja certyfikatu nie jest dostępna.
~ $ psql "sslmode=verify-ca user=postgres dbname=postgres password=postgres hostaddr=35.233.149.65"
psql: root certificate file "/home/lelu/.postgresql/root.crt" does not exist
Either provide the file or change sslmode to disable server certificate verification.
~ $ psql "sslmode=require user=postgres dbname=postgres password=postgres hostaddr=35.233.149.65"
Pager usage is off.
psql (11.4, server 9.6.11)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128, compression: off)
Type "help" for help.Próba połączenia za pomocą psql z wymuszoną instancją SSL zwróci zrozumiały błąd:
~ $ psql "sslmode=require user=postgres dbname=postgres password=postgres hostaddr=35.233.149.65"
psql: FATAL: connection requires a valid client certificatePamięć
- Miejsce można zwiększyć po utworzeniu instancji, ale nigdy nie zmniejszać, więc uważaj na koszty związane z rosnącą przestrzenią dyskową lub skonfiguruj limit zwiększenia.
- Pamięć jest ograniczona do 30 TB.
procesor
Instancje można tworzyć z mniej niż jednym rdzeniem, jednak opcja nie jest dostępna w konsoli Cloud SQL, ponieważ instancję należy utworzyć, określając jeden z przykładowych typów maszyn, w tym przypadku – poziom:
Przykład tworzenia instancji z udostępnionym kodem przy użyciu gcloud w Cloud Shell:
Liczba procesorów jest ograniczona do 64, co jest stosunkowo niskim limitem dla dużych instalacje, biorąc pod uwagę, że w czasach testów 9.2 serwery high-end zaczynały się od 32 rdzeni.
Lokalizacje instancji
Lokalizacja w wielu regionach jest dostępna tylko dla kopii zapasowych.
Dostęp przez publiczny adres IP
Domyślnie Kreator konsoli GCP umożliwia dostęp tylko do publicznego adresu IP, jednak dostęp jest odmawiany do momentu skonfigurowania sieci klienta:
Konserwacja
Aktualizacje mogą przekroczyć okres konserwacji, a repliki do odczytu są aktualizowane w dowolnym momencie.
Dokumentacja nie określa, jak długo trwa okno konserwacji. Informacje są podawane podczas tworzenia instancji:
Zmiany liczby procesorów, rozmiaru pamięci lub strefy, w której znajduje się instancja lokalizacja wymaga, aby baza danych była offline przez kilka minut.
Użytkownicy
Cloud SQL używa zamiennie terminów „rola” i „użytkownik”.
Wysoka dostępność
Koszt w konfiguracji o wysokiej dostępności jest dwukrotnie wyższy niż w przypadku samodzielnej instancji, która obejmuje pamięć masową.
Automatyczne przełączanie awaryjne jest inicjowane po około 60 sekundach od momentu, gdy węzeł podstawowy stał się niedostępny. Według raportu Oracle MAA przekłada się to na stratę 5800 USD na minutę. Biorąc pod uwagę, że ponowne połączenie aplikacji trwa od 2 do 3 minut, awaria podwaja się do potrojenia. Ponadto 60-sekundowy interwał pulsu nie wydaje się być konfigurowalną opcją.
Replikacja
Do replik do odczytu nie można uzyskać dostępu za pomocą jednego punktu końcowego, z których każdy otrzymuje nowy adres IP:
Regionalne dyski stałe zapewniają nadmiarowość danych kosztem wydajności zapisu.
Cloud SQL nie przełączy się w tryb awaryjny w celu odczytu replik, dlatego czytników nie można uznać za rozwiązanie o wysokiej dostępności
Repliki zewnętrzne i zewnętrzne mastery nie są obecnie obsługiwane.
Łączenie z instancją
Google does not automatically renew the instance SSL certificates, however, both the initiation and rotation procedures can be automated.
If the application is built on the App Engine platform additional limits apply, such as 60 seconds for a database request to complete, 60 concurrent connections for PHP applications. The “App Engine Limits” section in Quotas and limits provides more details:
IP addresses in the range 172.17.0.0/16 are reserved.
Administration
Once started, operations cannot be canceled. Runaway queries can still be stopped by using the pg_terminate_backend and pg_cancel_backend PostgreSQL built-in functions.
A short demonstration using two psql sessions and starting a long running query in the second session:
[email protected]:5432 postgres> select now(); select pg_sleep(3600); select now();
now
-------------------------------
2019-07-16 02:08:18.739177+00
(1 row)In the first session, cancel the long running query:
[email protected]:5432 postgres> select pid, client_addr, client_port, query, backend_start from pg_stat_activity where usename = 'postgres';
-[ RECORD 1 ]-+-------------------------------------------------------------------------------------------------------------
pid | 2182
client_addr | 173.180.222.170
client_port | 56208
query | select pid, client_addr, client_port, query, backend_start from pg_stat_activity where usename = 'postgres';
backend_start | 2019-07-16 01:57:34.99011+00
-[ RECORD 2 ]-+-------------------------------------------------------------------------------------------------------------
pid | 2263
client_addr | 173.180.222.170
client_port | 56276
query | select pg_sleep(3600);
backend_start | 2019-07-16 02:07:43.860829+00
[email protected]:5432 postgres> select pg_cancel_backend(2263); select now();
-[ RECORD 1 ]-----+--
pg_cancel_backend | t
-[ RECORD 1 ]----------------------
now | 2019-07-16 02:09:09.600399+00Comparing the timestamps between the two sessions:
ERROR: canceling statement due to user request
now
-------------------------------
2019-07-16 02:09:09.602573+00
(1 row)It’s a match!
While restarting an instance is a recommended method when attempting to resolve database instance issues, avoid restarting before the first restart completed.
Data Import and Export
CSV import/export is limited to one database.
Exporting data as an SQL dump that can be imported later, requires a custom pg_dump command.
To quote from the documentation:
pg_dump -U [USERNAME] --format=plain --no-owner --no-acl [DATABASE_NAME] \
| sed -E 's/(DROP|CREATE|COMMENT ON) EXTENSION/-- \1 EXTENSION/g' > [SQL_FILE].sqlPricing
| Charge Type | Instance ON | Instance OFF |
| Storage | Yes | Yes |
| Instance | No | Yes |
Troubleshooting
Logging
All actions are recorded and can be viewed under the Activity tab.
Resources
Review the Diagnosing Issues with Cloud SQL instances and Known issues sections in the documentation.
Wnioski
Although missing some important features the PostgreSQL DBA is used to, namely PITR and Logical Replication, Google Cloud SQL provides out of the box high-availability, replication, encryption, and automatic storage increase, just to name a few, making manage PostgreSQL an appealing solution for organizations looking to quickly deploy their PostgreSQL workloads or even migrating from Oracle.
Developers can take advantage of cheap instances such as shared CPU (less than one CPU).
Google approaches the PostgreSQL engine adoption in a conservative manner, the stable offering lagging behind current upstream by 3 versions.
Just as with any solution provider consider getting support which can come in handy during edge scenarios such as when instances are suspended.
For professional support, Google maintains a list of partners which currently includes one of the PostgreSQL professional services , namely EDB.
