Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Database di Azure per PostgreSQL: i cluster elastici sono la prossima evoluzione dell'offerta PostgreSQL distribuita di Azure, basata sul server flessibile di Database di Azure per PostgreSQL con l'estensione Citus. Per i clienti che eseguono attualmente Azure Cosmos DB per PostgreSQL, i cluster elastici offrono parità delle funzionalità per i carichi di lavoro Postgres distribuiti, offrendo al tempo stesso un percorso più integrato, flessibile e conveniente.
Una roadmap chiara e lungimirante: i Cluster Elastici sono la direzione strategica per PostgreSQL distribuito su Azure, con investimenti continui (ad esempio, miglioramenti pianificati come i failover programmati, l'aumento automatico dello spazio di archiviazione e la conservazione a lungo termine). Azure Cosmos DB per PostgreSQL è in fase di ritiro con supporto limitato durante questo periodo.
Modello di costo inferiore e più semplice (senza sovrapprezzo per il coordinatore dedicato): Elastic Clusters non richiede un nodo solo coordinatore fatturato separatamente, il che può ridurre i costi di base e semplifica la previsione dei prezzi man mano che si scala orizzontalmente.
Scelte più flessibili per le prestazioni: scegliere tra livelli burstable, per utilizzo generico e ottimizzati per la memoria e serie di calcolo più recenti per ottenere costi e prestazioni corretti per ogni nodo man mano che i carichi di lavoro si evolvono.
Eseguire query da qualsiasi nodo: i cluster elastici consentono l'accesso alle query tramite qualsiasi nodo, migliorando la flessibilità operativa per gli strumenti, la risoluzione dei problemi e i modelli di carico di lavoro che traggono vantaggio da più punti di ingresso.
Funzionalità moderne di PostgreSQL prima: l'adozione più rapida delle versioni più recenti di PostgreSQL (incluso il supporto di PostgreSQL 17) consente ai clienti di accedere agli aggiornamenti della sicurezza, ai miglioramenti delle prestazioni e alle nuove funzionalità del linguaggio in precedenza.
Basato sul server flessibile di Database di Azure per PostgreSQL: i cluster elastici ereditano il modello operativo che i clienti usano già per il server flessibile, ovvero backup, monitoraggio/metriche, controlli di manutenzione e integrazione della piattaforma, riducendo la complessità delle operazioni quotidiane-2.
Integrazione più avanzata delle identità e della sicurezza: il supporto per l'identità gestita e l'autenticazione di Microsoft Entra ID consente di semplificare la gestione dei segreti e di allineare l'accesso al database con i controlli delle identità aziendali.
Confronto delle funzionalità
| Funzionalità/Categoria | Azure Cosmos DB con PostgreSQL | Azure Database per Cluster Elastici di PostgreSQL | Note/Parità |
|---|---|---|---|
| Tecnologia di base | Estensione PostgreSQL + Citus (tabelle/partizioni distribuite) | Estensione PostgreSQL + Citus (partizionamento orizzontale) | Parità. |
| Modelli di partizionamento orizzontale | Basato su righe (tabelle distribuite), basato su schema (schemi distribuiti) | Partizionamento orizzontale basato su righe e basato su schema | Parità. |
| Architecture | Nodo coordinatore e nodi di lavoro (non condiviso) | Più nodi di Flexible Server interconnessi come un cluster Citus | Simili; Elastic è basato su istanze di Flexible Server. |
| Ridimensionamento orizzontale | Aggiungere nodi di lavoro; ribilanciare le partizioni | Aggiungere nodi di lavoro; ribilanciare i dati | Parità. |
| Ridimensionamento verticale | Ridimensionare le unità di calcolo/archiviazione per ogni nodo | Ridimensionare le risorse di calcolo/processo e memoria/archiviazione per nodo | Parità. |
| Disponibilità elevata | Sì (opzioni con ridondanza della zona; failover automatico) | Sì (disponibilità elevata compatibile con cluster) | Parità. |
| Repliche in lettura | Sì | Sì | Parità. |
| Coordinatore dedicato (costo aggiuntivo) | Sì | No | Vantaggio elastico. |
| Eseguire query da qualsiasi nodo | No | Sì | Vantaggio elastico. |
| Scelte di calcolo | Rapporto burstable o fisso tra memoria e core; nessuna scelta di generazioni di calcolo | Burstable, Utilizzo generico, Ottimizzato per la memoria; scelta di serie di calcolo | Vantaggio elastico. |
| Calcolo massimo per nodo (core) | 96 vCore | 96 (presto 192) | Parità. |
| Prezzi (ottimizzati per la memoria) | Nodo: $0,1425/vCore ora + coordinatore ($0,44/ora) o $0,11/vCore ora | $0,125/vCore ora (nessun coordinatore dedicato) | Vantaggio elastico (modello di costo più semplice). |
| Prezzi di calcolo (utilizzo generico) | N/A | $0,09/vCore ora | Solo elastico. |
| Prezzi dell'archiviazione | $0,115/GB-month | $0,115/GB-month | Parità. |
| Ribilanciamento online | Sì | Sì | Parità. |
| Versioni di PostgreSQL | Fino alle versioni recenti (ad esempio, 15/16 storicamente) | Supporta la versione più recente, tra cui PostgreSQL 17 | Vantaggio elastico (supporto della versione più recente). |
| Supporto di Postgres 17/18 | No | Sì | Vantaggio elastico (supporto della versione più recente). |
| Supporto delle estensioni | Subset di estensioni chiave (ad esempio, PostGIS, JSONB) | Estensioni server flessibili standard; alcune limitazioni (ad esempio, nessun timescaleDB in modalità cluster) | Parità (piccole differenze). |
| Autenticazione Microsoft Entra ID | Sì | Sì | Parità. |
| Failover programmati HA | No | Pianificato (GA+) | Intervallo (pianificato). |
| Endpoint privati | Sì | Sì | Parità. |
| Rete virtuale | No | No | Parità (non supportata). |
| Supporto di PgBouncer | - | Sì | Vantaggio elastico (supporto della versione più recente). |
| Numero massimo di connessioni per nodo | 300 (0-3 vCore) pert nodo; 500 (4-15 vCore) per nodo; 1000 (16+ vCore) per nodo. Max 2500 | 3000 per nodo | Vantaggio elastico. |
| Metriche a livello di cluster o di nodo | Sì | Sì | Parità. |
| Monitoraggio multi-tenant | Sì | Sì | Parità. |
| Creare un ruolo NOLOGIN | No | Sì | Vantaggio elastico. |
| Finestre di manutenzione | Sì | Sì | Parità. |
| Backup geografico e ripristino | Sì | Sì | Parità. |
| Identità gestita | No | Sì | Vantaggio elastico. |
| Chiavi gestite dal cliente (crittografia) | Sì | Sì | Parità. |
| Terraform | Sì | Sì | Parità. |
| Aumento automatico dell'archiviazione | No | Pianificato (GA+) | Vantaggio elastico. |
| SSD Premium v2 (80.000 operazioni di I/O al secondo/nodo) | No | Pianificato (GA+) | Vantaggio elastico. |
| Rimuovi nodo | No¹ | No | Parity |
| Conservazione a lungo termine | No | Roadmap (GA+) | Vantaggio elastico. |
| Archivio query | No | Roadmap (GA+) | Vantaggio elastico. |
| Gestione e integrazione | Parte del portale/esperienza di Azure Cosmos DB; legami con l'ecosistema Cosmos | Integrato in Azure Database per PostgreSQL - Server Flessibile (ad esempio, backup, metriche, Microsoft Entra ID) | Portali diversi; Elastic sfrutta le funzionalità del server flessibile. |
| Modello di determinazione prezzi | basato su vCore; separato per coordinatore/lavoratori | vCore, archiviazione, operazioni di I/O al secondo (senza costi aggiuntivi per Citus) | Vantaggio elastico (modello più semplice). |
| Networking | Accesso pubblico (regole del firewall), accesso privato (collegamento privato) o entrambi | Accesso pubblico (indirizzi IP consentiti); accesso privato tramite collegamento privato nei nodi del server flessibile sottostante | Parità (opzioni simili). |
¹ Rimuovere il nodo è disponibile tramite ribilanciamento per spostare i dati da un nodo, ma il nodo stesso non viene deprovisionato automaticamente.
Strumento di migrazione
Viene fornito uno strumento di migrazione dedicato per semplificare la transizione da Azure Cosmos DB per PostgreSQL al cluster elastico di Database di Azure per PostgreSQL. Questo strumento automatizza la migrazione dello schema e dei dati, riduce al minimo i tempi di inattività e garantisce l'integrità dei dati.
L'approccio alla migrazione si concentra sulla creazione di un nuovo disco dati su Flex creando uno snapshot da un cluster CPG e montandolo come disco dati primario del cluster elastico di destinazione (EC), riducendo drasticamente i tempi di migrazione e garantendo la fedeltà dei dati senza influire sulla qualità della rete. Copiare quindi i file delta (estensioni, configurazioni PG & estensioni, certificati, log di archivio ecc.) dal Flex/datadrive originale nel nuovo disco.
Lo strumento insieme al promemoria popup sarà disponibile tramite la scheda Migrazione in Azure Cosmos DB per PostgreSQL a partire dal13 aprile.
Da qui, la migrazione può essere avviata fornendo dettagli semplici per il server di destinazione
Mapping degli SKU
Azure Cosmos DB per PostgreSQL verrà confrontato con il database di Azure di destinazione per PostgreSQL (cluster elastico) in base alla tabella di mapping seguente. Dopo la migrazione, i clienti possono aumentare o ridurre le prestazioni con quasi 0 tempi di inattività.
| Server di origineEdition | VCore di origine | Nome della Destinazione | Livello di destinazione |
|---|---|---|---|
| Ottimizzato per Memoria Espandibile | 1 | Standard_B2s | Possibilità di burst |
| ScopoGeneraleScoppiabile | 2 | Standard_B2s | Possibilità di burst |
| Utilizzo generico | 2 | Standard_D2ds_v5 | Utilizzo generico |
| Utilizzo generico | 4 | Standard_D4ds_v5 | Utilizzo generico |
| Utilizzo generico | 8 | Standard_D8ds_v5 | Utilizzo generico |
| Utilizzo generico | 16 | Standard_D16ds_v5 | Utilizzo generico |
| Utilizzo generico | 32 | Standard_D32ds_v5 | Utilizzo generico |
| Utilizzo generico | 64 | Standard_D64ds_v5 | Utilizzo generico |
| Utilizzo generico | 96 | Standard_D96ds_v5 | Utilizzo generico |
| MemoryOptimized | 2 | Standard_E2ds_v5 | MemoryOptimized |
| MemoryOptimized | 4 | Standard_E4ds_v5 | MemoryOptimized |
| MemoryOptimized | 8 | Standard_E8ds_v5 | MemoryOptimized |
| MemoryOptimized | 16 | Standard_E16ds_v5 | MemoryOptimized |
| MemoryOptimized | 32 | Standard_E32ds_v5 | MemoryOptimized |
| MemoryOptimized | 64 | Standard_E64ds_v5 | MemoryOptimized |
| MemoryOptimized | 96 | Standard_E96ds_v5 | MemoryOptimized |
Flusso di migrazione
L'utente avvia la migrazione dalla pagina del cluster CPG nel portale di Azure.
Il portale esegue controlli di pre-convalida.
Se i controlli vengono superati, il portale provvede al provisioning del cluster elastico di destinazione con le impostazioni di migrazione CPG (ad esempio, le regole di confronto/ configurazione della versione PostgreSQL e Citus).
Il portale avvia la migrazione sull'EC provvisto.
Lo strumento di migrazione imposta il cluster CPG in modalità sola lettura e avvia la creazione di snapshot (uno per ciascun nodo nel caso di cluster multi-nodo).
Chiama l'Elastic Cluster con gli ID delle risorse dello snapshot per avviare la migrazione basata su disco.
Crea nuovi dischi dati dagli snapshot, blocca l'EC, arresta i contenitori e scambia il nuovo disco inserendolo come disco primario /datadrive.
Copia i file della piattaforma "delta" nel nuovo disco (estensioni, configurazioni PG/estensioni, certificati, archivio/WAL e così via), quindi ripristina la proprietà/autorizzazioni ed esegue correzioni di metadati necessarie (ad esempio, mapping dei nodi, ruoli, estensioni).
Avvia i contenitori e completa l'operazione di migrazione;
Dopo il successo, lo strumento applica le impostazioni post-migrazione a EC (le configurazioni con override dell'utente, impostazioni di alta disponibilità).
Migrazione completata: il portale aggiorna lo stato di esito positivo/negativo al termine. Il cluster CPG viene arrestato e il Cluster Elastico diventa la nuova destinazione scrivibile a cui il cliente passa (nuova stringa di connessione, ricreare PEC, se necessario).
Intervallo medio di migrazione
Nella maggior parte dei casi, la migrazione end-to-end viene completata in meno di 10 minuti. La finestra write-lock (sola lettura), dal momento in cui il cluster di origine è impostato a sola lettura fino a quando l'Elastic Cluster di destinazione diventa scrivibile, ha in genere una durata di circa 5-8 minuti, rendendola adatta per essere eseguita all'interno di una finestra di manutenzione pianificata standard.
Fattori chiave che possono influire sulla tempistica: dimensioni del database e numero di nodi (più snapshot/dischi), footprint di estensione.