PowerScale: Error de migración de políticas de SYNCIQ de Smartsync para replicación de uno a muchos o en cascada

Summary: La migración está bloqueada por dos errores: uno cuando la instantánea de origen no coincide con la instantánea más reciente y otro cuando es más antigua que la última. Debido a incompatibilidades en las configuraciones de distribución ramificada o en cascada. ...

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

La migración de la política de SyncIQ de SmartSync falla con uno de dos errores:

  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

El error 1 se produce cuando la ruta base de origen tiene conjuntos de datos preexistentes que SmartSync marca como conjuntos de datos de destino. Y la instantánea asociada que se utiliza para la migración, utilizada por el registro de origen de la política de SyncIQ, no es la misma que utiliza el conjunto de datos más reciente para la ruta de origen específica.

 

Nota: Un escenario probable para que esto ocurra es cuando la ruta base de origen actúa como un destino para una política de SmartSync ascendente, es decir, políticas encadenadas en cascada.

 

El error 2 se produce cuando la ruta base de origen tiene conjuntos de datos preexistentes que SmartSync no marcó como conjuntos de datos de destino. Y la instantánea asociada que se utiliza para la migración, utilizada por el registro de origen de la política de SyncIQ, no es mayor ni igual que la instantánea que utiliza el conjunto de datos más reciente para la ruta de base de origen específica.

Resolution

Si el error ya ocurrió, vaya a la sección Pasos de recuperación.

Pasos de migración preventiva

Pasos de precaución que se deben realizar antes de que los errores ya aparezcan en el trabajo de migración. Antes de iniciar el trabajo de migración, realice los siguientes pasos para evitar los errores mencionados anteriormente:

Configuración de distribución ramificada (A → B + A → C)

  1. Paso 1: Identifique su política de SyncIQ Servicios de entrega interactiva de Documentum. Por ejemplo:

    1. Política A → B:
      # isi sync policies view <pol_a_b> | head -2
    2. Política A → C:
      # isi sync policies view <pol_a_c> | head -2
  2. Paso 2: el directorio de registros fuente en el clúster A:

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

  3. Paso 3: Enumere y vea el archivo XML correspondiente a cada ID de política y anote el valor de latest-snap-id:

    1. Compruebe la instantánea A→B (el ID resultante será AX en el siguiente paso):
      # grep '<latest-snap-id>' <pol_a_b_ID>.xml

    2. Compruebe la instantánea →C (el ID resultante será AY en el siguiente paso):
      # grep '<latest-snap-id>' <pol_a_c_ID>.xml

  4. Paso 4: Compare los valores de latest-snap-id. Migre la política con el más antiguo (lower)latest-snap-id primero:
    si la instantánea de A a B (AX) es más antigua que la instantánea de A a C (AY), por ejemplo: AX = snapID 100,AY = snapID150.
    Luego, migre primero la política A a B.

    Si la instantánea de A a C (AY) es más antigua que la instantánea de A a B (AX), por ejemplo: AX = snapID 150,AY = snapID100.
    Luego, migre primero la política de A a C.

    Si ambas políticas utilizan la misma instantánea, por ejemplo: AX = 100,AY = 100.
    Cualquiera de las políticas se puede migrar primero. La segunda migración de políticas reutiliza el conjunto de datos.

Configuración en cadena (en cascada) (A → B → C)

  1. La sincronización debe completarse por completo, asegurándose de que todos los clústeres involucrados en el encadenamiento de políticas reflejen datos idénticos.

  2. Deshabilite todas las políticas de SyncIQ en la cadena antes de continuar con la migración. Esto evita que se activen nuevos trabajos incrementales de SyncIQ mientras la migración está en curso. Por ejemplo, en una cadena A→B→C, deshabilite las políticas A→B y B→C.

  3. Importante: La migración siempre debe comenzar desde el clúster raíz (fuente). Para cualquier clúster intermedio (como B en una configuración de 3 clústeres), todas las políticas cuya ruta base fuente también sea un destino para otra política de SmartSync deben utilizar la misma instantánea (idéntica) que el conjunto de datos más reciente para esa ruta base. Si las instantáneas no coinciden, el trabajo de migración se pondrá en pausa (no se bloqueará permanentemente). Los pasos de recuperación se agregan a continuación en la sección Pasos de recuperación.

    Antes de migrar políticas encadenadas, asegúrese de que la política de B→C SyncIQ utilice sincronización basada en instantáneas con el mismo patrón de instantáneas producido por la política A→B en el clúster B. Esto garantiza que ambas políticas compartan la misma base de instantáneas en el clúster de retransmisión.

  4. Si la política de B→C SyncIQ no se configuró originalmente con sincronización basada en instantáneas, actualícela antes de la migración mediante los siguientes pasos:

    1. Paso 1: Verifique que la política A→B cree instantáneas de destino de archivo (Target Snapshot Archive: debe mostrar Yes), así como con un patrón de nombres distinto del patrón de nombres predeterminado de 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

      Como notará en el ejemplo anterior, Target Snapshot Archive se configura en "No" y el patrón es el predeterminado con el prefijo SIQ-*.

    2. Paso 2: Modifique la política A→ B para crear una instantánea de archivo con un patrón diferente al predeterminado:

      # 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. Paso 3: Modifique la política de B→C para utilizar --schedule=when-snapshot-taken:

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

    4. Paso 4: Active el trabajo de la política A→B para asegurarse de que la política B→C se ponga al día y reutilice la instantánea de archivo creada por A-B>; puede verificarlo mediante la ejecución del comando reports.

      # isi sync job start <A_to_B_policy>

      # isi sync reports list

      Espere a que se complete el trabajo de la política A→B y, a su vez, eso activará el trabajo de la política B→C. Una vez que se completen ambos trabajos, valide que el trabajo más reciente de B→C reutilice la instantánea de archivo creada por la última ejecución de la política de A→B mediante el siguiente comando:

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

      Como notará anteriormente, latest-snap-id para la política B→ C es igual que latest-archive-snap para A→ B. Este es el estado para que la migración de la política encadenada se realice correctamente.

Pasos de migración de recuperación

Si ya se intentó la migración y el trabajo de migración entra en un estado PAUSED, siga estos pasos de recuperación:

Configuración de distribución ramificada

Cuando un trabajo de migración de políticas de SyncIQ falla con el error, la política de SyncIQ correspondiente se vuelve a habilitar. Los pasos de mitigación son los siguientes:

  1. Paso 1: Ejecute la política de SyncIQ para ponerse al día:
    # isi sync job start <policy-name>
  2. Paso 2: Espere hasta que la nueva ejecución del trabajo finalice correctamente y aparezca en el resultado del informe:
    # isi sync reports list --policy-name <policy-name>
  3. Paso 3: Reanude el trabajo de migración de SmartSync que se había pausado:
    # isi dm jobs resume <job_id>

Configuración en cadena (en cascada)

Cuando un trabajo de migración de políticas de SyncIQ falla con el error, la política de SyncIQ correspondiente se vuelve a habilitar. Los pasos de mitigación son los siguientes:

  1. Paso 1: Modifique la política de SyncIQ mediante el comando:
    # isi sync policies modify <B_to_C_policy> --schedule=when-snapshot-taken
  2. Paso 2: Ejecute la política A-B> de Smart Sync mediante el comando (suponiendo que la política ascendente ya está migrada):
    # isi dm policies modify <policy_name> --run-now=yes
    Sincronizará automáticamente la instantánea con la instantánea del conjunto de datos más reciente en la ruta base de origen.
  3. Paso 3: Reanude el trabajo de migración mediante el comando:
    # 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.