Metodtips för Azure SQL Data Sync

  • Artikel

Gäller för:Azure SQL Database

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

En översikt över SQL Data Sync finns i Synkronisera data i flera moln och lokala databaser med Azure SQL Data Sync.

Viktigt!

Azure SQL Data Sync stöder för närvarande inte Azure SQL Managed Instance eller Azure Synapse Analytics.

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 SQL DB-deltagarrollen. 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 hubben och medlemsdatabaserna.
      • Scheman 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 schemana 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 aktiverar granskning av din Azure SQL-databas eller aktiverar granskning i SQL Server-databasen.

Konfigurera

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 ALTER DATABASE kommandot för att öka databasens storlek när den har skapats. Se till att du håller dig inom databasens storleksgränser.

Viktigt!

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älja 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 läsa in data. Annars gör Data Sync en jämförelse rad för rad och infogning 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 avetablering av databaser.

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

Begränsningar för automatisk avetablering

SQL Data Sync har följande begränsningar för automatisk avetablering:

  • 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.
  • Index för XML-typkolumner etableras 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 etableras inte.
  • Vyer och lagrade procedurer skapas inte i måldatabasen.
  • VID UPPDATERING AV CASCADE och VID BORTTAGNING återskapas INTE CASCADE-åtgärder för begränsningar för sekundärnyckel 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 funktionen för automatisk avetablering av SQL Data Sync endast när du testar 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.

Synkronisera

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 inledande synkronisering

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.
  • Bryter mot begränsningar för sekundärnyckel.

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

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

Kommentar

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 inaktuell slutar den att fungera. När en databass status är inaktuell kan 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 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 inaktuell när ändringar i synkroniseringsgruppen inte kan spridas till resten av synkroniseringsgruppen i 45 dagar eller mer. Om du vill undvika 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.
  • Uppdatera en rad med ett värde som bryter mot en begränsning för sekundärnyckel.

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 sekundärnyckeln så att de innehåller 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 avetablering

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.

Så här återställer du från det här scenariot:

  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 avetablering ä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.

Nästa steg

Mer information om SQL Data Sync finns i:

Mer information om SQL Database finns i: