Condividi tramite

Mirroring di Database di Azure per PostgreSQL in Microsoft Fabric

Il mirroring in Fabric (ora disponibile in generale) offre un'esperienza semplice per evitare i processi ETL complessi (Extract Transform Load) e integrare il tuo attuale database di Azure per PostgreSQL con il resto dei dati in Microsoft Fabric. Puoi replicare continuamente il tuo esistente Azure Database per PostgreSQL direttamente in Fabric OneLake. All'interno di Fabric è possibile sbloccare potenti scenari di business intelligence, intelligenza artificiale, ingegneria dei dati, data science e condivisione dei dati.

Importante

I server appena creati dopo Ignite 2025 includono automaticamente la versione di disponibilità generale più recente dei componenti di mirroring. I server esistenti si aggiornano progressivamente nell'ambito dei cicli di manutenzione successivi senza che venga richiesto l'intervento manuale. Per ricevere gli aggiornamenti non è necessario disabilitare e riabilitare il mirroring.

Architettura

Il mirroring di Fabric nel Database di Azure per PostgreSQL si basa su concetti come la replica logica e lo schema progettuale CDC (Change Data Capture).

Dopo aver stabilito il mirroring di Fabric per un database in un'istanza del server flessibile di Database di Azure per PostgreSQL, un processo in background di PostgreSQL crea uno snapshot iniziale delle tabelle selezionate su cui eseguire il mirroring. Lo snapshot viene inviato a una zona di destinazione di Fabric OneLake nel formato Parquet. Un processo di replicazione in esecuzione in Fabric accetta questi file di snapshot iniziali e crea tabelle Delta nell'artefatto del database replicato.

Il database di origine acquisisce le modifiche successive applicate alle tabelle selezionate. Queste modifiche vengono inviate alla zona di destinazione di OneLake in batch da applicare alle rispettive tabelle Delta nell'artefatto del database su cui è stato eseguito il mirroring.

Diagramma dell'architettura end-to-end per il mirroring di fabric in un'istanza flessibile di Database di Azure per PostgreSQL.

Che cos'è Change Data Capture (CDC)?

Change Data Capture (CDC) è un metodo che consente alle applicazioni di rilevare e acquisire le modifiche apportate a un database.

Non si basa su query SQL esplicite per tenere traccia delle modifiche.

Implica invece un flusso continuo di eventi di modifica pubblicati dal server di database.

I client possono sottoscrivere questo flusso per monitorare le modifiche, concentrandosi su database specifici, singole tabelle o persino subset di colonne all'interno di una tabella.

Per il mirroring dell'infrastruttura, il modello CDC viene implementato in un'estensione PostgreSQL proprietaria denominata azure_cdc. Il piano di controllo per un'istanza del server flessibile di Azure Database per PostgreSQL viene installato e registrato nei database di origine durante il flusso di lavoro di abilitazione del mirroring Fabric.

Estensione Azure Change Data Capture (CDC)

Azure CDC è un'estensione per PostgreSQL che migliora le funzionalità di decodifica logica.

Interpreta e trasforma i dati Write-Ahead log (WAL) in un formato logico comprensibile.

L'estensione converte le modifiche del database in una sequenza di operazioni logiche come INSERT, UPDATE e DELETE.

Azure CDC è un livello sopra il plug-in di decodifica logica predefinito di PostgreSQL, pgoutput.

Azure CDC esporta istantanee e modifiche delle tabelle come file Parquet e le copia in una zona di atterraggio di Microsoft Fabric OneLake per l'elaborazione successiva.

Abilitare il mirroring di Fabric nel portale di Azure

Il mirroring di fabric nel portale di Azure per un'istanza del server flessibile di Database di Azure per PostgreSQL consente di replicare i database PostgreSQL in Microsoft Fabric. Questa funzionalità consente di integrare facilmente i dati con altri servizi in Microsoft Fabric, abilitando scenari avanzati di analisi, business intelligence e data science. Seguendo alcuni semplici passaggi nel portale di Azure, è possibile configurare i prerequisiti necessari e avviare il mirroring dei database per usare il potenziale completo di Microsoft Fabric.

Versioni supportate

Database di Azure per PostgreSQL supporta PostgreSQL 14 e versioni successive per il mirroring dell'infrastruttura.

Prerequisiti

Prima di poter utilizzare il mirroring di Fabric in un server flessibile di Azure Database per PostgreSQL, è necessario configurare diversi requisiti preliminari.

  • L'identità gestita assegnata dal sistema (SAMI) deve essere abilitata.
    • Azure CDC usa questa identità per autenticare le comunicazioni con Fabric OneLake, copiare gli snapshot iniziali e modificare i batch nella zona di destinazione.

È possibile configurare prerequisiti aggiuntivi tramite un flusso di lavoro di abilitazione dedicato descritto nella sezione seguente. Questi prerequisiti sono:

  • wal_level parametro del server deve essere impostato su "logico".

    • Abilita la replica logica per il server di origine.

  • max_worker_processes parametro del server deve essere aumentato per supportare più processi in background per il mirroring.

  • azure_cdc estensione. L'estensione Azure CDC (azure_cdc) viene precaricata nel server di origine e registrata per i database selezionati per il mirroring (richiede il riavvio).

Nel portale di Azure è disponibile una nuova pagina per automatizzare queste configurazioni dei prerequisiti nel server di origine.

Screenshot che mostra la pagina di New Fabric mirroring nel portale di Azure per iniziare l'attivazione.

Selezionare Inizia per avviare il flusso di lavoro di abilitazione.

Screenshot che mostra la pagina di mirroring New Fabric nel portale di Azure per database selezionati.

Questa pagina mostra lo stato corrente dei prerequisiti necessari. Se l'identità gestita assegnata dal sistema (SAMI) non è abilitata per questo server, selezionare il collegamento da reindirizzare alla pagina in cui è possibile abilitare questa funzionalità.

Al termine, selezionare i database per abilitare il mirroring dell'infrastruttura (fino a tre per impostazione predefinita, ma è possibile aumentare questo limite modificando il parametro del server max_mirrored_databases ) e quindi selezionare Prepara.

Il flusso di lavoro presenta una notifica per riavviare il server. Selezionando Riavvia, si avvia il processo. Il flusso di lavoro automatizza tutti i passaggi di configurazione rimanenti. È possibile iniziare a creare il database con mirroring dall'interfaccia utente di Fabric.

La pagina di mirroring di Fabric mostra che il server è pronto per il mirroring.

Creare un ruolo di database per il Fabric Mirroring

Successivamente, è necessario fornire o creare un ruolo PostgreSQL per il servizio Fabric per connettersi al server flessibile di Database di Azure per PostgreSQL.

È possibile eseguire questa attività specificando un ruolo del database per la connessione al sistema di origine.

Annotazioni

Sia l'ID Entra che i ruoli del database locale sono supportati per connettere il mirroring di Fabric a Database di Azure per PostgreSQL, selezionare il metodo di autenticazione più adatto alle proprie esigenze.

Utilizzo di un ruolo del database

  1. Connettersi al database di Azure per PostgreSQL usando Visual Studio Code o pgAdmin. Connettersi a un'entità di sicurezza che è un membro del ruolo azure_pg_admin.

  2. Creare un ruolo PostgreSQL denominato fabric_user. È possibile scegliere qualsiasi nome per questo ruolo. Specificare una password complessa. Concedere le autorizzazioni necessarie per il mirroring di Fabric nel database. Eseguire lo script SQL seguente per concedere le autorizzazioni CREATEDB, CREATEROLE, LOGIN, REPLICATION e azure_cdc_admin al nuovo ruolo denominato fabric_user.

    -- create a new user to connect from Fabric
CREATE ROLE fabric_user CREATEDB CREATEROLE LOGIN REPLICATION PASSWORD '<strong password>';

-- grant role for replication management to the new user
GRANT azure_cdc_admin TO fabric_user;
-- grant create permission on the database to mirror to the new user
GRANT CREATE ON DATABASE <database_to_mirror> TO fabric_user;

  3. L'utente del database creato deve anche essere owner delle tabelle da replicare nel database con mirroring. Questo requisito significa che l'utente crea le tabelle o modifica la proprietà di tali tabelle usando ALTER TABLE <table name here> OWNER TO fabric_user;.

    • Quando si passa la proprietà al nuovo utente, prima potrebbe essere necessario concedergli tutti i privilegi per lo schema public. Per altre informazioni sulla gestione degli account utente, vedere la documentazione sulla gestione degli utenti di Database di Azure per PostgreSQL, la documentazione di prodotto per PostgreSQL relativa a ruoli e privilegi del database, sintassi GRANT e privilegi.

Importante

La mancanza di uno dei precedenti passaggi di configurazione di sicurezza causa il fallimento delle operazioni di mirroring successive nel portale di Fabric con il messaggio Internal error.

Parametri del server

Questi parametri del server influiscono direttamente sul mirroring di Fabric per Azure Database per PostgreSQL e possono essere utilizzati per ottimizzare il processo di replica verso Fabric OneLake.

  • Azure.fabric_mirror_enabled: per impostazione predefinita è disattivato. Questo parametro specifica il flag che indica se il mirroring è abilitato nel server. Viene impostato automaticamente alla fine del flusso di lavoro di abilitazione del server, quindi non è consigliabile modificarlo manualmente.

  • max_replication_slots: valore predefinito 10. Viene utilizzato uno slot di replica per ogni database con mirroring, ma i clienti potrebbero prendere in considerazione un aumento nel caso in cui creino più mirror o abbiano altri slot di replica creati per altri scopi (replica logica).

  • max_wal_senders: il valore predefinito è 10. Come per il parametro precedente, viene usato un wal processo mittente per mirror, che deve essere aumentato quando si esegue il mirroring di più database.

  • max_worker_processes: il valore predefinito è 8. Dopo lo snapshot iniziale, viene usato un processo per ogni database con mirroring o in cui è abilitato il mirroring (ma non è ancora stato creato alcun artefatto con mirroring in Fabric). È necessario aumentare questo valore se sono presenti altre estensioni o carichi di lavoro che usano più processi di lavoro.

  • max_parallel_workers: il valore predefinito è 8, che limita il numero di ruoli di lavoro che possono essere eseguiti contemporaneamente. Se si abilitano più sessioni di mirroring nello stesso server, è consigliabile aumentare questo parametro per consentire più operazioni parallele, ad esempio aumentando il parallelismo negli snapshot iniziali.

  • azure_cdc.max_fabric_mirror Il valore predefinito è 3. I clienti possono aumentare questo valore se devono eseguire il mirroring di più di tre database in questo server. È importante considerare che ogni nuovo database con mirroring utilizza risorse server (cinque processi in background che usano risorse CPU e memoria per la creazione e l'invio in batch di modifiche di snapshot), quindi, a seconda di quanto sia occupato il server, è consigliabile monitorare l'utilizzo delle risorse e aumentare le dimensioni di calcolo fino alle dimensioni successive disponibili se l'utilizzo della CPU e della memoria supera costantemente i 80% o le prestazioni non sono quelle previste.

  • azure_cdc.max_snapshot_workers: il valore predefinito è 3. Numero massimo di processi di lavoro usati durante la creazione iniziale dello snapshot. Aumentare questo valore per velocizzare la creazione dello snapshot iniziale quando si aumenta il numero di database con mirroring. Tuttavia, è consigliabile prendere in considerazione tutti gli altri processi in background in esecuzione nel sistema prima di eseguire questa operazione.

  • azure_cdc.change_batch_buffer_size: il valore predefinito è 16 MB. Dimensioni massime del buffer (in MB) per il batch di modifiche. La tabella mostra molti dati memorizzati nel buffer fino a questo prima di essere scritti nel disco locale. A seconda della frequenza di modifica dei dati nei database con mirroring, è possibile modificare questo valore per ridurre la frequenza batch di modifica o aumentarla se si vuole assegnare priorità alla velocità effettiva complessiva.

  • azure_cdc.change_batch_export_timeout: il valore predefinito è 30. Tempo di inattività massimo (in secondi) tra i messaggi batch di modifica. Quando viene superato questo valore, il batch corrente viene contrassegnato come completato. A seconda della frequenza di modifica dei dati nei database con mirroring, è possibile modificare questo valore per ridurre la frequenza batch di modifica o aumentarla se si vuole assegnare priorità alla velocità effettiva complessiva.

  • azure_cdc.parquet_compression: il valore predefinito è ZSTD. Questo parametro è solo per uso interno, quindi non è consigliabile modificarlo.

  • azure_cdc.snapshot_buffer_size: il valore predefinito è 1000. Dimensioni massime (in MB) del buffer dello snapshot iniziale. In base alla tabella, molti dati vengono memorizzati nel buffer fino a questo prima di essere inviati a Fabric. Tenere presente che azure_cdc.snapshot_buffer_size*azure_cdc.max_snapshot_workers è il buffer di memoria totale usato durante lo snapshot iniziale.

  • azure_cdc.snapshot_export_timeout: il valore predefinito è 180. Tempo massimo (in minuti) per esportare lo snapshot iniziale. Se viene superato il tempo massimo, viene riavviato.

  • azure_cdc.prune_local_batches: l'impostazione predefinita è True. Se l'opzione è impostata, rimuovere i dati batch dal disco locale, una volta caricati e riconosciuti correttamente in wal_sender.

Monitorare

Monitorare il mirroring di Fabric nelle istanze del server flessibile di Database di Azure per PostgreSQL è essenziale per garantire che il processo di mirroring funzioni in modo fluido ed efficiente. Monitorando lo stato dei database con mirroring, è possibile identificare eventuali problemi potenziali ed eseguire azioni correttive.

È possibile usare diverse funzioni e tabelle definite dall'utente per monitorare le metriche CDC importanti nelle istanze server flessibili di Azure Database per PostgreSQL e risolvere i problemi del processo di mirroring verso Fabric.

Monitoraggio delle funzioni

La funzione di mirroring per il mirroring dell'infrastruttura in Database di Azure per PostgreSQL replica facilmente i database PostgreSQL in Microsoft Fabric, in modo da poter usare scenari avanzati di analisi e integrazione dei dati.

  • azure_cdc.list_tracked_publications(): per ogni pubblicazione nell'istanza del server flessibile di origine, restituisce una stringa delimitata da virgole contenente le informazioni seguenti

    • publicationName (text)
    • includeData (bool)
    • includeChanges (bool)
    • attivo (bool)
    • baseSnapshotDone (bool)
    • generationId (int)

  • azure_cdc.publication_status('pub_name'): per ogni pubblicazione nell'origine, l'istanza del server flessibile restituisce una stringa delimitata da virgole con le informazioni seguenti

    • <status, start_lsn, stop_lsn, flush_lsn>.
    • Lo stato è costituito da ["Nome slot", "Nome origine", "Percorso destinazione dati CDC", "Attivo", "Snapshot Completato", "Percentuale di avanzamento", "ID generazione", "ID batch completato", "ID batch caricato", "Ora di inizio CDC"]

  • azure_cdc.is_table_mirrorable('schema_name','table_name'):Dato schema e nome di tabella, restituisce se la tabella è mirrorable. Affinché una tabella sia mirrorable, deve soddisfare le condizioni seguenti:

    • I nomi di colonna non contengono i caratteri seguenti: [ ;{}\n\t=()]
    • I tipi di colonna sono uno dei tipi seguenti:
      • bigint
      • bigserial
      • boolean
      • bytes
      • character
      • character varying
      • date
      • double precision
      • integer
      • numeric
      • real
      • serial
      • oid
      • money
      • smallint
      • smallserial
      • text
      • time without time zone
      • time with time zone
      • timestamp without time zone
      • timestamp with time zone
      • uuid
    • La tabella non è una vista, una vista materializzata, una tabella esterna, una TOAST table o una tabella partizionata
    • La tabella ha una chiave primaria o un indice univoco, non nullable e non partiale. Se questi prerequisiti non sono soddisfatti, il mirroring funzionerà ancora applicando l'identità di replica FULL, ma questo avrà un impatto significativo sulle prestazioni complessive della replica e sull'utilizzo di WAL. È consigliabile avere una chiave primaria o un indice univoco per le tabelle di dimensioni non intermedie.

Tabelle di rilevamento

  • azure_cdc.tracked_publications: una riga per ogni database duplicato esistente in Fabric. Eseguire una query in questa tabella per comprendere lo stato di ogni pubblicazione.
Nome colonna Tipo Postgres Spiegazione
publication_id oid OID della pubblicazione
percorso_di_destinazione text Percorso della zona di atterraggio in Fabric OneLake
destination_format azure_cdc.data_format Formato dei dati in Azure CDC
include_data bool Indica se includere i dati dello snapshot iniziale nella pubblicazione
include_changes bool Indica se includere le modifiche nella pubblicazione
active bool Indica se la pubblicazione è attiva
snapshot_done bool Indica se lo snapshot è stato completato
snapshot_progress smallint Progresso dello snapshot
snapshot_progress_percentage text Percentuale dello stato di avanzamento dello snapshot
generation_id int Identificatore di generazione
stream_start_lsn pg_lsn Numero di sequenza del log in cui è stato avviato il flusso di modifiche
stream_start_time timestamp Timestamp dell'ora di avvio del flusso di modifiche
stream_stop_lsn pg_lsn Numero di sequenza del log in cui il flusso di modifiche è stato arrestato
snapshot_size bigint Dimensioni totali dello snapshot (in byte)
total_time int Tempo totale (in secondi) impiegato per la pubblicazione
  • azure_cdc.tracked_batches: una riga per ogni batch di modifiche acquisito e spedito a Fabric OneLake. Eseguire una query in questa tabella per comprendere quale batch è già stato acquisito e caricato in Fabric OneLake. Con la last_written_lsn colonna è possibile capire se una determinata transazione nel database di origine è già stata spedita a Fabric.
Nome Tipo Postgres Spiegazione
publication_id oid OID della pubblicazione
completed_batch_id bigint Numero di sequenza (a partire da 1) del batch. Univoco per pubblicazione
last_written_lsn pg_lsn LSN dell'ultima scrittura di questo batch
  • azure_cdc.tracked_tables: una riga per ogni tabella rilevata in tutte le pubblicazioni. Include i campi seguenti per tutte le tabelle pubblicate, in tutte le pubblicazioni. Se una tabella fa parte di due pubblicazioni, verrà elencata due volte.
Nome Tipo Postgres Spiegazione
publication_id oid OID della pubblicazione
table_oid oid Oid della tabella
sequence_number bigint numero di sequenza del file generato

Contenuto correlato

  • Last updated on