PowerScale: Smartsyncs SYNCIQ-politikmigreringsfejl for en-til-mange- eller kaskadereplikering

Summary: Overflytning blokeres af to fejl: en, når kildesnapshottet ikke stemmer overens med det nyeste snapshot, og en anden, når det er ældre end den nyeste. På grund af uoverensstemmelser i fan-out eller kaskadeopsætninger. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

SmartSyncs migrering af SyncIQ-politikken mislykkes med en af to fejl:

  1. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) does not match latest dataset snapshot (<snapshot-id>) for the source basepath (<source-base-path>). This source basepath may act as a target for an existing SmartSync policy. Hence, the SIQ policy migration can't proceed unless the two snapshots are identical. Start the SIQ policy to match the latest dataset snapshot (<snapshot-id>) in source.
  2. Error Message: Migration blocked: Source record snapshot (<snapshot-id>) is older than the snapshot (<snapshot-id>) associated with the latest dataset (<dataset details>) for the source basepath (<source-base-path>). Replicate to the latest snapshot or above to proceed with the SIQ policy migration.

Cause

Fejl 1 opstår, når kildebasisstien har allerede eksisterende datasæt, der er markeret som et måldatasæt af SmartSync. Og det tilknyttede snapshot, der bruges til migrering, og som bruges af SyncIQ-politikkens kildepost, er ikke det samme, som bruges af det seneste datasæt for den specifikke kildebasesti.

 

Bemærk: Et sandsynligt scenarie, hvor dette sker, er, når kildebasisstien fungerer som et mål for en opstrøms SmartSync-politik, dvs. kaskadekædede politikker.

 

Fejl 2 opstår, når kildebasisstien har allerede eksisterende datasæt, der ikke er markeret som et måldatasæt af SmartSync. Og det tilknyttede snapshot, der bruges til migrering, og som bruges af SyncIQ-politikkens kildepost, er ikke større end eller lig med det snapshot, der bruges af det seneste datasæt for den specifikke kildebasesti.

Resolution

Hvis fejlen allerede er opstået, skal du gå til afsnittet Genoprettelsestrin.

Trin til forebyggende migrering

Forholdsregler, der skal udføres, før fejlene allerede vises i migreringsjobbet. Før du starter migreringsjobbet, skal du udføre følgende trin for at undgå ovennævnte fejl:

Konfiguration af aftapning (A → B + A → C)

  1. Trin 1: Identificer din SyncIQ-politik Documentum interaktive leveringstjenester. For eksempel:

    1. Politik A → B:
      # isi sync policies view <pol_a_b> | head -2
    2. Politik A → C:
      # isi sync policies view <pol_a_c> | head -2
  2. Trin 2: Mappen med kildeposter på klynge A:

    # cd /ifs/.ifsvar/modules/tsm/config/source_records/

  3. Trin 3: Angiv og få vist den XML-fil, der svarer til hvert politik-id, og noter værdien for det seneste snap-id:

    1. Kontrollér A→B-snapshot (det resulterende id bliver AX i næste trin):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

    2. Kontroller A→C snapshot (det resulterende id vil være AY i næste trin):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

  4. Trin 4: Sammenlign de seneste snap-id-værdier. Overfør politikken med det ældre (nederste)seneste-snap-id først:
    Hvis A-B-snapshottet (AX) er ældre end A-C-snapshottet (AY), f.eks.: AX = snapID 100,AY = snapID150.
    Derefter skal du først overføre A til B-politikken.

    Hvis A-til-C-snapshottet (AY) er ældre end A-til-B-snapshottet (AX), f.eks.: AX = snapID 150,AY = snapID100.
    Derefter skal du først migrere A til C-politikken.

    Hvis begge politikker bruger det samme øjebliksbillede, f.eks.: AX = 100,AY = 100.
    Begge politikker kan migreres først. Den anden politikmigrering genbruger datasættet.

Sammenkædet (overlappet) konfiguration (A → B → C)

  1. Synkroniseringen bør være fuldført fuldt ud, så det sikres, at alle klynger, der er involveret i politikkæden, afspejler identiske data.

  2. Deaktiver alle SyncIQ-politikker i kæden, før du fortsætter med migreringen. Dette forhindrer, at nye trinvise SyncIQ-job udløses, mens migreringen er i gang. I en A→B→C-kæde skal du f.eks. deaktivere både A→B- og B→C-politikkerne.

  3. Vigtigt! Overflytningen skal altid begynde fra rodklyngen (kilden). For enhver mellemliggende klynge (f.eks. B i en opsætning med 3 klynger) skal alle politikker, hvis kildeoprindelige sti også er et mål for en anden SmartSync-politik, bruge det samme (identiske) snapshot som det seneste datasæt for den pågældende basissti. Hvis snapshots ikke stemmer overens, sættes overførselsjobbet på pause (blokeres ikke permanent). Gendannelsestrin tilføjet nedenfor i afsnittet Gendannelsestrin.

    Før du overfører sammenkædede politikker, skal du sikre dig, at B→C SyncIQ-politikken bruger snapshotbaseret synkronisering med det samme snapshotmønster, som produceres af A→B-politikken på klynge B. Dette sikrer, at begge politikker deler den samme snapshot-basislinje på relæklyngen.

  4. Hvis B→C SyncIQ-politikken ikke oprindeligt blev konfigureret med snapshotbaseret synkronisering, skal du opdatere den før overførslen ved hjælp af følgende trin:

    1. Trin 1: Kontroller, at A→B-politikken opretter arkivsnapshots af destinationer (Target Snapshot Archive: bør vise Ja) samt med et andet navngivningsmønster end standardnavngivningsmønsteret for SIQ-*.

      # isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: No Target Snapshot Pattern: SIQ-%{SrcCluster}-%{PolicyName}-%Y-%m-%d_%H-%M-%S

      Som du vil bemærke i ovenstående eksempel, er Target Snapshot Archive indstillet til "Nej", og mønsteret er standard med et præfiks på SIQ-*.

    2. Trin 2: Rediger A→ B-politikken for at oprette arkivsnapshot med et andet mønster end standardmønsteret:

      # isi sync policies modify <A_to_B_policy> --target-snapshot-archive True --target-snapshot-pattern 'snapB-%{PolicyName}-%Y-%m-%d'

      # isi sync policies view pol_wJ9n-a2b | grep -E "Target Snapshot Archive|Target Snapshot Pattern" Target Snapshot Archive: Yes Target Snapshot Pattern: snapB-%{PolicyName}-%Y-%m-%d

    3. Trin 3: Rediger B→C-politikken til at bruge --schedule=when-snapshot-taken:

      # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken

    4. Trin 4: Udløs A→B-politikkens job for at sikre, at B→C-politikken indhenter den og genbruger det arkivsnapshot, der er oprettet af A-B>. Du kan kontrollere ved at køre kommandoen rapporter.

      # isi sync job start <A_to_B_policy>

      # isi sync reports list

      Vent på, at både A→B-politikkens job er afsluttet, og til gengæld vil det udløse B→C-politikkens job. Når begge job er fuldført, skal du kontrollere, at det arkivsnapshot, der er oprettet af A→B-politikkens seneste kørsel, genbruges af det seneste job B→C ved hjælp af følgende kommando:

      # cat /ifs/.ifsvar/modules/tsm/config/target_records/<A_to_B_policy_Id>.xml | grep latest-archive-snap 
         <latest-archive-snap-alias>621</latest-archive-snap-alias> 
               <latest-archive-snap>625</latest-archive-snap>

      # cat /ifs/.ifsvar/modules/tsm/config/source_records/<B_to_C_policy_Id>.xml | grep latest-snap-id
                 <latest-snap-id>625</latest-snap-id>
         <restore-latest-snap-id>0</restore-latest-snap-id>

      Som du vil bemærke ovenfor, er politikken latest-snap-id for B→ C den samme som latest-archive-snap for A→ B. Hvilket er staten for, at lænket politiks migration kan gå igennem med succes.

Trin til migrering af gendannelse

Hvis overførslen allerede er forsøgt, og overførselsjobbet går i pausetilstand, skal du følge disse genoprettelsestrin:

Konfiguration af fan-out

Når et migreringsjob for en SyncIQ-politik mislykkes med fejlen, aktiveres den tilsvarende SyncIQ-politik tilbage. Afbødningstrinnene er:

  1. Trin 1: Kør SyncIQ-politikken for at indhente det forsømte:
    # isi sync job start <policy-name>
  2. Trin 2: Vent på, at den nye jobkørsel afsluttes og vises i rapportoutputtet:
    # isi sync reports list --policy-name <policy-name>
  3. Trin 3: Genoptag det SmartSync-overførselsjob, der var sat på pause:
    # isi dm jobs resume <job_id>

Sammenkædet (overlappet) konfiguration

Når et migreringsjob for en SyncIQ-politik mislykkes med fejlen, aktiveres den tilsvarende SyncIQ-politik tilbage. Afbødningstrinnene er:

  1. Trin 1: Rediger SyncIQ-politikken ved hjælp af kommandoen:
    # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
  2. Trin 2: Kør AB Smart Sync-politik> ved hjælp af kommando (forudsat at opstrømspolitikken allerede er migreret):
    # isi dm policies modify <policy_name> --run-now=yes
    Snapshottet synkroniseres automatisk med det nyeste snapshot af datasættet på kildestien.
  3. Trin 3: Genoptag overførselsjobbet ved hjælp af kommandoen:
    # isi dm jobs resume <job_id>

Affected Products

PowerScale OneFS
Article Properties
Article Number: 000501890
Article Type: Solution
Last Modified: 08 Sept 2026
Version:  1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.