Mandato de CLI de ejemplo

ibmcloud resource service-instance-update "Event Streams resource instance name" -p '{"mirroring":{"source_crn":"<source_crn>", "source_alias":"<source_alias>", "target_alias":"<target_alias>"}}'

Selecciona los temas que quieres reflejar

Cuando se complete la actualización de la instancia de servicio, debe seleccionar qué temas se reflejarán desde el clúster de origen al de destino. Esto se hace con la CLI utilizando el comando 'ibmcloud es mirroring-topic-selection-set'. Cualquier grupo de consumidores utilizado para consumir a partir de estos temas seleccionados se reflejará desde el clúster de origen hasta el clúster de destino. La selección de temas tiene el formato de un patrón de expresión regular o una lista separada por comas de dichos patrones.

El mandato siguiente selecciona todos los temas que se van a duplicar:

ibmcloud es mirroring-topic-selection-set --select '.*'

Puede seleccionar temas listando los temas que desea duplicar como se indica a continuación:

ibmcloud es mirroring-topic-selection-set --select topic1,topic2,topic3

Para obtener más información sobre cómo realizar la selección, consulte Duplicación de controles de usuario.

Una vez completada la selección de temas, el clúster de destino muestra los temas que se han seleccionado para la duplicación utilizando los controles de usuario de duplicación con el sufijo del alias del clúster de origen.

Paso 3.1:. Especifique cómo se transforman los nombres de los temas y los grupos

Puede especificar reglas de transformación que le permitan reflejar datos en temas con diferentes nombres en el clúster de destino. Los tres escenarios siguientes describen posibles transformaciones y explican los casos de uso de cada una.

Puede especificar qué temas o grupos de consumidores se reflejan en cualquier momento una vez que se haya habilitado el reflejo, sin embargo, la transformación de temas o grupos solo es posible en el momento en que se habilita el reflejo. Si la duplicación ya está habilitada, será necesario deshabilitarla antes de realizar una solicitud de habilitación posterior para especificar la transformación de temas o grupos.

Escenario 1: Transformación de temas eliminando el prefijo o sufijo antiguo y añadiendo un prefijo o sufijo nuevo

Configure los cuatro parámetros adicionales siguientes.

| Parámetros requeridos para renombrar temas Descripción | -- | -- | | remove_prefix | El prefijo a eliminar de los nombres de temas en el cluster de origen. | | remove_suffix | El sufijo a eliminar de los nombres de temas en el cluster de origen. | | add_prefix | El prefijo a añadir a los nombres de temas en el cluster de destino. | | add_suffix | El sufijo a añadir a los nombres de temas en el cluster de destino. |

El comando ibmcloud resource service-instance-update debe especificarse a través del argumento de línea de comandos -p. Cuando se especifican estas opciones, solo los temas con los prefijos o sufijos coincidentes serán aptos para la duplicación. Por ejemplo, si tiene un remove_prefix de app1- y especifica una selección de temas de abc.*, solo se reflejarán los temas que empiecen por app1-abc.

Si especifica el tipo de transformación «rename» (cambiar nombre) y no especifica los parámetros para add_prefix o add_suffix, el tema reflejado en el clúster de destino tendrá estos parámetros eliminados. Los patrones de tema se aplican al nombre del tema después de eliminar cualquier prefijo o sufijo de origen y antes de añadir cualquier prefijo o sufijo.

Consulte el siguiente ejemplo de comando CLI:

{
  "mirroring": {
    "source_crn": "crn:v1:...",
    "source_alias": "source",
    "target_alias": "target",
    "options": {
      "topic_name_transform": {
        "type": "rename",
        "rename": {
          "add_prefix": "newprefix-",
          "remove_prefix": "oldprefix-",
          "add_suffix": "-newsuffix",
          "remove_suffix": "-oldsuffix"
        }
      }
    }
  }
}

Escenario 2: Añadir el alias de origen como sufijo a los temas reflejados

Aplica una transformación de nombre de tema con el tipo topic_name_transform establecido en use_alias. Con esta configuración, un tema llamado app1-topic en el clúster de origen se reflejará en un tema llamado app1-topic.source en el clúster de destino, porque el alias de origen especificado en la configuración es source.

Consulte el siguiente ejemplo de comando CLI:

{
  "mirroring": {
    "source_crn": "crn:v1:...",
    "source_alias": "source",
    "target_alias": "target",
    "options": {
        "topic_name_transform": {
            "type": "use_alias"
      }
    }
  }
}

Escenario 3: Los temas se reflejan sin cambiar sus nombres

En este escenario, también aplica el topic_name_transform con el tipo establecido en none. Con esta configuración, un tema llamado app1-topic en el clúster de origen se reflejará en un tema llamado app1-topic en el clúster de destino.

Consulte el siguiente ejemplo de comando CLI:

{
  "mirroring": {
    "source_crn": "crn:v1:...",
    "source_alias": "source",
    "target_alias": "target",
    "options": {
        "topic_name_transform": {
            "type": "none"
      }
    }
  }
}

Paso 3.2:. Transformación de los ID de grupo de consumidores correspondientes

De forma predeterminada, Mirror Maker no modificará los ID de grupo de consumidores al duplicar en el clúster de destino. Sin embargo, Event Streams le permite modificar los datos de los ID de grupo, como se describe en los dos escenarios siguientes. De forma similar a los temas, los patrones de ID de grupo se aplican después de eliminar cualquier prefijo o sufijo de origen y antes de añadir cualquier prefijo o sufijo. Si especifica el tipo de transformación «rename» (cambiar nombre) y no especifica los parámetros para add_prefix o add_suffix, el ID de grupo reflejado en el clúster de destino tendrá estos parámetros eliminados.

El comando ibmcloud resource service-instance-update debe especificarse a través del argumento de línea de comandos -p.

Escenario 1: Transformar el ID de grupo eliminando el prefijo o sufijo antiguo y añadiendo un prefijo o sufijo nuevo

Configure los cuatro parámetros adicionales siguientes.

Cuando se especifican estas opciones, solo los ID de grupo con los prefijos o sufijos coincidentes serán elegibles para la duplicación. Por ejemplo, si tiene un remove_prefix de aaa y add_prefix de bbb, los grupos de consumidores que comiencen con aaa-group-id en el clúster de origen se reflejarán en bbb-group-id en el clúster de destino.

Consulte el siguiente ejemplo de comando CLI:

{
  "group_id_transform": {
    "type": "rename",
    "rename": {
       "add_prefix": "newprefix-",
       "remove_prefix": "oldprefix-",
       "add_suffix": "-newsuffix",
       "remove_suffix": "-oldsuffix"
    }
  }
}

Escenario 2: Los ID de los grupos de consumidores se duplican sin modificar sus nombres

En este escenario, también aplica el topic_name_transform con el tipo establecido en none. Con esta configuración, un tema llamado aaa-group-id en el clúster de origen se reflejará en un tema llamado aaa-group-id en el clúster de destino.

Consulte el siguiente ejemplo de comando CLI:

"group_id_transform": {
  "type": "none"
}

Precauciones

Antes de sincronizar esquemas mediante mirroring, revise las siguientes precauciones:

1. Se necesita un periodo de mantenimiento mientras se exportan/importan los esquemas de forma masiva entre los dos registros (unas horas o menos).
2. Para que el renombramiento de temas funcione, los esquemas deben utilizar Confluent Avro Serdes, de modo que el tema pueda derivarse del nombre del tema. Confluent Avro Serdes porque el tema asociado a un esquema puede derivarse del nombre del tema (por ejemplo, para las estrategias de denominación de temas y temas/temas de registro).
3. La duplicación de la autorización de S2S debe ser ininterrumpida; la desactivación de la autorización de s2s o la duplicación impedirá que se reenvíen las solicitudes de registro de esquemas.
4. Si se requiere una transformación, el registro de esquemas de la instancia de destino debe configurarse con reglas de renombrado de temas antes de que tenga lugar cualquier migración.
5. Las reglas de renombrado no pueden modificarse hasta que la migración haya finalizado. Realizar cambios durante la migración provocará incoherencias entre los registros.

Instrucciones

Las siguientes instrucciones describen cómo puede utilizar la duplicación del registro de esquemas para mover esquemas entre dos instancias.

Todavía no se ha añadido una utilidad de exportación a la CLI.

ibmcloud resource service-instance-update \
"trgt-instance-name" \
-p '{
"mirroring": {
"source_crn": "<src instance crn>",
"source_alias": "source",
"target_alias": "target",
"schemas": "proxied"
}
}'

Transformación del nombre del tema

Los nombres de los temas pueden transformarse durante el reenvío. Por ejemplo, con las reglas adecuadas,old-my-topic podría convertirse en new-my-topic. Cuando está activada, la instancia de origen sólo reconoce el nombre original, mientras que la instancia de destino sólo reconoce el nuevo nombre de tema (transformado). Todos los resultados devueltos se transforman en consecuencia.

Si no se proporcionan reglas de transformación, se utiliza use_alias, en línea con el comportamiento de duplicación existente en Event Streams. Para reenviar sin cambiar los nombres de los temas, utilice topic_name_transform tipo none. La transformación se configura utilizando los campos de transformación existentes en la CLI.

Flujo migratorio

Al migrar entre dos instancias de Event Streams, se sugiere el siguiente flujo.

1. Active la duplicación entre dos instancias, especificando schemas: proxied.
2. Actualice sus aplicaciones para que utilicen el registro del esquema de destino.
3. Bloquee cualquier escritura en el registro de destino cambiando a schemas: read-only. Antes de realizar este cambio, la duplicación debe desactivarse momentáneamente.
4. Exporta todos los esquemas de la instancia de origen.
5. Importa todos los esquemas exportados desde la instancia de origen a la de destino. Esto puede hacerse utilizando la CLI IBM Cloud®: ibmcloud [...].
6. Desactiva la duplicación.

Exportación de esquemas

Para obtener información más detallada, consulte la documentación de Confluent.

La CLI Event Streams requiere que las importaciones de esquemas tengan un valor v1 exportVersion.

1. Descargue el último código fuente de v2.x.x, por ejemplo, https://github.com/Apicurio/apicurio-registry/archive/refs/tags/2.6.13.Final.zip.

2. Cree el cliente de exportación: mvn -pl utils/exportConfluent -am -DskipTests -Pprod package.

3. Ejecute el exportador (guarda la salida en confluent-schema-registry-export.zip ):

   java -jar utils/exportConfluent/target/apicurio-registry-utils-exportConfluent-2.6.13.Final.jar \
   "https://token:<password>@<my-event-streams-instance.com>/confluent" \
   --client-props basic.auth.credentials.source=URL
   

Importación de esquemas

Los esquemas pueden importarse utilizando la CLI Event Streams.

1. Asegúrese de tener instalado el plugin event-streams[es]: ibmcloud plugin list.

2. Conéctese a IBM Cloud®: ibmcloud login [...].

3. Inicialice la instancia Event Streams a la que desea importar: ibmcloud es init.

4. Importe el esquema:

   ibmcloud es schema-import \
   -f confluent-schema-registry-export.zip