Documentación de Oracle Cloud Infrastructure

Mejores prácticas para conexiones de baja latencia con Autonomous Database

Tomar medidas para reducir la latencia de las conexiones entre una aplicación y Autonomous Database es fundamental si la aplicación realiza muchas idas y vueltas entre la aplicación y la base de datos.

Por ejemplo, considere una aplicación OLTP que se conecte a Autonomous Database y envíe miles de sentencias SQL a la base de datos de forma individual para ejecutar una orden de venta. En este caso, la aplicación requiere miles de viajes de ida y vuelta, y la reducción de la latencia de cada viaje de ida y vuelta puede acelerar considerablemente el proceso de órdenes de venta. Para estas aplicaciones, existen mejores prácticas que puede seguir para reducir la latencia de las conexiones de base de datos.

Tema principal: Opciones y funciones de conexión y red

Pasos para reducir la latencia de las conexiones de base de datos

Puede seguir estas recomendaciones para reducir la latencia de las conexiones entre las aplicaciones y la base de datos.

Primero, determine el dominio de disponibilidad de la base de datos. Para buscar un dominio de disponibilidad de una instancia de Autonomous Database, conéctese como ADMIN y ejecute la siguiente consulta: 

SELECT json_value(cloud_identity, '$.AVAILABILITY_DOMAIN') AVAILABILITY_DOMAIN FROM v$pdbs;

Por ejemplo:

SELECT json_value(cloud_identity, '$.AVAILABILITY_DOMAIN') AVAILABILITY_DOMAIN
             FROM v$pdbs;

AVAILABILITY_DOMAIN  
-------------------- 
SoSC:US-ASHBURN-AD-1

Para reducir la latencia, realice lo siguiente:

  1. Coloque los clientes o los servidores de nivel medio en el mismo dominio de disponibilidad que la instancia de Autonomous Database.

    Por ejemplo, si la aplicación se ejecuta en una máquina virtual de Oracle Cloud Infrastructure Compute, seleccione el mismo dominio de disponibilidad que la instancia de Autonomous Database al crear la instancia informática.

    Si la aplicación se ejecuta en otra nube o en un centro de datos local, utilice OCI FastConnect para reducir la latencia de la conexión a su región de OCI. Consulte FastConnect Visión general para obtener más información.

  2. Configure el enrutamiento de red.

    • Si utiliza una instancia de Autonomous Database en un punto final público, configure el enrutamiento de red para que la conexión del cliente a la base de datos pase por un gateway de servicio.

      Puede obtener más información en los siguientes enlaces.

    • Si utiliza una instancia de Autonomous Database en un punto final privado, se conecta a la base de datos mediante el punto final privado visible en la red, sin necesidad de configurar un gateway de servicio.

  3. Utilice conexiones TLS unidireccionales sin una cartera.

    Como mejor práctica para una latencia más baja, configure la instancia de Autonomous Database para permitir conexiones mTLS y TLS, y utilice conexiones TLS para conectar la aplicación a la base de datos.

    Puede obtener más información en los siguientes enlaces:

  4. Utilice TCP Fast Open (TFO) para conectarse a la base de datos.

Pasos para reducir la latencia de las conexiones de base de datos para bases de datos con Autonomous Data Guard

Proporciona los pasos que se deben realizar para configurar un entorno en espera de Autonomous Data Guard, clientes y niveles intermedios, para reducir la latencia de las conexiones de base de datos al conectarse después de un failover o después de un switchover (cuando la base de datos en espera se convierte en la principal).

Tema principal: Mejores prácticas para conexiones de baja latencia con Autonomous Database

Reducción de la latencia para conexiones de base de datos con Autonomous Data Guard local

Siga estos pasos para reducir la latencia de las conexiones de base de datos que realice al utilizar Autonomous Data Guard y realizar un failover o switchover a una base de datos en espera local.

Si tiene una base de datos en espera local de Autonomous Data Guard y se encuentra en una región con varios dominios de disponibilidad, Autonomous Data Guard crea la base de datos en espera local en un dominio de disponibilidad diferente. Cuando se realiza un failover o un switchover a la base de datos en espera, la base de datos en espera local se convierte en la base de datos principal. Para prepararse para un failover o un switchover, se recomienda tener clientes en espera y niveles intermedios disponibles para su activación, de modo que después de un fallo o después de un switchover, las aplicaciones puedan seguir trabajando en caso de fallo de un dominio de disponibilidad.

En primer lugar, verifique que el tipo de recuperación ante desastres para el peer local es Autonomous Data Guard. Consulte Activación de Autonomous Data Guard para obtener más información.

Realice las siguientes tareas para configurar clientes en espera y niveles intermedios para una baja latencia cuando utilice Autonomous Data Guard con una base de datos en espera local en una región con varios dominios de disponibilidad.

  1. Coloque los clientes o niveles intermedios en espera en el mismo dominio de disponibilidad que la base de datos en espera local (todos los componentes se deben configurar para utilizar el mismo dominio de disponibilidad).

    Por ejemplo, si la aplicación se ejecuta en una máquina virtual de Oracle Cloud Infrastructure Compute, al crear la instancia informática seleccione el mismo dominio de disponibilidad para la máquina virtual de Compute que la base de datos en espera. De esta forma, se prepara la configuración de recuperación ante desastres para que la base de datos en espera y la VM de Compute en espera utilicen el mismo dominio de disponibilidad después de un failover o switchover. Esto reducirá la latencia de las conexiones a la base de datos en comparación con una configuración en la que los componentes utilizan diferentes dominios de disponibilidad.

    Para determinar el dominio de disponibilidad de la base de datos en espera, conéctese a la base de datos primaria como usuario ADMIN y ejecute la siguiente consulta:

    SELECT availability_domain FROM v$pdbs,
     JSON_TABLE(
       cloud_identity,
       '$.AUTONOMOUS_DATA_GUARD[*]'
       COLUMNS (
         standby_type PATH '$.STANDBY_TYPE',
         availability_domain PATH '$.AVAILABILITY_DOMAIN'
       )
     ) jt
WHERE jt.standby_type = 'local';

    Por ejemplo, este comando muestra el dominio de disponibilidad de una base de datos en espera local:

    AVAILABILITY_DOMAIN 
------------------- 
SoSC:US-ASHBURN-AD-3
  2. No es necesario realizar ninguna configuración de red adicional ni permitir conexiones TLS unidireccionales para la base de datos en espera local. Una base de datos en espera local tiene la misma configuración de red de configuración que la base de datos primaria.
  3. Configure los clientes y los niveles medios para utilizar TCP Fast Open.

Reducción de la latencia para conexiones de base de datos con Autonomous Data Guard entre regiones

Siga estos pasos para reducir la latencia de las conexiones de base de datos que realice al utilizar Autonomous Data Guard y realizar una operación de failover o switchover a una base de datos en espera entre regiones.

Si agrega una o más bases de datos en espera de Autonomous Data Guard entre regiones, las bases de datos en espera entre regiones se agregan a las regiones que seleccione al agregar un peer entre regiones. Al realizar un failover o un switchover a una base de datos en espera de Autonomous Data Guard entre regiones, la base de datos en espera entre regiones se convierte en la base de datos principal. Para prepararse para un failover o switchover regional, se recomienda tener clientes en espera y niveles medios disponibles en la región remota. De esta forma, se preparan los clientes y el nivel medio en la región remota para que, en caso de fallo o después de un switchover, las aplicaciones puedan seguir funcionando.

En primer lugar, verifique que la recuperación ante desastres incluye al menos una base de datos en espera de Autonomous Data Guard entre regiones. Consulte Adición de una base de datos en espera entre regiones para obtener más información.

Siga estos pasos para configurar clientes y niveles intermedios para una baja latencia al utilizar Autonomous Data Guard con una o más bases de datos en espera entre regiones.

  1. Coloque los clientes o niveles intermedios en espera en el mismo dominio de disponibilidad que las bases de datos en espera entre regiones.

    Para determinar los dominios de disponibilidad de las bases de datos en espera de Autonomous Data Guard entre regiones, conéctese a la base de datos primaria como usuario ADMIN y ejecute la siguiente consulta: 

    SELECT availability_domain FROM v$pdbs,
     JSON_TABLE(
       cloud_identity,
       '$.AUTONOMOUS_DATA_GUARD[*]'
       COLUMNS (
         standby_type PATH '$.STANDBY_TYPE',
         availability_domain PATH '$.AVAILABILITY_DOMAIN'
       )
     ) jt
WHERE jt.standby_type = 'cross-region';

    Por ejemplo, cuando tiene dos bases de datos en espera entre regiones, la ejecución de este comando muestra los dominios de disponibilidad para cada base de datos en espera entre regiones:

    AVAILABILITY_DOMAIN    
---------------------- 
SoSC:PHX-AD-3          
SoSC:US-SANJOSE-1-AD-1
    1. Si tiene una base de datos en espera entre regiones, la consulta muestra un único dominio de disponibilidad. Coloque los clientes en espera y los niveles intermedios en la misma región y utilice el mismo dominio de disponibilidad que la base de datos en espera entre regiones.

      Por ejemplo, si la aplicación se ejecuta en una máquina virtual de Oracle Cloud Infrastructure Compute, al crear la instancia informática, seleccione el mismo dominio de disponibilidad para la máquina virtual de Compute que la base de datos en espera de Autonomous Data Guard. Esto garantiza que la base de datos en espera entre regiones y la VM de Compute en espera estén en la misma región y utilicen el mismo dominio de disponibilidad después de un failover o switchover.

    2. Si tiene más de una base de datos en espera entre regiones, en cada región utilice el dominio de disponibilidad adecuado que coincida con la región y el dominio de disponibilidad para cada base de datos en espera correspondiente. Tendrá que realizar esta configuración varias veces (todos los componentes de una región individual deben utilizar el mismo dominio de disponibilidad que la base de datos en espera de Autonomous Data Guard).

    Si la aplicación se ejecuta en otra nube o en un centro de datos local, utilice OCI FastConnect para reducir la latencia de la conexión a su región de OCI. Consulte FastConnect Visión general para obtener más información.

  2. Configure el enrutamiento de red en la región en la que reside la base de datos en espera. Realice este paso varias veces si tiene más de una base de datos en espera entre regiones.
    1. Si la base de datos en espera está en un punto final público, configure el enrutamiento de red para que la conexión de los clientes de la región en la que se encuentra la base de datos en espera entre regiones pase por un gateway de servicio.
    2. Si la base de datos en espera está en un punto final privado, se conecta a la base de datos mediante el punto final privado visible en la red, sin necesidad de configurar un gateway de servicio.
  3. Utilice conexiones TLS unidireccionales sin una cartera.

    Si ha configurado TLS unidireccional para la base de datos primaria, las bases de datos en espera ya tendrán configurada TLS unidireccional. No es necesario realizar ninguna configuración adicional en bases de datos en espera entre regiones.

  4. Configure los clientes y los niveles medios para utilizar TCP Fast Open.

Diagrama de red conceptual para conexiones de base de datos de baja latencia

Muestra el diagrama de red conceptual para conexiones de baja latencia que utilizan puntos finales públicos y privados para la base de datos.

Conexiones de baja latencia mediante un punto final privado con la aplicación ejecutándose dentro de la región de OCI

Descripción de adb-private-low-latency.eps

Conexiones de baja latencia mediante un punto final público con la aplicación ejecutándose dentro de la región de OCI

Descripción de adb-public-low-latency.eps a continuación

Conexiones de baja latencia mediante un punto final privado con una aplicación que se ejecuta en un centro de datos local conectado a OCI mediante FastConnect

Descripción de adb-fastconnect-private-low-latency.eps

Conexiones de baja latencia mediante un punto final privado con la aplicación ejecutándose en el centro de datos local conectado a OCI mediante FastConnect

Descripción de adb-fastconnect-public-low-latency.eps