PC SOFT

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.
  • Presentación
  • Aplicación de la réplica universal
  • Modo de funcionamiento de la réplica
  • Estructura de la base de datos
  • Etapa 1: Implementación en el sitio maestro
  • Etapa 2: Preparación de los datos del sitio del suscriptor
  • Etapa 3: Implementación en el sitio del suscriptor
  • Etapa 4: Sincronización inicial entre el sitio maestro y el sitio del suscriptor
  • Etapa 5: Sincronizaciones diarias
  • Observaciones
  • Limitaciones
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReportes y ConsultasCódigo de Usuario (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Código Navegador
WINDEV Mobile
AndroidWidget Android iPhone/iPadApple WatchUniversal Windows 10 AppWindows Mobile
Otros
Procedimientos almacenados
Presentación
El propósito de la replicación universal es mantener sincronizadas varias bases de datos. Estas bases de datos pueden tener diferentes tipos. Se puede realizar una replicación:
  • entre una base de datos HFSQL y una base de datos Oracle.
  • entre las bases de datos HFSQL Classic o HFSQL Client/Server.
  • ...
La replicación universal utiliza un modelo centralizado: todas las bases de datos están sincronizadas con una base de datos maestra. Luego, la base de datos maestra aplica las modificaciones a las otras bases de datos.
Para implementar fácilmente la replicación universal, se recomienda utilizar replicación universal asistida.
Versiones 19 y posteriores
Observación: La replicación universal está disponible para la replicación de datos móviles (Android o iOS). Para obtener más información, consulte Replicación de datos móviles (Android o iOS).
Nueva funcionalidad versión 19
Observación: La replicación universal está disponible para la replicación de datos móviles (Android o iOS). Para obtener más información, consulte Replicación de datos móviles (Android o iOS).
Observación: La replicación universal está disponible para la replicación de datos móviles (Android o iOS). Para obtener más información, consulte Replicación de datos móviles (Android o iOS).
La replicación universal utiliza varios tipos de archivos:
  • .RPM file: archivo utilizado para describir una base de datos maestra así como sus bases de datos de suscriptores. Contiene el nombre del archivo.SYN para cada suscriptor. Este archivo es un archivo de texto. Se crea y se almacena en el equipo que se utilizará para conectarse a la base de datos maestra.
  • Archivo.RPL: archivo que describe una base de datos de suscriptores. Se crea un archivo RPL para cada base de datos de suscriptores.. Este archivo se encuentra en el ordenador del abonado. Contiene el nombre del archivo.SYN del suscriptor. Este archivo es un archivo de texto. Se crea en el equipo maestro y luego se transfiere al equipo del suscriptor.
  • .RPA file: archivo de registro que contiene la información de replicación. Este archivo se intercambia entre la base de datos maestra y la base de datos de suscriptores.. Este archivo es creado por HCreateMoveableReplica, y es leído y eliminado por HSynchronizeReplica.. El contenido se incrementa: si se realizan dos HCreateMoveableReplica uno tras otro en la misma dirección, el primer archivo y el segundo archivo tendrán el mismo contenido pero el segundo archivo también contendrá las modificaciones recientes. Si un archivo.RPA se "pierde", todo lo que tienes que hacer es recrearlo: contendrá todas las modificaciones. Si se encuentran varios archivos RPA en el suscriptor, todo lo que tiene que hacer es ejecutar el último.. Este archivo está en formato binario.
  • .SYN archivo: archivo que contiene información sobre la situación de la base de datos remota. Este archivo se utiliza para optimizar el tamaño de los archivos de sincronización.. Este archivo se encuentra en el ordenador principal y en cada uno de los ordenadores de los abonados.. Este archivo está en formato binario.
Windows Mobile La replicación universal funciona sólo para los dispositivos móviles con Windows versión 2003 y posterior.
Observación: A partir de la versión 19, HFSQL es el nuevo nombre de HyperFileSQL.
Aplicación de la réplica universal

Modo de funcionamiento de la réplica

Estructura de la base de datos

La implementación de una replicación universal no requiere modificar la estructura de las bases de datos HFSQL (Classic o Client/Server).
Por el contrario, para implementar la replicación universal en bases de datos externas (Oracle, ...), se debe crear un elemento DateTime en cada archivo que se tenga en cuenta para la replicación. Este ítem deberá ser actualizado por la aplicación al modificar o añadir un registro.
Si las bases de datos utilizan zonas horarias diferentes, le recomendamos que utilice un formato universal (por ejemplo, fecha y hora GMT).
También pueden utilizarse varias funciones específicas al aplicar la replicación universal en bases de datos que no sean de HFSQL:
HRplDeclareLinkSe utiliza para indicar al motor de replicación que se ha encontrado un enlace entre dos archivos. El motor seguirá el enlace para obtener la lista de registros que deben ser replicados en el segundo archivo.
HRplManageFileDefine las opciones utilizadas para la replicación universal de un archivo.
HRplManageItemDefine las opciones utilizadas para la replicación universal de un elemento.
HRplFilterProcedureSe utiliza para especificar un procedimiento de filtro específico cuando se replica un archivo determinado.
Para obtener más información, consulte Funciones de replicación.

Etapa 1: Implementación en el sitio maestro

Este paso se utiliza para crear la base de datos principal de la aplicación. Este paso debe realizarse durante la primera ejecución del programa (o a través de un programa específico dedicado al administrador).
  1. To habilitar la replicación universal, simplemente usa HSetReplication con la constante rplicationUniversal.
    HSetReplication(rplReplicationUniversal)

    Esta función se utiliza para desactivar el modo de replicación estándar (si estaba activado) y para activar la replicación universal.
  2. Creación del directorio de inicio de datos (opcional)
    Usted tiene la capacidad de crear un directorio que recibirá los archivos de la base de datos. Este directorio será compartido en el servidor del sitio maestro para que los usuarios puedan acceder a los datos..
    // Create the data directory
    fMakeDir(gsMasterDirectory)
    // Connect to this location
    HOpenConnection(MasterConnection)
    HChangeConnection(CLIENT, MasterConnection)
  3. Creación de los ficheros de datos de la aplicación (opcional)
    Si los archivos de datos no existen, tienes la posibilidad de crear archivos de datos vacíos (HCreation). Estos datos serán tratados por los usuarios del sitio maestro.
  4. Creación de la réplica maestra
    Para declarar la base de datos maestra, todo lo que tienes que hacer es usar HCreateMasterReplica.
    HCreateMasterReplica(gsMasterDirectory)

    Esta línea de código crea el archivo MasterReplica.RPM en el disco. Entonces, todo lo que tienes que hacer es escribir los suscriptores en este archivo.

Etapa 2: Preparación de los datos del sitio del suscriptor

Este paso se utiliza para crear una segunda base de datos. Este paso se realiza en el sitio "maestro. Este paso debe realizarse a través de una opción específica de la aplicación (o a través de un programa específico dedicado al administrador).
  1. Creación de un directorio de inicio para los datos (opcional)
    Usted tiene la capacidad de crear un directorio que recibirá los archivos de la base de datos.
  2. Creación de la réplica del suscriptor
    Para crear un nuevo abonado, utilice HCreateSubscriberReplica. Esta función crea un suscriptor (archivo RPL) con el nombre especificado. Esta función también devuelve un número de abonado.
    Tan pronto como se crea, el suscriptor está listo para recibir los datos de la réplica maestra que se utilizó para inicializarla.. Esta primera sincronización se utiliza para asegurarse de que el contenido del suscriptor sea idéntico al contenido del master.
    // Create the subscriber replica
    HCreateSubscriberReplica(gsMasterDirectory, gsSubscriberDirectory, ...
    "Subscriber1", 0, "Customer" + TAB + "DATETIMEID")

    En este ejemplo, el elemento "DATETIMEID" corresponde a un elemento "DateTimeid" que debe estar disponible en la base de datos (para una base de datos que no esté en formato HFSQL Classic o Client/Server).. Este ítem deberá ser actualizado por la aplicación al modificar o añadir un registro.. Si las bases de datos utilizan zonas horarias diferentes, le recomendamos que utilice un formato universal (por ejemplo, fecha y hora GMT)..
    Este elemento no es necesario para una base de datos HFSQL Clásico o Cliente/Servidor.
    Versiones 25 y posteriores
    Observación: Un parámetro de HCreateSubscriberReplica indica si se debe tener en cuenta la modificación automática de datos. Para obtener más información, consulte Observaciones.
    Nueva funcionalidad versión 25
    Observación: Un parámetro de HCreateSubscriberReplica indica si se debe tener en cuenta la modificación automática de datos. Para obtener más información, consulte Observaciones.
    Observación: Un parámetro de HCreateSubscriberReplica indica si se debe tener en cuenta la modificación automática de datos. Para obtener más información, consulte Observaciones.
Ejemplo: Gestionar un elemento específico para la réplica entre una base de datos HFSQL Classic y una base de datos MySQL:
Se implementa una trigger para llenar automáticamente el elemento "Itm_DateTime" que se encuentra en la base de datos de MySQL:
  • Código de la trigger:
    TriggerResult is boolean
    TriggerResult = HDescribeTrigger("*", ...
    "HADD,HMODIFY,HDELETE,HCROSS,HWRITE", ...
    "AddDateTime",hTriggerBefore)
    IF TriggerResult = False THEN Error(HErrorInfo())
  • Procedimiento llamado por la trigger:
    PROCÉDURE AddDateTime()
    TestReplic.Itm_DateTime = DateSys()+TimeSys()

Etapa 3: Implementación en el sitio del suscriptor

  1. Cuando los datos se "preparan" para el sitio del suscriptor (archivos .rpl, .syn), todo lo que hay que hacer es habilitar el mecanismo de replicación en el sitio del suscriptor (HSetReplication).
    HSetReplication(rplReplicationUniversal)
  2. El sitio del suscriptor debe crear su base de datos en blanco (HCreation) antes de la primera sincronización:
    HCréation(CUSTOMER)

    Esta base de datos se inicializará durante la primera sincronización.

Etapa 4: Sincronización inicial entre el sitio maestro y el sitio del suscriptor

Este paso es necesario para que la replicación universal funcione correctamente. Mediante la sincronización inicial, la base de datos de suscriptores debe contener toda o parte de la base de datos maestra (antes de que se pueda utilizar el suscriptor).
  1. Creación de una réplica móvil:
    Se creará una réplica móvil a partir de la base de datos maestra. contendrá los datos de la base de datos a partir de la cual se creó la réplica maestra. Esta operación es realizada por HCreateMoveableReplica. HCreateMoveableReplica crea un archivo de registro (archivo .RPA).
    HCreateMoveableReplica(sMasterReplica, "Master","")
  2. Inclusión de la réplica maestra en la base de datos de suscriptores:
    Los datos que se encuentran en la base de datos principal son importados a la base de datos de suscriptores por HSynchronizeReplica.
    sMovableReplica= gsMasterDirectory +RPL.File

    HSynchronizeReplica(sMovableReplica, ...
    gsSubscriberDirectory + "Subscriber_Replica1.RPL", ...
    rplToSubscriber)
    fDelete(sMovableReplica)
  3. Se ha creado el suscriptor. Los archivos del suscriptor ahora pueden ser movidos al sitio del suscriptor. Esta operación se puede realizar a través de cualquier tipo de soporte (FTP, CD ROM,...), siendo el objetivo principal la creación de una base de datos vacía y la realización de una primera replicación en el sitio.
Atención:
  • Tan pronto como se inicialice una réplica de suscriptor, ya no debe reemplazar/restaurar uno de los archivos maestros (porque contienen información sobre los rangos de identificadores para las réplicas de suscriptor)..
  • Todos los archivos de la base de datos no necesariamente tienen que ser replicados. Replicar sólo los archivos de datos necesarios.

Etapa 5: Sincronizaciones diarias

Una vez realizada la sincronización inicial, el mecanismo de replicación está listo para funcionar en modo "Estándar".
Para sincronizar una base de datos, debe hacerlo:
  1. Generar una réplica móvil (HCreateMoveableReplica).
  2. Transmitir la réplica móvil al emplazamiento correspondiente (maestro o abonado).
  3. Sincronizar la base de datos mediante la réplica móvil a través de HSynchronizeReplica.
Estas operaciones pueden iniciarse desde el sitio "Maestro" o desde los sitios "Suscriptor".
El tipo de replicación se puede configurar para definir el modo de funcionamiento de la replicación.. Los diferentes tipos de réplicas son los siguientes:
  • rplMasterFirst: este modo de replicación es el modo por defecto. Se utiliza para proteger la base de datos del emplazamiento "maestro" de las modificaciones realizadas en el emplazamiento "abonado".. Las modificaciones realizadas en los sitios de suscriptores no se llevarán a cabo en este modo (excepto las adiciones).
  • rplSuscriptorPrimero: en este modo de replicación, los sitios suscriptores tienen prioridad sobre el sitio maestro. En este modo, el sitio maestro es una copia de los diferentes suscriptores, pero las modificaciones no se transfieren entre los diferentes suscriptores..
  • rplMásRecientePrimero: este modo se utiliza para llevar a cabo todas las modificaciones realizadas en las bases de datos. Este modo de operación debe utilizarse cuando todas las bases de datos tienen la misma prioridad (las modificaciones se trasladan a todas las bases de datos).
También tiene la capacidad de definir un procedimiento de replicación personalizado.: permite definir las prioridades utilizadas durante el mecanismo de sincronización.
Observaciones
  • Compruebe los archivos replicados. Todos los archivos de la base de datos no necesariamente tienen que ser replicados. Replicar sólo los archivos de datos necesarios.
  • Los intercambios de ficheros ".RPA" no son necesariamente simétricos: puede crear y ejecutar varios logs en una dirección sin crear y ejecutar un único log en la otra dirección. Sin embargo, para mejorar las prestaciones, debe evitar realizar intercambios siempre en la misma dirección.
  • La replicación respeta los filtros aplicados a las tablas o a los archivos (excepto los enlaces, para respetar la integridad).
  • Un filtro puede ser implementado en el lado maestro: los abonados recibirán un subconjunto de datos de la base de datos maestra. En este caso, no es necesario implementar un filtro para la base de datos de suscriptores..
    Si, debido al filtro, un registro ya no es "visible" en la base de datos maestro, este registro se considerará como eliminado. Se borrará automáticamente del ordenador del abonado.
  • HRecreateSubscriberReplica se usa para recrear una réplica de un abonado a partir de la réplica maestra.
  • Versiones 25 y posteriores
    Tengan en cuenta la modificación automática de datos (HFSQL Classic o bases de datos Cliente/Servidor):
    Al crear la réplica del suscriptor con HCreateSubscriberReplica, puede especificar si la modificación automática de datos debe realizarse durante la réplica. En este caso:
    • Los cambios en la estructura de la base de datos principal se trasladarán a la base de datos de suscriptores. Esto se hará durante la replicación.
      Atención: Esto puede aumentar significativamente el tiempo necesario para la replicación.
    • Los nuevos elementos serán tenidos en cuenta por la replicación.
    Observaciones:
    • Este mecanismo no funciona si se añade o se elimina una clave única..
    • En el caso de una réplica existente, es necesario recrear esta réplica (así como los suscriptores) para tener en cuenta esta funcionalidad.
    Nueva funcionalidad versión 25
    Tengan en cuenta la modificación automática de datos (HFSQL Classic o bases de datos Cliente/Servidor):
    Al crear la réplica del suscriptor con HCreateSubscriberReplica, puede especificar si la modificación automática de datos debe realizarse durante la réplica. En este caso:
    • Los cambios en la estructura de la base de datos principal se trasladarán a la base de datos de suscriptores. Esto se hará durante la replicación.
      Atención: Esto puede aumentar significativamente el tiempo necesario para la replicación.
    • Los nuevos elementos serán tenidos en cuenta por la replicación.
    Observaciones:
    • Este mecanismo no funciona si se añade o se elimina una clave única..
    • En el caso de una réplica existente, es necesario recrear esta réplica (así como los suscriptores) para tener en cuenta esta funcionalidad.
    Tengan en cuenta la modificación automática de datos (HFSQL Classic o bases de datos Cliente/Servidor):
    Al crear la réplica del suscriptor con HCreateSubscriberReplica, puede especificar si la modificación automática de datos debe realizarse durante la réplica. En este caso:
    • Los cambios en la estructura de la base de datos principal se trasladarán a la base de datos de suscriptores. Esto se hará durante la replicación.
      Atención: Esto puede aumentar significativamente el tiempo necesario para la replicación.
    • Los nuevos elementos serán tenidos en cuenta por la replicación.
    Observaciones:
    • Este mecanismo no funciona si se añade o se elimina una clave única..
    • En el caso de una réplica existente, es necesario recrear esta réplica (así como los suscriptores) para tener en cuenta esta funcionalidad.
Limitaciones
  • Cada archivo o tabla debe tener al menos una clave única.
  • Debe tener la capacidad de asociar una fecha con un registro. Si el ítem utilizado para asociar una fecha con el registro es llenado automáticamente por una trigger, esta trigger debe ser desactivada cuando se ejecuta HSynchronizeReplica (para evitar llenar este ítem con la fecha de replicación).
    Observación: Para las bases de datos HFSQL (Classic o Client/Server), el ítem utilizado para asociar una fecha con el registro se gestiona automáticamente.
  • La replicación no abre los archivos ni las tablas. El programa debe haber abierto los archivos o las tablas antes de iniciar la replicación.
  • Durante la replicación, el consumo de memoria puede ser muy alto. Por lo tanto, sólo los registros necesarios deben ser replicados hacia una computadora del suscriptor.
  • Atención: caso especial: algunas de las tablas de relacionado no se replican. En este caso, la replicación puede repetir algunas modificaciones como una pareja {adición, eliminación}.. Si un tabla no replicado es relacionado con modificaciones en cascada, los registros relacionado pueden borrarse erróneamente.
  • La replicación no se realizará en el siguiente caso: uno de los archivos a replicar está asegurado, protegido por una contraseña y se utiliza en un enlace con las normas de integridad.
Versión mínima requerida
  • Versión 10
Esta página también está disponible para…
Comentarios
Haga clic en [Agregar] para publicar un comentario