PostgreSQLAdministratörerMaskinöversatt

Hantera beräkningsplanerna

Var PostgreSQL-beräkningsplanerna lagras, vilka av dem modulen återställer vid varje start, hur du lägger till en egen plan och varifrån lagringsklasserna kommer.

PostgreSQL-beräkningsplanerna är rader i tabellen db_postgres.postgres_compute_plans i plattformsdatabasen. Det finns ingen sida i portalen och inget API för att ändra dem: du ändrar raderna. Modulen ansluter till databasen med anslutningssträngen i hemligheten stackship-db-credentials (nyckeln connection-string) i stackship-system.

Tabellen

Kolumn	Innehåller
`name`	Planens namn, högst 90 tecken; unikt
`description`	Texten som portalen visar med den
`cpu_request`, `cpu_limit`	CPU per instans, som en Kubernetes-kvantitet som `500m` eller `2`
`memory_request`, `memory_limit`	Minne per instans, till exempel `4Gi`. Håll dem lika: PostgreSQL dimensionerar sitt minne efter gränsen
`storage_size`	Datavolymen för ett nytt kluster, till exempel `50Gi`
`storage_class`	Lagringsklassen för ett nytt klusters volymer
`wal_storage_size`	Den separata WAL-volymen, eller `NULL` för ingen
`replicas`	Antalet instanser
`is_production_ready`	Markerar en produktionsnivå
`engine_parameters_json`	PostgreSQL-parametrar, som ett JSON-objekt med namn och värde, som skrivs in i ett kluster som skapas från planen
`pooling_enabled`, `pooling_mode`, `pooling_instances`	Om ett kluster som skapas med CLI:t eller API:t utan att ange något annat får PgBouncer, och hur
`id`, `created_utc`	Ett UUID och en tidsstämpel

De sju inbyggda planerna

Varje gång modulen startar skriver den tillbaka planerna nano, small, medium, standard, large, xlarge och 2xlarge till de värden den levereras med, parametrarna inräknade. En ändring av någon av de raderna gäller till nästa start. Rader med andra namn lämnas orörda.

Lägg till en plan

Lägg till en rad med ett eget namn:

sql

INSERT INTO db_postgres.postgres_compute_plans
  (id, name, description, cpu_request, cpu_limit, memory_request, memory_limit,
   storage_size, storage_class, wal_storage_size, replicas, is_production_ready,
   engine_parameters_json, pooling_enabled, pooling_mode, pooling_instances, created_utc)
VALUES
  (gen_random_uuid(), 'reporting', 'Two instances for reporting workloads.',
   '2000m', '4000m', '8Gi', '8Gi', '200Gi', '<storage-class>', '16Gi', 2, true,
   '{"shared_buffers":"2GB","effective_cache_size":"5734MB","max_connections":"200"}',
   false, NULL, NULL, now());

Att skapa ett kluster, byta dess plan och lista planerna läser tabellen direkt. Den plan ett befintligt kluster visas på kommer från en kopia som varje modulinstans behåller i upp till en minut, så den kan ligga efter en ändring så länge. Döp inte en plan till custom: det namnet betyder ett kluster som inte motsvarar någon plan.

Hur kluster hänger ihop med planer

Ett kluster lagrar inte sin plan. Varje gång ett kluster läses jämför modulen dess CPU, minne och antal instanser med katalogen och rapporterar den plan som stämmer, eller Custom. Att ändra en plans CPU, minne eller repliker ändrar alltså ingenting i körande kluster — men de kluster som skapats från den stämmer inte längre och visas som Custom. Att ta bort en plan får samma effekt, om inte en annan plan har samma form. Att byta namn på en plan ändrar bara namnet som dess kluster visar.

En plan som ingen nod i målklustret skulle kunna köra avvisas vid skapande och vid planbyte. Vilka planer en boundary får använda avgörs av dess policyer för beräkningsplaner.

Lagringsklasser

De inbyggda planerna tar sin lagringsklass från modulens inställningar Storage__Standard — för nano och small — och Storage__Premium för de andra; installationsprogrammet kallar dem Standard Storage Class och Premium Storage Class. De finns i modulens konfigurationsreferens. En ändrad inställning når raderna vid modulens nästa start, och därefter nya kluster; ett befintligt kluster behåller den klass som dess volymer skapades med.