Gruppi di parametri in Azure HorizonDB (anteprima)

I gruppi di parametri in HorizonDB fungono da contenitori per i valori di configurazione del cluster che è possibile applicare a uno o più cluster di database. Anziché gestire le impostazioni di configurazione per ogni cluster singolarmente, definirle in un gruppo di parametri e connetterle con più cluster per garantire la coerenza nell'ambiente.

I gruppi di parametri sono risorse di prima classe in Azure. Vengono visualizzati all'interno del gruppo di risorse e della sottoscrizione specifici definiti nel relativo identificatore di risorsa.

Concetti chiave

  • Controllo delle versioni del motore: i gruppi di parametri sono specifici di una versione del motore PostgreSQL (ad esempio, 17).
  • Ereditarietà dei parametri predefinita: quando si crea un gruppo, è sufficiente specificare un subset di parametri. Tutti i parametri non specificati in modo esplicito vengono automaticamente sottoposti a seeding e uniti dal gruppo di parametri predefinito del sistema per la versione del motore di destinazione.
  • Identificatore predefinito del gruppo di parametri: a ogni cluster HorizonDB viene assegnato un gruppo di parametri predefinito gestito dal sistema al momento della creazione. L'identificatore di risorsa per questo gruppo segue la convenzione: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.HorizonDB/parameterGroups/default_pg{pgVersion}(ad esempio, default_pg17 per PostgreSQL versione 17)
  • Applicazione immediata o posticipata: alcuni parametri (statici) richiedono un riavvio del server per rendere effettivo, mentre altri (dinamici) possono essere applicati immediatamente.
    • Parametri dinamici: i valori modificati vengono applicati immediatamente ai cluster attivi senza richiedere un riavvio.
    • Parametri statici: i valori modificati vengono archiviati nella configurazione del cluster, ma rimangono "in sospeso" fino al successivo riavvio del server.
    • Applica stato: il applyImmediately flag (impostazione predefinita: false) determina se il sistema deve forzare il riavvio dei cluster connessi al gruppo di parametri per applicare immediatamente modifiche statiche.
  • Parametri di sola lettura: alcuni parametri sono contrassegnati come di sola lettura dal sistema per motivi di sicurezza o stabilità.
    • Modifica non consentita: qualsiasi tentativo di includere un parametro di sola lettura in una richiesta genera un errore di convalida.
    • Valori predefiniti: questi parametri di sola lettura si applicano ancora ai cluster, ma usano sempre i valori definiti nel gruppo di parametri predefinito del sistema per la versione del motore di destinazione.
  • Univocità delle risorse: i nomi dei gruppi di parametri devono essere univoci all'interno del gruppo di risorse e della sottoscrizione.
  • Connessioni: i gruppi di parametri possono essere connessi (collegati o associati) a uno o più cluster. Un gruppo di parametri creato in un'area non può essere connesso a un cluster creato in un'area diversa. Le connessioni vengono gestite tramite un sistema di mapping interno che tiene traccia:
    • Stato di sincronizzazione: indica se la configurazione del cluster corrisponde alla versione del gruppo di parametri.
  • Scenario: connessione multi-cluster e applicazione posticipata:
    • Si supponga che il cluster A e il cluster B siano entrambi connessi con il gruppo di parametri X.
    • Se un parametro statico ( ad esempio , max_connections) viene aggiornato nel gruppo di parametri X ed applyImmediately è impostato su false:
      1. L'aggiornamento crea una nuova versione dei dati per il gruppo di parametri X.
      2. Il backend aggiorna la mappatura sia per il cluster A che per il cluster B, portandola alla nuova versione con stato di sincronizzazione "In sospeso".
      3. Se il cluster A viene riavviato manualmente (o riavviato a causa della manutenzione), recupera il nuovo valore statico e il relativo stato passa a InSync.
      4. cluster B, se non riavviato, continua a essere eseguito con il valore precedente del parametro statico, anche se la configurazione di destinazione nel back-end punta alla nuova versione. Rimane in uno stato "Riavvio in sospeso" o "Non sincronizzato" fino a quando non si verifica un riavvio.

Procedure consigliate

  • Convenzioni di denominazione: preferibilmente, incorporare una forma di descrizione codificata nel nome in modo da poter identificare successivamente i potenziali cluster di destinazione di tale configurazione.
  • Staging: testare sempre nuovi gruppi di parametri in un cluster di sviluppo prima di applicarli all'ambiente di produzione, soprattutto quando si imposta applyImmediately su true.

Contenuti correlati

  • Last updated on