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.
Il mirroring in Fabric offre un'esperienza semplice per evitare complessi processi ETL (Extract Transform Load) e integrare il tuo patrimonio esistente di server flessibili di Azure Database per PostgreSQL con il resto dei dati in Microsoft Fabric. È possibile replicare continuamente il server flessibile di Database di Azure per PostgreSQL esistente direttamente in OneLake di Fabric. All'interno di Fabric è possibile sbloccare potenti scenari di business intelligence, intelligenza artificiale, ingegneria dei dati, data science e condivisione dei dati.
Per un'esercitazione sulla configurazione del mirroring del server flessibile di Database di Azure per PostgreSQL in Fabric (ora disponibile a livello generale), vedere Esercitazione: Configurare i database con mirroring di Microsoft Fabric dal server flessibile di Database di Azure per PostgreSQL.
Perché usare il mirroring in Fabric?
Con il Mirroring in Fabric, non è necessario integrare diversi servizi da più fornitori. È invece possibile usufruire di un prodotto altamente integrato, end-to-end e facile da usare, progettato per semplificare le esigenze di analisi e costruito per favorire l'apertura e la collaborazione tra Microsoft, il database flessibile di Azure per PostgreSQL e le migliaia di soluzioni tecnologiche in grado di leggere il formato di tabella open-source Delta Lake.
Quali esperienze di analisi sono integrate?
I database con mirroring sono un elemento nel Fabric Data Warehousing distinto dal Warehouse e dall'endpoint di analisi SQL.
Il mirroring crea questi elementi nella tua area di lavoro Fabric.
- Elemento del database sottoposto a mirroring. Il mirroring gestisce la replica dei dati in OneLake e la conversione in Parquet, in un formato pronto per l'analisi. Ciò consente scenari downstream come ingegneria dei dati, data science e altro ancora.
- Un endpoint di analisi SQL
Ogni database con mirroring nel server flessibile di Database di Azure per PostgreSQL ha un endpoint di analisi SQL generato automaticamente che offre un'esperienza analitica avanzata oltre alle tabelle Delta create dal processo di mirroring. Gli utenti hanno accesso a comandi T-SQL familiari che possono definire ed eseguire query su oggetti dati, ma non modificare i dati dall'endpoint di analisi SQL, perché si tratta di una copia di sola lettura. È possibile eseguire le azioni seguenti nell'endpoint di analisi SQL:
- Esplora le tabelle che fanno riferimento ai dati nelle tue tabelle di Delta Lake dal server flessibile di Azure Database per PostgreSQL.
- Crea query e viste senza codice ed esplora visivamente i dati senza scrivere una riga di codice.
- Sviluppare viste SQL, funzioni con valori con tabella INLINE e stored procedure allo scopo di incapsulare la semantica e la logica aziendale nel T-SQL.
- Gestire le autorizzazioni per gli oggetti.
- Eseguire query sui dati in altri data warehouse e data lakehouse nella stessa area di lavoro.
Oltre all'editor di query SQL, è disponibile un ampio ecosistema di strumenti in grado di eseguire query sull'endpoint di analisi SQL, tra cui SQL Server Management Studio (SSMS),l'estensione mssql con Visual Studio Code e anche GitHub Copilot.
Requisiti di rete
Se il server flessibile non è accessibile pubblicamente e non consente ai servizi di Azure di connettersi, è possibile creare un gateway dati di rete virtuale per eseguire il mirroring dei dati. Assicurarsi che la rete virtuale di Azure o la rete del computer gateway possa connettersi al server flessibile di Database di Azure per PostgreSQL tramite un endpoint privato o sia consentita dalla regola del firewall.
Transazioni attive, carichi di lavoro e comportamenti del motore di replica
Le transazioni attive continuano a mantenere il troncamento del log delle scritture anticipate (WAL) fino a quando la transazione viene confermata e il server flessibile con mirroring del Database di Azure per PostgreSQL si aggiorna, oppure la transazione viene interrotta. Le transazioni a esecuzione prolungata potrebbero comportare il riempimento del WAL più del solito. È consigliabile monitorare WAL nel server flessibile del database di origine di Azure per PostgreSQL per evitare che l'archiviazione si riempia. Per ulteriori informazioni, vedere WAL cresce a causa di transazioni a esecuzione prolungata e CDC.
Ogni carico di lavoro utente varia. Durante lo snapshot iniziale, nel database di origine potrebbero essere presenti più utilizzi delle risorse, sia per le operazioni di CPU che di I/O al secondo (operazioni di input/output al secondo, per leggere le pagine). Le operazioni di aggiornamento/eliminazione delle tabelle possono comportare un aumento della generazione di log. Altre informazioni su come monitorare le risorse per il server flessibile di Database di Azure per PostgreSQL.
Supporto del livello di calcolo
Il server flessibile del Database di Azure per PostgreSQL di origine può essere un livello di calcolo per utilizzo generico o ottimizzato per la memoria. Il livello di calcolo espandibile non è supportato come origine per il mirroring.
Per altre informazioni sui livelli di calcolo disponibili nel server flessibile di Database di Azure per PostgreSQL, vedere Opzioni di calcolo nel server flessibile di Database di Azure per PostgreSQL.
Passo successivo
Contenuti correlati
- Procedura: Proteggere i database replicati di Microsoft Fabric dal server flessibile del database di Azure per PostgreSQL
- Limitazioni nei database con mirroring di Microsoft Fabric dal server flessibile di Azure Database per PostgreSQL
- Monitorare la replica del database mirror di Fabric
- Risoluzione dei problemi dei database mirror di Fabric sul server flessibile di Azure Database per PostgreSQL