Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Vigtigt!
Denne funktion er i prøveversion.
Spejling i Fabric giver en nem oplevelse til at undgå komplekse ETL (Extract Transform Load) og integrere din eksisterende Azure Database for MySQL-ejendom med resten af dine data i Microsoft Fabric. Du kan løbende replikere din eksisterende Azure Database for MySQL direkte ind i Fabrics OneLake, uanset om dine servere er offentligt tilgængelige, netværksisolerede via virtuelle netværk eller private endepunkter, eller konfigureret til høj tilgængelighed. Inde i Fabric kan du låse op for kraftfuld forretningsintelligens, kunstig intelligens, dataingeniørarbejde, datavidenskab og datadelingsscenarier.
For en vejledning i at konfigurere din Azure Database til MySQL Mirroring i Fabric, se Vejledning: Opret en spejlet database fra Azure Database for MySQL i Microsoft Fabric (forhåndsvisning).
Hvorfor bruge spejling i stof?
Ved at bruge Mirroring in Fabric behøver du ikke samle forskellige tjenester fra flere leverandører. Brug i stedet et højt integreret, end-to-end og brugervenligt produkt, der forenkler dine analysebehov. Det er bygget til åbenhed og samarbejde mellem Microsoft, Azure Database for MySQL og de tusindvis af teknologiløsninger, der kan læse det open source Delta Lake-tabelformat.
Hvilke analyseoplevelser er indbygget?
Spejlede databaser er et element i Fabric Data Warehousing, der er forskelligt fra Warehouse - og SQL-analyseslutpunktet.
Spejling opretter disse elementer i dit Fabric-arbejdsrum:
- Det spejlede databaseelement. Spejling styrer replikeringen af data til OneLake og konvertering til Parquet i et analyseklart format. Denne proces muliggør downstream-scenarier som data engineering, data science og mere.
- Et SQL-analyseslutpunkt
Hver spejlet database i Azure Database for MySQL har et autogenereret SQL-analyse-endpoint , der giver en rig analytisk oplevelse oven på de Delta-tabeller, der er oprettet af spejlingsprocessen. Brugere har adgang til velkendte T-SQL-kommandoer, der kan definere og forespørge dataobjekter, men kan ikke manipulere dataene fra SQL-analyse-endpointet, da det er en skrivebeskyttet kopi. Du kan udføre følgende handlinger i SQL Analytics-slutpunktet:
- Udforsk tabellerne, der refererer til data i dine Delta Lake-tabeller fra Azure Database for MySQL.
- Opret forespørgsler og visninger uden kode, og udforsk data visuelt uden at skrive en kodelinje.
- Udvikl SQL-visninger, indbyggede TVF'er (tabelværdifunktioner) og lagrede procedurer for at indkapsle din semantik og forretningslogik i T-SQL.
- Administrer tilladelser til objekterne.
- Forespørg på data i andre lagersteder og søhuse i samme arbejdsområde.
Ud over SQL-forespørgselseditoren findes der et bredt økosystem af værktøjer, der kan forespørge SQL-analyse-endpointet, herunder SQL Server Management Studio (SSMS),mssql-udvidelsen med Visual Studio Code og endda GitHub Copilot.
Spejlede databaser tilbyder også ét-klik integration med Microsoft Power BI inden for Fabric, hvilket muliggør hurtig rapportering direkte fra det spejlede data- eller SQL-analyse-endpoint.
Netværkskrav
Spejling understøtter både offentligt tilgængelige servere og netværksisolerede konfigurationer, herunder servere hostet i virtuelle netværk. Hvis din server ikke er offentligt tilgængelig og ikke tillader offentlig adgang til at forbinde til den, kan du oprette en virtuel netværksdatagateway eller opsætte en lokal datagateway til at spejle dataene. Sørg for, at Azure Virtual Network eller gateway-maskinens netværk kan forbinde til Azure Database for MySQL og er tilladt af firewall-reglen.
Aktive transaktioner, arbejdsbelastninger og replikatorprogramadfærd
Aktive eller langvarige transaktioner kan forsinke binær log (binlog) rensning, indtil transaktionen commit, og eventuel nedstrøms replikering eller migrationsproces indhenter det. Denne forsinkelse kan få binlog-lagring til at vokse uventet, så overvåg lagerudnyttelsen på kildeserveren for at undgå pladsudtømning.
Under det indledende snapshot eller databelastning er højere CPU- og IOPS-forbrug normalt, da data læses og kopieres. Arbejdsbelastninger med hyppige UPDATE- eller DELETE-operationer kan generere ekstra redo- og binlog-aktivitet, hvilket yderligere øger IO- og lagerforbruget.
Overvåg lager, IOPS og langvarige transaktioner for at sikre tilstrækkelig kapacitet gennem hele processen.
Understøttelse af beregningsniveau
Kildekoden Azure Database for MySQL kan bruge enten et General Purpose eller et Memory Optimized compute-niveau. Burstable compute tier understøttes ikke som kilde til spejling.
For mere information om beregningsniveauer tilgængelige i Azure Database for MySQL, se serviceniveauer.