AYUDA EN LÍNEA
 WINDEVWEBDEV Y WINDEV MOBILE

Este contenido se ha traducido automáticamente.  Haga clic aquí  para ver la versión en inglés.
Ayuda / WLanguage / Administrar bases de datos / HFSQL / Gestión de la replicación / Replicación de servidores
  • Presentación
  • Implementación de la replicación de servidores HFSQL
  • Condición previa
  • FAQ sobre la replicación entre servidores HFSQL
  • Cuando se implementa una réplica entre servidores HFSQL, ¿por qué los identificadores de automatic están codificados en 8 bytes?
  • ¿Por qué se añaden los valores de los identificadores de automatic una vez que se implementó la replicación del servidor tan alta?
  • ¿Cuál es la configuración de red necesaria para la replicación del servidor de set?
  • Se modificó la estructura de los archivos en el análisis (adición, modificación o eliminación de elementos).. ¿Cómo aplicar las modificaciones a los archivos encontrados en los servidores HFSQL con una replicación de servidor?
  • Replicación del servidor: ¿Las transacciones se gestionan en los servidores HFSQL?
  • Replicación del servidor: ¿Qué tipo de seguridad se utiliza para la replicación del servidor?
  • Replicación del servidor : ¿Cómo se ejecutan los triggers del servidor?
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReportes y ConsultasCódigo de Usuario (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Código Navegador
WINDEV Mobile
AndroidWidget Android iPhone/iPadIOS WidgetApple WatchMac CatalystUniversal Windows 10 App
Otros
Procedimientos almacenados
Presentación
La replicación entre servidores HFSQL consiste en replicar automáticamente los datos de servidor a servidor, de forma asíncrona.. Esta replicación también puede hacerse con un servidor SPARE.
Ejemplo simple: una empresa puede tener varios servidores HFSQL en diferentes ubicaciones, un servidor en cada sucursal por ejemplo. La replicación entre servidores se utiliza para replicar los datos de cada servidor..
Se pueden implementar varios métodos de replicación:
  • los replicación lineal: Dos o más servidores son relacionado de dos en dos.
  • los replicación en estrella: Por ejemplo, la sede y los organismos utilizan servidores HFSQL. Las agencias pueden sincronizar sus datos con la sede en tiempo regular interval.
  • los replicación en estructura de árbol: Por ejemplo, una multinacional puede sincronizar sus agencias por Continent, luego por Country.
En todas estas configuraciones, la replicación está definida por un par de servidores. La replicación puede ser:
  • unidireccional o bidireccional.
    En una replicación unidireccionallos datos fluyen en una sola dirección. Las actualizaciones se realizan desde un servidor maestro a un servidor de suscriptores..
    En una replicación bidireccionalel dato se sincroniza en ambos sentidos. Las actualizaciones se realizan en cada uno de los servidores.
  • periódico o continuo.
    Se realiza una réplica periódica en un tiempo preestablecido interval: cada noche a las 20:00, ...
    Se realiza una replicación continua cada vez que se modifica la base de datos (puede existir un tiempo muerto entre la modificación inicial y la actualización realizada en los otros servidores).
Implementación de la replicación de servidores HFSQL
La replicación de servidores HFSQL puede ser implementada:
Atención: La implementación de la replicación entre varios servidores HFSQL requiere algunas adaptaciones en la aplicación (ver el siguiente párrafo).
Si no se realizan estas adaptaciones, es posible que la aplicación no funcione correctamente y que se pierdan datos.
Condición previa
La implementación de la replicación unidireccional o bidireccional entre varios servidores HFSQL requiere hacer algunos cambios en la aplicación.
Estos cambios no son necesarios en una réplica de reserva.
1. En cuanto al análisis de la aplicación
En el análisis, los ficheros de datos implicados en la replicación de los servidores HFSQL deben tener:
  • un identificador de automatic en 8 bytes. Si el identificador automatic está codificado en 4 bytes, debe ser modificado.
    Atención: Esta modificación puede provocar modificaciones en el código de la aplicación. Por ejemplo, cuando se manejan identificadores de archivos con variables enteras.
    • Busca "n is int = file.autoid" en tu aplicación para reemplazar el entero por un entero de 8 bytes.
    • Compruebe si los identificadores de su archivo se pasan a procedimientos que esperan un número entero.. En este caso, debe eliminar el tipo de la declaración de la Procedure, o utilizar un entero de 8 bytes.
  • una clave primaria (es decir, una clave única simple o compuesta que no acepta un valor nulo y cuyos componentes no aceptan un valor nulo).
2. En cuanto a la solicitud
  • no se debe utilizar HCross.
  • Un archivo no se puede copiar si se replica: no se debe utilizar HCopyFile.
    Observación: Para una replicación unidireccional:
    • el copy al servidor maestro no está permitido.
    • el copy del servidor maestro está permitido.
  • No se puede restaurar un archivo replicado: HRestoreBackup no puede utilizarse.
  • Los clusters HFSQL no deben ser usados en los datos replicados..
3. Seleccione la información a replicar: La implementación de la replicación de servidores reduce el rendimiento de los servidores HFSQL. Le aconsejamos que implemente la replicación entre servidores sólo para los archivos de datos realmente afectados por la replicación.. No dude en excluir algunos archivos de la replicación.
Atención:
  • La replicación bidireccional entre varios servidores HFSQL requiere el uso de direcciones IP fijas o "reverse-DNS".: debe encontrarse el nombre del servidor en el que se creó la réplica.
  • La comunicación del servidor HFSQL del suscriptor al servidor HFSQL maestro utilizará la IP Address que el servidor maestro utilizó para Contact el suscriptor al crear la réplica. Esta IP Address (utilizada por el servidor suscriptor para Contact el servidor maestro) se puede encontrar a través del Centro HFSQL control del servidor suscriptor en la configuración de la replicación (campo "Servidor de destino").
FAQ sobre la replicación entre servidores HFSQL

Cuando se implementa una réplica entre servidores HFSQL, ¿por qué los identificadores de automatic están codificados en 8 bytes?

Cuando la clave primaria es un identificador de automatic, el servidor debe comprobar la unicidad de los identificadores en todos los servidores que participan en la replicación.
Para ello, cada servidor de replicación utiliza un rango de valores diferentes para los identificadores automatic de los registros creados.
Para que el rango de identificadores de automatic utilizados por cada servidor sea lo suficientemente amplio, los identificadores de automatic deben estar codificados en 8 bytes.

¿Por qué se añaden los valores de los identificadores de automatic una vez que se implementó la replicación del servidor tan alta?

Cada servidor que participa en la replicación utiliza un rango diferente de identificadores automatic basados en el identificador del servidor de replicación.
El primer rango de identificadores de automatic (el que comienza en 0) no será usado por ningún servidor que participe en la replicación: esta gama de identificadores se reserva a los datos existentes al implementar la primera réplica.
Por lo tanto, tan pronto como se cree un nuevo Record en una réplica del servidor, si se asigna un identificador automatic al archivo, el valor de este identificador será un valor alto.

¿Cuál es la configuración de red necesaria para la replicación del servidor de set?

La replicación del servidor utiliza el puerto 4996 para transferir datos.
  • En una réplica bidireccional, el puerto 4996 debe estar abierto en ambos servidores (maestro y suscriptor).
  • En una réplica unidireccional o de repuesto, el puerto 4996 puede estar abierto sólo en el servidor de suscripción o de repuesto.

Se modificó la estructura de los archivos en el análisis (adición, modificación o eliminación de elementos).. ¿Cómo aplicar las modificaciones a los archivos encontrados en los servidores HFSQL con una replicación de servidor?

Todo lo que tienes que hacer es aplicar la modificación de la estructura (modificación de datos de automatic) al servidor de replicación maestro. Esta modificación de datos del automatic puede ser ejecutada:
  • desde el editor de análisis,
  • al instalar la aplicación
  • mediante programación.
Durante la siguiente sincronización de datos entre servidores, la modificación de la estructura de archivos se aplicará automáticamente a los servidores HFSQL del suscriptor.. Los procedimientos almacenados y los disparadores del servidor también se actualizarán durante esta sincronización.

Replicación del servidor: ¿Las transacciones se gestionan en los servidores HFSQL?

Cuando se modifican, añaden o eliminan registros en una transacción en un servidor HFSQL en modo de replicación, los registros se replican en los servidores suscriptores sólo cuando se valida la transacción.
Si la transacción se cancela (rollback), no se realizará ninguna replicación para los registros relevantes..
Si la transacción es validada, todas las operaciones en transacción serán transmitidas a los servidores replicados.

Replicación del servidor: ¿Qué tipo de seguridad se utiliza para la replicación del servidor?

La comunicación entre servidores es autenticada. También está encriptado.

Replicación del servidor : ¿Cómo se ejecutan los triggers del servidor?

Un servidor disparador associated con una actualización de archivos se ejecuta en el servidor HFSQL para el cual la función que activa el disparador se llama.
Todos los registros modificados se sincronizan mediante replicación del servidor.
Por lo tanto, si un disparador de servidor realiza modificaciones en los datos, estas modificaciones se aplicarán automáticamente a los servidores replicados sin tener que ejecutar los disparadores en los servidores replicados.
Versión mínima requerida
  • Versión 18
Esta página también está disponible para…
Comentarios
Haga clic en [Agregar] para publicar un comentario

Última modificación: 27/05/2022

Señalar un error o enviar una sugerencia | Ayuda local