PowerScale: ошибка переноса политики SYNCIQ в Smartsync для репликации «из одной во многие» или каскадной репликации

Zhrnutie: Перенос блокируется двумя ошибками: одна — если снимок исходной системы не соответствует последнему снимку, а другая — если снимок старше самого последнего. Из-за несоответствий в конфигурациях с разветвлением по выходу или каскадных конфигурациях. ...

Tento článok sa vzťahuje na Tento článok sa nevzťahuje na Tento článok nie je viazaný na žiadny konkrétny produkt. V tomto článku nie sú uvedené všetky verzie produktov.

Symptómy

При переносе политики SyncIQ в SmartSync происходит сбой с одной из двух ошибок:

  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.

Príčina

Ошибка 1 возникает, когда для исходного базового пути имеются уже существующие наборы данных, которые SmartSync помечает как целевой набор данных. И связанный моментальный снимок, используемый для переноса и используемый исходной записью политики SyncIQ, не является моментальным снимком, используемым последним набором данных для конкретного исходного базового пути.

 

Примечание. Один из вероятных сценариев для этого — когда исходный базовый путь выступает в качестве целевого объекта для вышестоящей политики SmartSync, то есть каскадных цепочек политик.

 

Ошибка 2 возникает, когда для исходного базового пути имеются уже существующие наборы данных, которые не помечены SmartSync как целевой набор данных. А связанный моментальный снимок, используемый для переноса и используемый исходной записью политики SyncIQ, не больше и не равен моментальному снимку, который используется последним набором данных для конкретного исходного базового пути.

Riešenie

Если ошибка уже возникла, перейдите к разделу Действия по восстановлению.

Этапы превентивного переноса

Меры предосторожности, которые необходимо предпринять, прежде чем ошибки уже появятся в задании переноса. Чтобы избежать вышеупомянутых ошибок, перед запуском задачи переноса выполните следующие действия:

Конфигурация с разветвлением по выходу (A, → B + A → C)

  1. Шаг 1: Определение политики SyncIQ Интерактивные услуги доставки Documentum. Пример.

    1. Политика A → B:
      # isi sync policies view <pol_a_b> | head -2
    2. Политика A → C.
      # isi sync policies view <pol_a_c> | head -2
  2. Шаг 2: каталог исходных записей в кластере A:

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

  3. Шаг 3: Выведите список и просмотрите XML-файл, соответствующий каждому идентификатору политики, и запишите последнее значение Snap-ID:

    1. Проверьте моментальный снимок A→B (на следующем шаге результирующий идентификатор будет AX):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

    2. Проверьте снимок A→C (в следующем шаге результирующий идентификатор будет AY):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

  4. Шаг 4: Сравните значения последнего идентификатора моментального снимка. Сначала перенесите политику с более старым (младшим)последним-идентификатором моментального снимка:Если
    моментальный снимок A->B (AX) старше, чем снимок A->C (AY), например: AX = snapID 100,AY = snapID150.
    Затем сначала перенесите политику A на политику B.

    Например, если моментальный снимок A–>C (AY) старше, чем моментальный снимок A–>B (AX), например: AX = snapID 150,AY = snapID100.
    Затем сначала перенесите политику A на C.

    Если обе политики используют один и тот же моментальный снимок, например: AX = 100,AY = 100.
    Любую политику можно перенести в первую очередь. При втором переносе политики набор данных используется повторно.

Цепочка (каскадная) конфигурация (A → B → C)

  1. Синхронизация должна быть полностью завершена, при этом все кластеры, участвующие в цепочке политик, должны отражать идентичные данные.

  2. Прежде чем продолжить перенос, отключите все политики SyncIQ в цепочке. Это предотвратит запуск новых инкрементных заданий SyncIQ во время переноса. Например, в цепочке A→B→C отключите политики A→B и B→C.

  3. Важно: Миграция всегда должна начинаться с корневого (исходного) кластера. Для любого промежуточного кластера (например, B в конфигурации с 3 кластерами) все политики, исходный базовый путь которых также является целевым для другой политики SmartSync, должны использовать тот же (идентичный) моментальный снимок, что и последний набор данных для этого базового пути. Если снимки не совпадают, задание переноса будет приостановлено (но не заблокировано навсегда). Шаги восстановления, добавленные ниже в раздел Этапы восстановления.

    Перед переносом связанных политик убедитесь, что политика B→C SyncIQ использует синхронизацию на основе моментальных снимков с тем же шаблоном моментальных снимков, который создается политикой A→B в кластере B. Это гарантирует, что обе политики будут совместно использовать один и тот же базовый моментальный снимок в кластере ретрансляции.

  4. Если для политики B→C SyncIQ изначально не настроена синхронизация на основе моментальных снимков, обновите ее перед переносом, выполнив следующие действия.

    1. Шаг 1: Убедитесь, что политика A→B создает целевые моментальные снимки архива (в поле Архив моментальных снимков получателя: должно отображаться значение «Да»), а также используйте шаблон именования, отличный от шаблона именования по умолчанию 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

      Как видно из приведенного выше примера, для целевого архива моментальных снимков установлено значение «Нет», и шаблон является шаблоном по умолчанию с префиксом SIQ-*.

    2. Шаг 2: Измените политику A→B, чтобы создать архивный моментальный снимок с шаблоном, отличным от шаблона по умолчанию:

      # 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. Шаг 3: Измените политику B→C, указав на использование --schedule=when-snapshot-taken:

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

    4. Шаг 4: Активируйте задание политики A→B, чтобы убедиться, что политика B→B догоняет ее и повторно использует архивный моментальный снимок, созданный A-B>; это можно проверить, выполнив команду reports.

      # isi sync job start <A_to_B_policy>

      # isi sync reports list

      Дождитесь завершения задания политики A→B, и, в свою очередь, это запустит задание политики B→C. После завершения обоих заданий убедитесь, что моментальный снимок архива, созданный последним запуском политики A→B, повторно используется последним заданием B→C, с помощью следующей команды:

      # 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>

      Как вы могли заметить выше, идентификатор последнего моментального снимка для политики B→ C совпадает с идентификатором последнего архивного моментального снимка для A→ B. Это то состояние, в котором миграция цепной политики должна успешно пройти.

Действия для миграции в режиме восстановления

Если попытка переноса уже была предпринята и задание переноса переходит в состояние PAUSED, выполните следующие действия по восстановлению:

Конфигурация с разветвлением по выходу

Если задание переноса политики SyncIQ завершается сбоем с ошибкой, соответствующая политика SyncIQ включается снова. Ниже перечислены шаги по устранению рисков.

  1. Шаг 1. Запустите политику SyncIQ, чтобы наверстать упущенное:
    # isi sync job start <policy-name>
  2. Шаг 2. Дождитесь успешного завершения нового задания и его отображения в выходных данных отчетов:
    # isi sync reports list --policy-name <policy-name>
  3. Шаг 3. Возобновите приостановленное задание переноса SmartSync:
    # isi dm jobs resume <job_id>

Цепочка (каскадная) конфигурация

Если задание переноса политики SyncIQ завершается сбоем с ошибкой, соответствующая политика SyncIQ включается снова. Ниже перечислены шаги по устранению рисков.

  1. Шаг 1: Измените политику SyncIQ с помощью команды:
    # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
  2. Шаг 2: Запустите политику A-B> Smart Sync с помощью команды (при условии, что вышестоящая политика уже перенесена):
    # isi dm policies modify <policy_name> --run-now=yes
    Моментальный снимок будет автоматически синхронизирован с последним снимком набора данных по исходному базовому пути.
  3. Шаг 3: Возобновите задание переноса с помощью команды:
    # isi dm jobs resume <job_id>

Dotknuté produkty

PowerScale OneFS
Vlastnosti článku
Číslo článku: 000501890
Typ článku: Solution
Dátum poslednej úpravy: 08 sep 2026
Verzia:  1
Nájdite odpovede na svoje otázky od ostatných používateľov spoločnosti Dell
Služby podpory
Skontrolujte, či sa na vaše zariadenie vzťahujú služby podpory.