Yugabyte: objetos y operaciones soportados

En la siguiente lista se describen los objetos y las operaciones soportados para Oracle GoldenGate for Yugabyte:

• Oracle GoldenGate Extract soporta el plugin yboutput.

• La identidad de réplica CHANGE es el valor nativo para Yugabyte y se recomienda al utilizar el plugin yboutput, ya que proporciona un mejor rendimiento en comparación con otros tipos de identidad de réplica.

• La replicación bidireccional está soportada con el plugin yboutput. Al utilizar el plugin yboutput para la replicación bidireccional, se debe crear la tabla de puntos de control de Oracle GoldenGate y se debe incluir en la lista de publicación antes de iniciar el proceso de extracción de CDC.

  Además, la ranura de replicación se debe crear solo después de que la tabla de puntos de control se haya creado y agregado a la publicación.

• La replicación bidireccional está soportada con el plugin test_decoding. Todas las tablas, incluidas las tablas de puntos de control, se deben crear antes de registrar cualquier Extract al utilizar el plugin test_decoding. En el caso del plugin PGOUTPUT, la tabla de puntos de control junto con todas las demás tablas interesadas deben incluirse en la publicación antes del registro de Extract.

Nota: No borre ninguna tabla, incluidas las tablas de puntos de control.

• Solo se admiten varias operaciones de truncamiento en el plugin pgoutput/yboutput.

• Comando de registro integrado con la opción pgplugintype:

  • La opción pgplugintype está disponible tanto en la interfaz web como en el cliente de administración en el comando REGISTER EXTRACT. Esta opción permite seleccionar test_decoding o pgoutput como plugin de descodificación lógica.

  • Al especificar pgplugintype pgoutput, el módulo subyacente utiliza automáticamente el plugin yboutput para registrar el proceso de extracción.

  • Si no especifica ningún pgplugintype, el Extract de CDC se registra mediante el plugin test_decoding, por defecto.

  • Para registrarse explícitamente con el plugin yboutput en Yugabyte, debe especificar el tipo de plugin pgoutput.

  Sintaxis:

    <pre class="copy"><code>REGISTER EXTRACT *group_name* PGPLUGINTYPE *plugin_option*;</code></pre>
  

  Ejemplo:

    <pre class="copy"><code>REGISTER EXTRACT ext_yb PGPLUGINTYPE pgoutput;</code></pre>
  

• El parámetro STREAMINGOPTIONS se ha introducido en TRANLOGOPTIONS. Este parámetro permite especificar publication_name para el comando de inicio de replicación.

  Ejemplo:

  TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  Al utilizar este parámetro, se deben tener en cuenta las siguientes directrices y restricciones:

  • Las publicaciones se deben crear antes de registrar el proceso de extracción.

  Los nombres de publicación no deben contener caracteres especiales, como Coma (,) Comillas simples (') Comillas dobles (").

  • Se pueden especificar varios nombres de publicación como una lista separada por comas en publication_names. Por ejemplo:

    TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  El nombre de la publicación final de la lista debe terminar con un punto y coma (;)

Limitaciones de yugabytes

Tenga en cuenta las siguientes limitaciones para la base de datos de Yugabyte al configurarla para su captura y entrega:

• Faltan transacciones de LOB grandes: cuando un LOB (objeto grande) tiene un tamaño entre 200 MB y 400 MB, es posible que falte toda la transacción, ya sea INSERT o UPDATE, en el flujo de CDC.

• Diferencia de datos en sentido descendente debido a varias actualizaciones en la misma transacción: cuando se producen varias actualizaciones en la misma transacción, es posible que el módulo CDCSDK de Yugabyte no envíe la imagen AFTER correcta si la identidad de réplica de la tabla está definida en FULL o DEFAULT. Esto puede dar lugar a discrepancias de datos para la imagen AFTER en el sistema descendente.

• La conexión de replicación termina después de DDL en las tablas replicadas (plugin test_decoding): al utilizar el plugin test_decoding, todas las tablas de la base de datos se incluyen automáticamente en la lista de sondeos, por defecto. Si se realiza una operación DDL (como un borrado de tabla) en cualquier tabla incluida en esta lista, el servidor termina la conexión de replicación. Sin embargo, el borrado de tablas que forman parte de la lista de sondeos no está soportado con el plugin test_decoding, por lo que, si necesita esta flexibilidad, debe cambiar al plugin yboutput.

  Nota: Antes de borrar una tabla, asegúrese de que no forme parte de ninguna publicación para evitar errores de replicación o interrupciones de conexión. Del mismo modo, no borre la tabla de puntos de control de Oracle GoldenGate, ya que también generará el mismo error.

• Caducidad de la ranura de replicación debido a inactividad prolongada: las ranuras de replicación conservan determinados recursos para evitar la recolección de basura de los registros WAL (log de escritura anticipada) necesarios para la replicación. Si un espacio permanece inactivo durante un período prolongado, se marca como caducado y los recursos retenidos se liberan. Después de la caducidad, la ranura de replicación deja de ser utilizable y se debe volver a crear.

  Ventana de retención por defecto:

  • 8 horas desde la versión 2024.2.1

  • 4 horas en versiones anteriores a la versión 2024.2.1

  Este es un problema conocido como mencionado en el sitio de Yugabyte:

  https://github.com/yugabyte/yugabyte-db/issues/27766

  Acciones recomendadas para evitar la caducidad:

  • Habilite la funcionalidad de latidos para garantizar la actividad continua de WAL y evitar largos períodos de inactividad.

  • Configure las opciones autostart o autorestart para el proceso CDC para que se vuelva a conectar automáticamente al módulo CDCSDK, minimizando el tiempo de inactividad y evitando la caducidad de la ranura.

• BatchSQL no funciona correctamente cuando BatchMechanism 3 se establece con el controlador DD de progreso, que es el valor predeterminado para el proceso Replicat para Yugabyte. Por lo tanto, si necesita utilizar BatchSQL, debe configurar el valor DBOPTIONS _BatchMechanism 2 en el archivo de parámetros Replicat para una funcionalidad adecuada. Esta solución alternativa se puede aplicar al proceso de Replicat en Oracle GoldenGate 23.10 y versiones posteriores para Yugabyte.

• Tablas elegibles solo para publicación: las tablas base persistentes y las tablas particionadas se pueden incluir en una publicación. Los siguientes tipos de objetos no pueden formar parte de una publicación:

  • Tablas temporales

  • Tablas sin registrar

  • Tablas ajenas

  • Vistas materializadas

  • Vistas regulares

• Impacto de supresión de publicación en el extracto de CDC: si se suprime una publicación mientras el extracto de CDC aún se está ejecutando, existe el riesgo de que se dañe la ranura de replicación, lo que hace que deje de funcionar. En tales casos, la ranura de replicación afectada se vuelve inutilizable, y simplemente volver a crear la misma publicación no resolverá el problema. No hay solución para reanudar en el flujo existente y solo se puede crear una nueva publicación y asociarla a un nuevo espacio de replicación.

• Limitaciones con zona horaria (TZ): el proceso de remitente de WAL siempre transmite los registros de hora confirmados en UTC. Si la zona horaria de la sesión de Oracle GoldenGate difiere de UTC, se pueden producir discrepancias al posicionar por registro de hora en el proceso de extracción de CDC. Para evitar este problema, debe definir la variable de entorno TZ=UTC en la capa de despliegue. Esta limitación se aplica específicamente al plugin yboutput.

• El plugin pgoutput no está soportado para Yugabyte.

• La globalización no está soportada con el plugin yboutput

• Clave primaria en la tabla: solo están soportadas las tablas con una clave primaria para el flujo de CDC en Yugabyte. La tabla que no tiene la clave primaria no será capturada por Oracle GoldenGate CDC Extract.

• Actualizaciones de clave primaria en Yugabyte: una actualización de clave primaria en Yugabyte se registrará como DELETE, seguida de INSERT. Oracle GoldenGate Extract mostrará las estadísticas de una UPDATE de clave primaria solo como DELETE e INSERT. Aunque las estadísticas no se mostrarán como una operación de actualización en las estadísticas de Extract, no habrá ninguna discrepancia en los datos de origen y destino.

• Comportamiento de identidad de réplica: la identidad de réplica de las tablas presentes en el momento de la creación de la ranura no se puede cambiar después de crear la ranura. Sin embargo, la identidad de réplica de todas las tablas nuevas creadas después de la creación del espacio se puede definir mediante los indicadores ysql_yb_default_replica_identity, cdcsdk_publication_list_refresh_interval_secs y csdk_enable_dynamic_table_support tserver. Estos indicadores se deben definir en el maestro y en t-server antes de crear nuevas tablas.

  Por defecto, cdcsdk_publication_list_refresh_interval_secs se define en 900 segundos, que es de 15 minutos. Debe definir esto según su requisito. Si disminuye su valor, se reducirá rápidamente la tabla recién creada que se va a refrescar en el módulo CDCSDK, lo que ayudará a Oracle GoldenGate a capturar cualquier registro para estas nuevas tablas. En el siguiente ejemplo, se muestran los indicadores que se definen para las tablas creadas dinámicamente después de crear la SLOT:

  ysql_yb_default_replica_identity=FULL,cdcsdk_publication_list_refresh_interval_secs=120,cdcsdk_enable_dynamic_table_support=true

• No se admite el posicionamiento por fin de log (EOL) o fin de archivo (EOF): en lugar de EOL/EOF, puede modificar la posición de la ranura por el registro de hora actual, que filtrará los registros existentes.

• Operación Truncar: los parámetros como GETTRUNCATES/IGNORETRUNCATES no están soportados, ya que la base de datos no permite al usuario truncar la tabla si están activados para la captura de datos de cambio.

• Retención de WAL: Yugabyte normalmente depura los segmentos de WAL después de algún período de tiempo. Esto significa que Oracle GoldenGate podría perder los datos del log de WAL si los logs se truncan cuando Extract está inactivo durante más tiempo. La retención de WAL no se garantiza en Yugabyte hasta que se ajusten un par de parámetros como cdc_intent_retention_ms y cdc_wal_retention_time_secs para retener los logs WAL durante más tiempo. Se debe ajustar en todos los nodos o clusters en los que se esté ejecutando el proceso de extracción de Oracle GoldenGate.

  Los valores recomendados son los siguientes:

  cdc_wal_retention_time_secs=86400

  cdc_intent_retention_ms = 86400000

• Comando UNREGISTER EXTRACT: Oracle GoldenGate utiliza el comando UNREGISTER EXTRACT para borrar la ranura de replicación. Una ranura de replicación solo se puede borrar después de que el cliente que consume de ella se haya detenido durante al menos ysql_cdc_active_replication_slot_window_ms. El valor predeterminado del indicador es de 5 minutos, lo que significa que debe esperar la ventana de tiempo máxima para la que un espacio de replicación puede permanecer inactivo antes de que se considere obsoleto.

  En el caso de una configuración de cluster, este parámetro se debe ajustar en todos los nodos con el mismo valor.

• Limitaciones de BLOB/CLOB: el tipo de datos, como texto/imagen, tiene la limitación de capturar solo 200 MB de datos. El tamaño de fila no debe superar los 32 MB y cada columna que contiene los datos de lob debe mantenerse hasta los 2 MB.

  https://docs.yugabyte.com/stable/develop/best-practices-ysql/#row-size-limit

• Limitaciones con SAVEPOINT y rollback en operaciones DML: Oracle GoldenGate CDC Extract no soporta las operaciones de rollback SAVEPOINT. El plugin CDC test_decoding no respeta los comandos ROLLBACK TO SAVEPOINT. Como resultado, los registros que deberían haberse excluido debido a una reversión siguen siendo capturados y procesados por Extract.

  Este comportamiento es una limitación conocida del módulo SDK de Yugabyte CDC. Para obtener más información, consulte los siguientes enlaces:

  https://yugabyte.atlassian.net/browse/DB-11714

  https://docs.yugabyte.com/stable/develop/change-data-capture/using-logical-replication/#limitations

• Limitación de tabla de borrado: una vez que se crea un espacio, el usuario no debe borrar ninguna tabla de la base de datos hasta que se borre el espacio. Si el espacio está activo y el usuario intenta borrar cualquier tabla de la base de datos, el Extract de CDC no podrá capturar ningún registro de otras tablas de CDC que formen parte de la replicación. Además, se sugiere que cuando se ejecuta la extracción de CDC, el usuario tampoco debe borrar ninguna tabla en la base de datos donde se crea el espacio. Si no lo sigue, el Extract de CDC finalizará de manera anormal con el error de desconexión similar al siguiente:

  Error: The server has ended the streaming connection.

• Limitación en statement_timeout: el parámetro Yugabyte statement_timeout no se debe modificar en el nivel de usuario o de base de datos y se debe mantener en el valor por defecto. Si se define en un valor inferior, el Extract de CDC no podrá leer los registros de WAL. Si es necesario, siempre se debe definir solo en el nivel de sesión.

• No se admite la creación de ranuras en el nodo de réplica con el modo de solo lectura: la extracción de CDC no podrá capturar los registros del nodo de réplica. Esto se debe a que la versión que admitimos, como 2024.2.1.0 o 2024.2.2.0, se crean sobre PostgreSQL 11.2, que no admite la creación de la ranura en el nodo de réplica.