Dela via

Metodtips för Azure SQL Data Sync

  • Artikel

gäller för:Azure SQL Database

Viktig

SQL Data Sync dras tillbaka den 30 september 2027. Överväg att migrera till alternativa lösningar för datareplikering/synkronisering.

I den här artikeln beskrivs metodtips för Azure SQL Data Sync.

En översikt över SQL Data Sync finns i Vad är SQL Data Sync för Azure?

Säkerhet och tillförlitlighet

Klientagent

  • Installera klientagenten med det minst privilegierade användarkontot som har åtkomst till nätverkstjänsten.
  • Installera klientagenten på en annan server än där SQL Server är installerat.
  • Registrera inte en lokal databas med fler än en agent.
    • Undvik detta även om du synkroniserar olika tabeller för olika synkroniseringsgrupper.
    • Att registrera en lokal databas med flera klientagenter innebär utmaningar när du tar bort en av synkroniseringsgrupperna.

Databaskonton med minst nödvändiga behörigheter

  • För synkroniseringskonfiguration:

    • SQL Server-behörigheter: CREATE/ALTER TABLE, ALTER DATABASE, CREATE PROCEDURE, SELECT/ALTER SCHEMA, CREATE TYPE. Dessa behörigheter ingår (tillsammans med andra behörigheter) i den inbyggda databasrollen ddl_admin.
    • På resursgruppsnivå krävs medlemskap i rollen SQL DB-bidragsgivare. Mer information finns i Tilldela Azure-roller med hjälp av Azure-portalen. Medlemskap i bredare roller som Deltagare eller Ägare fungerar också, om det redan har tilldelats.
    • Behörigheter på prenumerationsnivå bör inte behövas, men kan ge ett förenklat (men inte minst nödvändigt) sätt att ge nödvändiga behörigheter för flera Azure Data Sync-implementeringar i en prenumeration. Ett ursprungligt, inaktuellt API krävde dessa Azure RBAC-behörigheter, men bör inte längre användas.
      • "Microsoft.Sql/locations/syncMemberOperationResults/read"
      • "Microsoft.Sql/locations/syncAgentOperationResults/read"
      • "Microsoft.Sql/locations/syncGroupOperationResults/read"

  • För pågående synkronisering.

    • SQL Server-behörigheter: SELECT-, INSERT-, UPDATE- och DELETE-behörighet för användartabeller som har valts för synkronisering. KÖR-behörighet för användardefinierade tabelltyper.
    • SQL Server-behörigheter: SELECT-, INSERT-, UPDATE- och DELETE-behörighet för synkroniseringsmetadata och systemskapade spårningstabeller. KÖR-behörighet för lagrade procedurer som skapats av tjänsten.
      • Schemat DataSync används för systemskapade objekt i hubb- och medlemsdatabaserna.
      • Scheman för dss och TaskHosting används för systemskapade objekt i databasen för synkroniseringsmetadata.

  • För avetablering.

    • SQL Server-behörigheter: ÄNDRA på alla tabeller som ingår i synkroniseringen; SELECT och DELETE i synkroniseringsmetadatatabeller; KONTROLL för synkroniseringsspårningstabeller, lagrade procedurer och användardefinierade typer.
    • För rensning tar du bort systemskapade objekt i scheman DataSync, dssoch TaskHosting.

Azure SQL Database stöder endast en enda uppsättning autentiseringsuppgifter. Tänk på följande alternativ för att utföra dessa uppgifter inom den här begränsningen:

  • Ändra autentiseringsuppgifterna för olika faser (till exempel autentiseringsuppgifter1 för installation och autentiseringsuppgifter2 för pågående).
  • Ändra behörigheten för autentiseringsuppgifterna (d.s. ändra behörigheten efter att synkroniseringen har konfigurerats).

Granskning

Vi rekommenderar att du aktiverar granskning på databasnivå i synkroniseringsgrupperna. Lär dig hur du aktivera granskning på din Azure SQL-databas eller aktivera granskning på din SQL Server-databas.

Konfiguration

Databasöverväganden och begränsningar

Databasstorlek

När du skapar en ny databas anger du den maximala storleken så att den alltid är större än den databas som du distribuerar. Om du inte anger den maximala storleken till större än den distribuerade databasen misslyckas synkroniseringen. Även om SQL Data Sync inte erbjuder automatisk tillväxt kan du köra kommandot ALTER DATABASE för att öka databasens storlek när den har skapats. Se till att du håller dig inom databasens storleksgränser.

Viktig

SQL Data Sync lagrar ytterligare metadata med varje databas. Se till att du tar hänsyn till dessa metadata när du beräknar det utrymme som behövs. Mängden extra omkostnader är relaterad till bredden på tabellerna (t.ex. smala tabeller kräver mer omkostnader) och mängden trafik.

Tabellöverväganden och begränsningar

Välj tabeller

Du behöver inte inkludera alla tabeller som finns i en databas i en synkroniseringsgrupp. De tabeller som du inkluderar i en synkroniseringsgrupp påverkar effektiviteten och kostnaderna. Inkludera tabeller och de tabeller som de är beroende av i en synkroniseringsgrupp endast om företaget behöver det.

Primärnycklar

Varje tabell i en synkroniseringsgrupp måste ha en primärnyckel. SQL Data Sync kan inte synkronisera en tabell som inte har en primärnyckel.

Testa inledande och pågående synkroniseringsprestanda innan du använder SQL Data Sync i produktion.

Tomma tabeller ger bästa möjliga prestanda

Tomma tabeller ger bästa prestanda vid initieringstid. Om måltabellen är tom använder Data Sync massinfogning för att ladda data. Annars gör Data Sync en rad-för-rad jämförelse och infogar data för att söka efter konflikter. Om prestanda inte är ett problem kan du dock konfigurera synkronisering mellan tabeller som redan innehåller data.

Etablera måldatabaser

SQL Data Sync tillhandahåller grundläggande automatisk autokonfigurering av databaser.

I det här avsnittet beskrivs begränsningarna för etablering i SQL Data Sync.

Begränsningar för automatiserad provisioning

SQL Data Sync har följande begränsningar för automatiserad provisionering:

  • Markera endast de kolumner som skapas i måltabellen. Kolumner som inte ingår i synkroniseringsgruppen etableras inte i måltabellerna.
  • Index skapas endast för valda kolumner. Om källtabellindexet har kolumner som inte ingår i synkroniseringsgruppen etableras inte dessa index i måltabellerna.
  • Indexer för XML-typkolumner tillhandahålls inte.
  • Data Sync stöder endast följande två indexegenskaper: Unik, Klustrad/Icke-klustrad. Andra egenskaper för index som IGNORE_DUP_KEY, Där filterpredikat osv. inte stöds och målindexet etableras utan dessa egenskaper även om källindexet har dessa egenskaper angivna.
  • CHECK-begränsningar har inte etablerats.
  • Befintliga utlösare i källtabellerna tillhandahålls inte.
  • Vyer och lagrade procedurer skapas inte i måldatabasen.
  • VID UPPDATERING MED CASCADE och VID BORTTAGNING MED CASCADE återskapas inte åtgärder för främmande nyckelbegränsningar i måltabellerna.
  • Om du har decimaler eller numeriska kolumner med en precision som är större än 28 kan SQL Data Sync stöta på ett konverteringsöverflödesproblem under synkroniseringen. Vi rekommenderar att du begränsar precisionen för decimaler eller numeriska kolumner till 28 eller mindre.

Rekommendationer

  • Använd kapaciteten för automatisk provisionering av SQL Data Sync endast när du provar på tjänsten.
  • Etablera databasschemat för produktion.

Var du hittar hubbdatabasen

Scenario mellan företag och moln

Minimera svarstiden genom att hålla hubbdatabasen nära den största koncentrationen av synkroniseringsgruppens databastrafik.

Scenario från moln till moln

  • När alla databaser i en synkroniseringsgrupp finns i ett datacenter bör hubben finnas i samma datacenter. Den här konfigurationen minskar svarstiden och kostnaden för dataöverföring mellan datacenter.
  • När databaserna i en synkroniseringsgrupp finns i flera datacenter bör hubben finnas i samma datacenter som majoriteten av databaserna och databastrafiken.

Blandade scenarier

Tillämpa de föregående riktlinjerna på komplexa synkroniseringsgruppskonfigurationer, till exempel sådana som är en blandning av scenarier mellan företag och moln och moln till moln.

Synkronisering

Undvik långsam och kostsam inledande synkronisering

I det här avsnittet diskuterar vi den första synkroniseringen av en synkroniseringsgrupp. Lär dig hur du förhindrar att en inledande synkronisering tar längre tid och blir dyrare än nödvändigt.

Så här fungerar den inledande synkroniseringen

När du skapar en synkroniseringsgrupp börjar du med data i endast en databas. Om du har data i flera databaser behandlar SQL Data Sync varje rad som en konflikt som måste lösas. Den här konfliktlösningen gör att den inledande synkroniseringen går långsamt. Om du har data i flera databaser kan den inledande synkroniseringen ta mellan flera dagar och flera månader, beroende på databasens storlek.

Om databaserna finns i olika datacenter måste varje rad färdas mellan de olika datacenteren. Detta ökar kostnaden för en inledande synkronisering.

Rekommendation

Om möjligt börjar du med data i endast en av synkroniseringsgruppens databaser.

Utforma för att undvika synkroniseringsloopar

En synkroniseringsloop inträffar när det finns cirkelreferenser i en synkroniseringsgrupp. I det scenariot replikeras varje ändring i en databas oändligt och cirkulärt via databaserna i synkroniseringsgruppen.

Se till att du undviker synkroniseringsloopar eftersom de orsakar prestandaförsämring och kan öka kostnaderna avsevärt.

Ändringar som inte kan spridas

Orsaker till att ändringar inte kan spridas

Ändringar kan misslyckas med att spridas av någon av följande orsaker:

  • Inkompatibilitet för schema/datatyp.
  • Infogar null i icke-nullbara kolumner.
  • Överträder främmande nyckelbegränsningar.

Vad händer när ändringar inte kan spridas?

  • Synkroniseringsgruppen visar att den är i tillståndet Varning.
  • Information visas i loggvisningsprogrammet för portalens användargränssnitt.
  • Om problemet inte har lösts på 45 dagar blir databasen inaktuell.

Notera

Dessa ändringar sprids aldrig. Det enda sättet att återställa i det här scenariot är att återskapa synkroniseringsgruppen.

Rekommendation

Övervaka synkroniseringsgruppens och databasens hälsotillstånd regelbundet via portalen och logggränssnittet.

Underhåll

Undvik inaktuella databaser och synkroniseringsgrupper

En synkroniseringsgrupp eller en databas i en synkroniseringsgrupp kan bli inaktuell. När en synkroniseringsgrupps status är inaktuellslutar den att fungera. När en databass status är inaktuellkan data gå förlorade. Det är bäst att undvika det här scenariot i stället för att försöka återställa från det.

Undvik inaktuella databaser

En databass status är inställd på inaktuell när den har varit offline i 45 dagar eller mer. Om du vill undvika en inaktuell status för en databas kontrollerar du att ingen av databaserna är offline i 45 dagar eller mer.

Undvik inaktuella synkroniseringsgrupper

Statusen för en synkroniseringsgrupp är inställd på inaktuell när en ändring i synkroniseringsgruppen inte kan spridas till resten av synkroniseringsgruppen i 45 dagar eller mer. Om du vill undvika en inaktuell status för en synkroniseringsgrupp kontrollerar du regelbundet synkroniseringsgruppens historiklogg. Kontrollera att alla konflikter har lösts och att ändringarna har spridits i synkroniseringsgruppens databaser.

En synkroniseringsgrupp kan misslyckas med att tillämpa en ändring av någon av följande orsaker:

  • Schemainkompatibilitet mellan tabeller.
  • Inkompatibilitet av data mellan tabeller.
  • Infoga en rad med ett null-värde i en kolumn som inte tillåter null-värden.
  • Uppdatering av en rad med ett värde som bryter mot en främmande nyckelbegränsning.

Så här förhindrar du inaktuella synkroniseringsgrupper:

  • Uppdatera schemat så att de värden som finns i de misslyckade raderna tillåts.
  • Uppdatera värdena för den externa nyckeln så att de inkluderar de värden som finns i de misslyckade raderna.
  • Uppdatera datavärdena på den misslyckade raden så att de är kompatibla med schemat eller sekundärnycklarna i måldatabasen.

Undvik problem med avprovisionering

I vissa fall kan avregistrering av en databas med en klientagent leda till att synkroniseringen misslyckas.

Scenario

  1. Synkroniseringsgrupp A skapades med hjälp av en SQL Database-instans och en SQL Server-databas, som är associerad med lokal agent 1.
  2. Samma lokala databas är registrerad med lokal agent 2 (den här agenten är inte associerad med någon synkroniseringsgrupp).
  3. Om du avregistrerar den lokala databasen från den lokala agenten 2 tar du bort spårnings- och metatabellerna för synkroniseringsgrupp A för den lokala databasen.
  4. Synkroniseringsgrupp A-åtgärder misslyckas med det här felet: "Det gick inte att slutföra den aktuella åtgärden eftersom databasen inte har etablerats för synkronisering eller så har du inte behörighet till synkroniseringskonfigurationstabellerna."

Lösning

För att undvika det här scenariot ska du inte registrera en databas med fler än en agent.

För att återgå från detta scenario:

  1. Ta bort databasen från varje synkroniseringsgrupp som den tillhör.
  2. Lägg till databasen i varje synkroniseringsgrupp som du tog bort den från.
  3. Distribuera varje berörd synkroniseringsgrupp (den här åtgärden etablerar databasen).

Ändra en synkroniseringsgrupp

Försök inte ta bort en databas från en synkroniseringsgrupp och redigera sedan synkroniseringsgruppen utan att först distribuera någon av ändringarna.

Ta i stället först bort en databas från en synkroniseringsgrupp. Distribuera sedan ändringen och vänta tills avetablering har slutförts. När avprovisioneringen är klar kan du redigera synkroniseringsgruppen och distribuera ändringarna.

Om du försöker ta bort en databas och sedan redigera en synkroniseringsgrupp utan att först distribuera någon av ändringarna misslyckas den ena eller den andra åtgärden. Portalgränssnittet kan bli inkonsekvent. Om detta händer uppdaterar du sidan för att återställa rätt tillstånd.

Undvik tidsgräns för schemauppdatering

Om du har ett komplext schema att synkronisera kan du stöta på en "åtgärdstimeout" under en schemauppdatering om synkroniseringsmetadatadatabasen har en lägre SKU (exempel: grundläggande).

Lösning

Du kan åtgärda det här problemet genom att skala upp dina databasresurser för synkroniseringsmetadata.

Relaterat innehåll

Mer information om SQL Data Sync finns i:

Mer information om SQL Database finns i: