Configuracion del componente del Servidor de Replica

El fichero “replicator.ini” contiene todas las opciones necesarias para que el servidor de réplica funcione. Aquí pondremos la explicación de las claves y un ejemplo práctico de un replicator.ini configurado.

En esta sección se almacenan las características de configuración que son globales para el server completo. Estas condiciones se evalúan cuando el servicio arranca, por lo que si se cambian con el servidor en marcha es necesario reiniciar el servicio de réplica para que los cambios surtan efecto.

Además, se podrá hacer de forma que se reevalúen cada cierto tiempo para poder cambiarlos sin necesidad de bajar el servicio de réplica. El hecho es que para que las cosas que se configuran aquí tengan efecto, es necesario cambiar cosas que es un poco complicado modificar sobre la marcha, ya se verá en la medida en que se vaya mirando.

Esta clave como su nombre indica, define el número de puerto en el cual el servidor de réplica espera los comandos.

El servidor no soporta ningún protocolo que no sea el propietario de CGSoft, así que solamente escuchará en este puerto.

Versiones que tengan su propio mini-servidor HTTP pueden venir más adelante.

El servidor mantiene una escucha sobre este puerto con una profundidad de conexiones configurables. Cada solicitud que llegue se atenderá en un subproceso independiente hasta que se alcance la cantidad de conexiones simultáneas para las cuales ha sido configurado el servidor y/o la máxima cantidad de licencias simultáneas que soporta el servicio, cualquiera de las dos que sea menor.

El comando que se solicite se coloca en una cola FIFO de la cual será extraído por alguno de los subprocesos de procesamiento de comandos que están esperando para procesar precisamente estos comandos.

Así pues, puede darse el caso de que haya comandos esperando en la cola, mientras su cliente no reciba respuesta. El hecho de que el servidor acepte una conexión no quiere decir que proceda inmediatamente a procesar el comando. Este será procesado cuando haya algún subproceso disponible para atenderlo. Esta clave no tiene valor por defecto. Si falta, el servicio no arrancará y reportará como error que no se ha definido el puerto de escucha.

Si el servidor va a estar de cara a Internet (la mayoría de los casos en que se use como servidor de réplica será así), es necesario abrir este puerto en el router para que sea accesible desde fuera.

El valor que trae esta clave en el INI que se instala con el servidor es 7757 y nosotros particularmente, recomendamos que no se cambie.

Esta clave tiene valor TRUE por defecto, para indicar que el servicio debe escuchar las solicitudes de los clientes de réplica por el puerto configurado en ListenPort (7757 por defecto).

En entornos en los que se configuran varias máquinas como servidores para atender los trabajos por separado (selectividad en una máquina en en base de datos, cola de entrada en otra y listener en otra) esta clave se debe desactivar en aquellas máquinas que no vayan a atender clientes de réplica y que solo se vayan a usar para procesar bases de datos.

Es importante tener en cuenta que para usar este tipo de configuraciones las bases de datos y las aplicaciones deben estar correctamente diseñadas para permitir el procesamiento de datos de manera adecuada, teniendo en cuenta que la interdependencia de los datos no estará garantizada si los procesamientos se efectúan en máquinas separadas.

Entero que indica cuantos subprocesos simultáneos de procesamiento de comandos estarán atendiendo la cola de comandos en espera.

No se debe confundir este término con el de cantidad máxima de conexiones, como se comentó en el apartado anterior.

El valor adecuado para este campo dependerá de la carga que se desea que soporte el servidor, la cantidad de procesadores y memoria disponibles, etc.

Por defecto la cantidad de subprocesos será 3 veces la cantidad de procesadores que tenga el servidor. No es eficiente hacer crecer indefinidamente la cantidad de subprocesos para aumentar la capacidad de procesamiento del servidor, ya que puede darse el caso en que haya más subprocesos dormidos porque no tienen tiempo para correr durante el intervalo asignado al servicio. La cantidad más eficiente será aquella en la cual haya la mayor cantidad posible de subprocesos ejecutándose simultáneamente (máximo uno por procesador) y la mínima cantidad posible parados sin hacer nada, mientras que se mantiene en espera de comandos la cantidad justa para aguantar un pico mediano sin desbordar la capacidad de procesamiento del servidor.

Si esta clave no se declara, el servicio calculará la cantidad que considere más eficiente, así que si no tiene ni idea de lo que está haciendo, yo le recomiendo encarecidamente que no declare esta clave.

Limita el número máximo de conexiones que soporta este servidor.

Nunca se puede hacer crecer la cantidad de conexiones por encima de la cantidad máxima de licencias que soporta el servidor, pero sí puede darse el caso de un servidor que soporte poca carga y sea eficiente bajarle la cantidad de conexiones y la profundidad de escucha, de forma que no consuma recursos innecesariamente esperando comandos que no van a llegar. En estos casos también suele ser buena idea variar el valor de la clave.

WorkerThreads.

Activa el Log del Servidor de Réplica para la parte servidora.

La réplica puede estar funcionando para varias bases de datos, y aquí se monitorizan todas y cada una de las conexiones de los clientes que se conectan, dando igual a que base de datos apunta la llamada.

Sus valores van desde 0(desactivado) hasta 6(máximo log que nos dirá todas y cada una de las operaciones realizadas).

El Log se guarda en la carpeta de Log del propio sistema operativo, que es %SYSTEM32%\LogFiles\CgsoftRpl

En esta sección se definen las licencias o bases de datos que este servidor va a atender.

El nombre de cada una de las claves que se insertan en esta sección constituye el número de licencia de la base de datos (8 caracteres alfanuméricos) y su valor es el antiguo DBID que se colocaría en el get_status. El número que se asigna a cada licencia será el que se use para referirse a esa base de datos para leer su configuración.

12345678=X; Base de datos de gestión.

La Base de datos con el número de licencia 12345678 y a la que se ha asignado el DBID X (el número de DBID puede ser cualquiera siempre que no se repita en el mismo servidor).

En este caso en Windows debe ir un fichero llamado 12345678.000.

Si acaba de instalar un servidor y no sabe qué licencias vienen con él, la mejor idea es buscar en la carpeta de Windows los archivos con extensión .000 y obtener sus nombres (cadenas de 8 caracteres) que representarán los números de licencia.

Cada una de las bases de datos que se definen en la sección [licenses] tiene que tener una sección con parámetros de configuración propia, ya que un mismo servidor puede atender varias bases de datos que no tienen por qué tener los mismos parámetros (DBMS, localización, etc.)

El nombre de la sección tendrá la forma [dbid-xx] donde xx será el número que se le haya asignado a la licencia de la base de datos en la definición de la licencia.

Si alguna base de datos definida en [licenses] no tiene su correspondiente sección [dbid-x] el servidor no será capaz de inicializar la base de datos adecuadamente, por lo que no se podrá vincular a ningún servicio (atención de clientes, réplica selectiva, etc.).

La vieja cadena de conexión de toda la vida.

Puede ser ODBC, OLEDB etc…

Esta cadena será usada directamente para abrir la base de datos cuando sea necesario usarla. El servidor no abrirá nunca una conexión ni creará las estructuras en memoria hasta que no se reciba una solicitud o la necesite él mismo internamente (i.e. cuando vaya a procesar clientes selectivos o arrancar el monitor para las colas de entrada).

Esta clave es obligatoria y si falta, la base de datos no podrá utilizarse. La cadena de conexión ODBC tiene que estar completa, o sea, algo como ConnString=mi_dsn no es válido, ya que el servidor no sabe si es una cadena ODBC u OLEDB.

En este caso, si se trata de una fuente de datos ODBC, debería ser ConnString=DSN=mi_dsn.

Indica al servidor en que formato espera el DBMS que deben ir formateadas las fechas en las sentencias que se van a ejecutar en el servidor.

El formato puede ser:

• dmy
• mdy
• ymd

Las fechas de las operaciones que están en la tabla master_replica_queue TIENEN que estar en este formato EXCEPTO aquellas que hayan sido insertadas directamente por los clientes que inyectan operaciones directamente (interfaces y terminales que trabajan directamente contra la base de datos del servidor)

Para indicarle al servidor en qué formato están las fechas de los clientes que escriben directamente en la cola (en caso de que lo hagan con un formato diferente) se usa el campo ULDATE para cada uno de ellos. En la sección correspondiente se explica cómo se hace esto.

La necesidad de claves diferentes para cada uno de los clientes se debe a que el formato de fecha no necesariamente está vinculado al DBMS, como pasa, por ejemplo, con MySQL, sino que puede ser un parámetro del USUARIO empleado para crear la conexión, como pasa, por ejemplo, con SQL Server. En este último puede tenerse una base de datos cuyo formato de fecha por defecto esté en inglés, y que los usuarios empleados para crear las conexiones utilicen un formato diferente. En este caso el valor que tiene que tener el DateMask debe ser el empleado por el servicio para acceder a la base de datos, es decir, el que emplea el usuario que está en la cadena de conexión configurada en la base de datos.

Ejemplo:

Tenemos una base de datos SQL Server que está en inglés y nos han configurado un usuario “replica” cuyo formato de fecha está también en inglés. Por tanto configuramos el servidor:

ConnString=xxxxxx;user=replica;xxxxxx
DateMask=mdy

Ahora supongamos que creamos un usuario de interface que necesita trabajar con las fechas en español porque la base de datos externa usa este formato y no queremos equivocarnos trabajando con dos formatos de fecha diferentes. Configuramos el MID de la interface de la siguiente manera:

MID=9999 (ejemplo)
ULDATE=dmy
DLDATE no importa
RPDATE no importa

Con esto le estamos diciendo al servicio que aquellas operaciones que hay en la cola cuyo MID sea cualquiera de los definidos como clientes de réplica tendrán sus fechas en formato “mdy” (DateMask). El servidor se encarga de arreglar las fechas que vengan en formato diferente. Aquellas operaciones que tengan su MID con valor 9999 tendrán la fecha en formato “dmy” y por tanto deberán arreglarse adecuadamente a la hora de trabajar con ellas.

Por defecto, las bases de datos se asumen del tipo configurable, el DBMS que se va a utilizar, para decir el tipo de base de datos de réplica.

DbmsName=dbms.oracle.xml
DbmsName=dbms.oracle8.xml
DbmsName=dbms.sqlserver.2005.xml
DbmsName= dbms.sqlserver.7.2000.xml
DbmsName= dbms.mysql.50.xml
DbmsName= dbms.mysql.41.xml
DbmsName= dbms.mysql.40.xml


Los archivos XML de configuración contienen valores para los nombres de determinados campos, los formatos de fecha por defecto, las cadenas de inicialización, etc. Opcionalmente, pueden contener también plantillas de inserción en cola y demás, por lo que un desarrollador puede crearse ficheros de configuración de DBMS propios si lo desea.

Para el que el servidor reconozca un archivo de configuración como válido, este debe estar en la misma carpeta en que se instala el servicio.

Esta clave por defecto es 0, indicando que las operaciones para esta base de datos no se llevarán a un archivo de registro.

Cuando esta clave tiene un valor entre 1 a 7, se le indica al servidor que las operaciones que se efectúen en base de datos se deben registrar.

Normalmente, estas operaciones se registran en la carpeta %SYSTEM32%\LogFiles\CgsoftRpl en ficheros. El registro de operaciones genera bastante información, así que lo mejor es usar este mecanismo solamente cuando algo vaya mal y apagarlo tan pronto como se haya resuelto el problema.

Los logs de un servidor con unos pocos clientes pueden crecer muchísimo en cuestión de minutos.

Esta clave permite cambiar la ruta en la cual el servidor almacena los logs para esta base de datos.

El uso de esta variable permite que si se van a generar logs de más de una base de datos a la vez, se puedan tener separados en carpetas diferentes, de forma que no se mezclen los logs de operaciones de bases de datos diferentes.

Esta clave permite cambiar el tamaño de la unidad de trabajo para el análisis de selectividad y para la atención de la cola de entrada en la base de datos.

En la sección correspondiente al análisis de registros de réplica selectiva se explica que cada unidad de trabajo tiene un registro inicial y un número de registros.

El número máximo de registros que puede llegar a tener una unidad de análisis se puede cambiar aquí para hacer que las unidades sean más grandes y por tanto los subprocesos de análisis estén más tiempo trabajando con el mismo MID.

El valor que se le da a esta clave dependerá de la estrategia de selectividad que requiera la base de datos, a saber:

• Poca concurrencia con mucha carga.
• Mucha concurrencia con poca carga.

Si una base de datos sufre mucho con operaciones que manejan muchos datos pero responde muy rápido con pocos datos y puede manejar muchos procesos simultáneos, lo más eficiente es poner el valor de SelUnitLen bajo y no limitar la concurrencia.

Si por el contrario, la base de datos sufre con muchas operaciones concurrentes, pero tolera bien las operaciones con mucha carga, lo más eficiente es limitar la cantidad de procesos concurrentes y poner esta clave con un valor más alto.

Cuando se tienen servidores de bases de datos que trabajan bien tanto con alta concurrencia como con mucha carga, es bueno dejar esta clave con un valor entre 500 y 1.000 y no limitar la concurrencia de procesos, con lo que se logra que la selectividad avance de manera más pareja.

Por defecto la cantidad de registros por unidad de análisis es 100.

Esta clave por defecto tiene valor true para indicar que las operaciones de la cola secundaria se deben ir borrando a medida que se van procesando.

Si el administrador desea que la cola secundaria mantenga las operaciones en la medida que las procesa, esta clave debe tomar valor false.

En caso de que la cola secundaria tenga campo SENT, se marcará el campo cada vez que se envíe una operación hacia el cliente para que sea más fácil analizar los registros de la cola secundaria.

Es importante que esta función se utilice solamente para funciones de depuración de errores, ya que no tiene sentido dejar datos en la cola secundaria.

Esta clave permite que el análisis de selectividad sea más eficiente una vez que se duerme el sub-proceso principal de la base de datos.

Para que el sub-proceso se despierte, es necesario que se hayan recibido al menos una cantidad mínima de registros, ya que en caso de que la base de datos tenga muchos clientes y lleguen muchas operaciones simultáneas es poco eficiente preparar pequeñas unidades de selectividad de menos registros que el SelUnitLen.

Esto ocurriría si el sub-proceso de análisis despierta con la primera operación que llegue. En este caso, como para cada cliente habrá solo uno o dos registros, se crearán pequeñas unidades de uno o dos registros, lo cual hará que cada sub-proceso de análisis trabaje durante muy poco tiempo con cada cliente, provocando muchos accesos a la base de datos para procesar muy pocas operaciones.

Si en vez de esto, el sub-proceso de análisis esperara por una cantidad mayor de registros (15 ó 20) las unidades que se formarían serían como mínimo de esta cantidad de registros, logrando una mayor latencia de los sub-procesos de análisis, y por tanto un mejor uso de los recursos del procesador.

En servidores con pocos clientes no hay un gran problema al respecto, al fin y al cabo hay más sub-procesos de análisis que clientes, por lo que todos los sub-procesos se ejecutarán de forma concurrente mientras haya sub-procesos disponibles.

Aquí el problema empieza cuando se trata de muchos clientes en juego. En servidores que tienen muchos clientes pero poca frecuencia de llegada de operaciones, es eficiente dejar el valor por defecto (1).

En servidores con muchos clientes y muchas operaciones llegando simultáneamente, lo mejor es que este número se haga mayor (aproximadamente la mitad de SelUnitLen).

De todas maneras, si desconoce lo que está haciendo, simplemente no declare esta clave y deje que el servidor calcule el número más adecuado para el.

Uno de los trabajos que tiene que hacer una base de datos replicada es aceptar y crear nuevos clientes.

Estos clientes normalmente tienen características diferentes en lo que a DBMS se refiere, ya que un sistema distribuido suele estar compuesto por varios componentes de bases de datos distintas.

Por tanto, es importante que mediante los propios comandos de registro de clientes se puedan inicializar los campos de formato de fecha en el momento de crear el cliente o mientras se revalida su licencia.

Los valores por defecto que tienen los campos se deciden en el momento que se crea la base de datos, y serán generalmente los valores que menos cambios requieran.

Esta clave define el formato de fecha que tendrán los clientes cuando escriban directamente en la base de datos (ver campo ULDATE de la tabla master_replica_slave), cuando se crea un cliente por defecto.
Al recibirse un comando para crear un nuevo cliente, este valor será el que se devuelva como parámetro “uld”.

Normalmente el cliente decidirá si quiere respetar este valor o cambiarlo por otro diferente. El valor especial “none” significa que se deje este campo vacío cuando se escriba el cliente en la base de datos. Si se está configurando un servidor de réplica que va a funcionar solamente como agente, este valor no es necesario configurarlo.

Este valor es similar a la Clave DefaultULD con la diferencia que opera sobre el campo DLDATE de la tabla master_replica_slave al crearse el nuevo cliente.

Una vez más el usuario es el que decide el valor final.

La clave “none” significa que se dejará a nulo este valor.

De igual forma, si el servidor es solamente un agente de réplica, no es necesario preocuparse con esta clave.

Este valor es similar a la Clave DefaultULD con la diferencia que opera sobre el campo RPDATE de la tabla master_replica_slave al crearse el nuevo cliente.

Una vez más el usuario es el que decide el valor final.

La clave “none” significa que se dejará a nulo este valor. La misma observación referente al servidor como agente.

Cuando se inicializa una base de datos, el servidor prueba que los campos y tablas a los que se refiere la tabla de relaciones (RL) contengan combinaciones correctas, así como que no haya registros con campos clave vacíos.

En algunos servidores con mucha carga de trabajo, este proceso puede fallar aunque la tabla RL esté correcta, ya que las consultas que se lanzan para este propósito pueden ser complicadas.

Si el administrador está seguro que la tabla RL es correcta (la ha comprobado usando la herramienta XnetSetup2 de CGSoft) puede asignar un valor false a esta clave para evitar que el servidor compruebe la tabla RL de la base de datos cada vez que la inicializa.

Esto también puede acelerar considerablemente el inicio del servicio cuando se trata de bases de datos que tienen réplica selectiva y/o cola de entrada.

Aunque esta clave sea false, el servidor seguirá comprobando la presencia de campos vacíos en los registros de la tabla RL, ya que para esto no hacen falta operaciones de consulta, y pueden provocar que fallen las operaciones de traducción de registros con relaciones.

Este comportamiento no se puede desactivar.

Esta clave tiene por defecto un valor false, para indicar que el proceso de réplica selectiva que se efectúa con los registros de la cola es normal.

Dicho proceso considera que las operaciones de inserción y actualización tienen que pasar por el filtro de selección, pero que las operaciones de borrado siempre se replican.

Esto se debe a que una base de datos en la cual se ha dejado de cumplir una regla de selectividad no puede saberlo una vez que la operación está en cola, ya que en realidad el registro no existe y no hay manera de comprobar si la operación hay que replicarla o no.

Por tanto, todas las operaciones de borrado se replican. Al asignarle valor true a esta clave, se le está diciendo al proceso de selección que utilice el filtro de selectividad de una manera más agresiva, es decir, si una tabla no aparece en el filtro, sus operaciones de borrado no se replicarán.

Si aparece con la marca ALWAYS=1 al menos una vez, las operaciones se replicarán. Si aparece con condiciones de borrado, se tratará de armar un registro “virtual” con las operaciones que haya en cola a partir del INSERT hasta el momento.

Si esto no se puede hacer, la operación se replicará, si los valores que haya al final de la creación del registro no cumplen el criterio de selectividad, tampoco se replicará la operación.

Esto implica riesgos en las bases de datos en que las reglas de selectividad varían, ya que se podrían dejar de replicar operaciones de borrado si han cambiado las reglas de selección.

Si las reglas para la selectividad no van a variar esta opción puede hacer que el tráfico entre el servidor y los dispositivos móviles con réplica selectiva se reduzca considerablemente.

Este campo se utiliza cuando la base de datos tiene activado el mecanismo de réplica por lotes.

Para ello, se necesita definir las tablas y campos necesarios para que esto sea posible, y el cliente tiene que aceptar operaciones en lotes. El número por defecto para los lotes de registros en caso de no definirse en la tabla de clientes (master_replica_slave) para cada uno de ellos se puede colocar aquí de manera global para toda la base de datos.

Si a un cliente no se le define la cantidad de registros por lote y no se define esta clave, dicho cliente nunca replicará por lotes, aunque el servicio cliente de réplica lo acepte.

Esta clave permite cambiar el nombre del campo ROWID en la base de datos del servidor.

El tráfico de operaciones entre el servidor y los clientes siempre se efectuará normalizado, es decir, el nombre del campo ROWID siempre será ROWID.

Sin embargo, una vez que el registro llega al servidor, se modificará para usar el nombre de campo que se indique en esta clave. Esto se utiliza para aquellos casos en los que el DBMS considera que la palabra ROWID está reservada y no se pueden crear campos de base de datos con este nombre.

Para esos casos, renombre todos los campos ROWID de la base de datos de la manera que estime convenientes (i.e. MYROWID) y coloque el nuevo nombre en esta clave.

A partir de este momento todas las operaciones que se almacenen en el servidor utilizarán el nuevo nombre y se almacenarán en la cola con el nombre cambiado.

Para enviar las operaciones a los clientes, el servidor volverá a cambiar el nombre del campo y le pondrá nuevamente ROWID, por lo que el cliente puede mantener su nombre de campo ROWID inalterado. Si la base de datos del cliente también tuviera el nombre cambiado, es necesario configurar el cliente de réplica y la maquinaria de la aplicación para que usen el nombre alternativo.

El nombre del campo ROWID también se puede cambiar mediante el fichero de DBMS configurado en DbmsName. La prioridad es la siguiente:

1. Si se define esta clave, este es el valor que se usa.
2. Si no se define esta clave y se indica un DbmsName cuyo fichero define el nombre del campo ROWID, ese es el que se usa.
3. Si no se define la clave, ni el Dbms (o este no redefine el campo ROWID) se considera que el campo se llama ROWID.

Esta clave funciona de manera idéntica a RowIDFieldName pero para redefinir el nombre del campo “SQL” en las tablas de réplica.

En algunos DBMS la palabra “SQL” está reservada y no se puede usar como nombre de campo, por lo que hay que redefinirla. La diferencia es que este campo solamente se usa en las tablas de réplica y no es necesario en las de datos.

La forma de operar de esta clave, así como las prioridades para su definición son iguales que en RowIDFieldName.

Normalmente el servidor bloquea las claves únicas de registro (ROWID) cuando va a efectuar una operación con alguna de ellas.

Esto permite que en un sistema con muchos clientes que estén trabajando con las mismas tablas no entren en las colas operaciones que puedan provocar conflictos y que se excluyan de los procesos de análisis al estar ya estos en proceso.

La idea es que cuando se inicie un proceso de análisis de conflictos se bloquee su ROWID, de manera que al menos en lo que respecta a este, el estado del servidor se mantenga hasta que se termine el análisis.

Una vez que se termine el proceso, se liberará el ROWID y los procesos que esperen podrán seguir. Si los procesos simultáneos trabajan con otros registros, el bloqueo de ROWID no los afectará.

Esta clave se puede poner a false para acelerar el trabajo del servidor, y es seguro su uso SOLAMENTE cuando se trata de sistemas en los que la localidad de los datos está perfectamente definida (sistemas con pocos conflictos) ya que no hay operaciones sobre el mismo registro en clientes diferentes, o bien en aquellos sistemas en los que cada cliente replica a horas en los que los otros no lo están haciendo.

Utilice esta clave si el servidor va a trabajar como receptor de operaciones de una interface de enlace con otros sistemas.

Normalmente, las interfaces se configuran mediante una base de datos intermedia que después se replica contra el servidor usando un cliente de réplica.

Una manera de optimizar este mecanismo es haciendo que la interface escriba directamente en la base de datos del servidor, pero para ello, es necesario que las operaciones que lleguen de los clientes marquen los campos de modificación en las tablas de datos.

Especialmente delicado es el borrado de registros, que en lugar de borrar físicamente debe marcar el campo de modificación con un valor que indique que el registro debe borrarse.

La interface se encargará de efectuar el borrado físico cuando envíe los datos hacia el otro sistema.

El nombre del campo de marca también es configurable.

El valor de este campo solo tiene sentido si se ha activado el modo interface, de lo contrario se ignora.

Por defecto su valor es “ACTUALIZADO” y tiene que existir en todas las tablas de la base de datos, ya que el servidor lo marcará con cada operación que efectúe.

Esta clave normalmente tiene valor “false” por defecto, lo cual significa que aquellos clientes que usan réplica selectiva emplearán la cola secundaria para seleccionar los registros que sí se replican.

Cuando la base de datos se pone en cola de monitoreo y esta clave tiene valor “true”, el servidor no procesará los registros de la cola para llenar la cola secundaria, sino que comprobará las condiciones de selectividad cuando los clientes hagan las solicitudes de registros o lotes.

Esta es una opción interesante para los sistemas con una gran cantidad de clientes, ya que de esta forma se libera el servidor de los procesos de análisis y modificación de la cola secundaria.

Si además se trata de réplica simple, los clientes que operen en entornos de gran concurrencia no se verán muy afectados por el uso de esta facilidad y al mismo tiempo se logrará que el servidor trabaje más desahogado.

Cuando los clientes operan por bloques en la bajada y se usa esta clave, es necesario emplear tamaños de bloques más pequeños para los clientes selectivos, ya que las respuestas a las solicitudes de bloques deberán comprobar la selectividad de cada uno de los registros que se incluirán en el lote.

Esta clave se usa para que no se pare la réplica si llega un UPDATE a un registro que no existe en el Servidor.
Normalmente, el servidor no permite que se ejecuten actualizaciones sobre registros que no tiene, ya que esto implicaría que hay un error de coherencia en alguna de las copias. Por tanto, el valor de esta clave es TRUE por defecto, y en general no debería tocarse.

Sin embargo, hay casos en los que se efectúan procesos de limpieza en determinadas tablas de la base de datos del servidor (i.e. los procesos de integración o mediante mantenimientos programados) por diseño de la propia aplicación. En estos casos es normal que falten registros en el servidor, ya que una vez que se integran en el sistema principal o backend ya no se necesitan en la réplica.

Si un cliente envía modificaciones posteriores a esta integración, dichas modificaciones en realidad no son importantes ni necesarias, por lo que se pueden obviar sin que causen problemas. En estos casos para que la réplica no se detenga al faltar los registros, se puede poner esta clave a FALSE para indicarle al servidor que simplemente se salte estas operaciones que afectan registros que no existen. El servidor dejará una traza en la tabla master_replica_errorlog indicando la tabla y el ROWID que han fallado y continuará ejecutando las operaciones que le siguen.

Es trabajo del administrador del servidor verificar que en efecto los registros que han ido fallando correspondan a tablas que se han vaciado por mantenimiento y no por problemas de coherencia.

Clave que indica si el replicador tiene que ir revisando el queue para ver si el campo TBL está relleno o no.

Solo hay que usarlo cuando el replicador convive con otros componentes de XOne, dlls o frameworks antiguos que no rellenan el campo TBL, por lo que si es un sistema nuevo debemos ponerlo a false para ganar en rendimiento.

Si la replica tiene que buscar un histórico, y esto esta true, solo lo busca en la tabla. Si esta a false, entonces buscar el histórico tambien en el queue.

El valor de esta clave es 0 por defecto. En caso de que se especifique un nivel superior, el servidor dejará en un fichero llamado IQUEUE.LOG.TXT todas las operaciones que lleguen antes de insertarlas en la cola de entrada. Esto puede ser útil durante la puesta en marcha de un sistema para verificar que las operaciones que llegan de cada cliente se estén recibiendo correctamente, ya que en el servidor una vez que se van procesando, se eliminan del iqueue.

Cuando por algún error de desarrollo o configuración de la aplicación durante la puesta en marcha se pierden operaciones, este mecanismo puede ayudar a determinar si se trata de operaciones que no han llegado nunca al servidor o si se están perdiendo por alguna causa (i.e. algún error en la base de datos)

Una vez puesto en marcha el sistema esta clave se debe desactivar, ya que penaliza la recepción de operaciones. Basta con eliminarla del fichero de configuración, ya que por defecto está desactivada.

Niveles posibles:

1: Registra entradas en el iqueue y errores.
2: Reporta duplicados (operaciones que se mandan más de una vez, tanto si está en iqueue como en main queue) también deja registro de que la inserción en iqueue fue correcta.

Por defecto esta clave tiene valor TRUE para indicar que si la base de datos se monitorea, se considera que hay que analizar la selecividad de los clientes condicionales. Si un proyecto no lleva selectividad, o esta se va a analizar mediante otro proceso (i.e. un procedimiento almacenado en el servidor de base de datos, otro servidor de réplica que solamente se dedique a la selectividad, etc.) entonces se debe dar valor FALSE a esta clave para indicarle al servicio que NO analice la selectividad de esta base de datos.

El servidor continuará monitorizando la cola de entrada, actualizando el campo TBL y esperando conexiones de los clientes de réplica, pero no arrancará los procesos de selectividad.

Esta clave tiene valor FALSE por defecto (comportamiento normal)

Los clientes de réplica envían como parte de su proceso de conexión el número de serie o IMEI del terminal. Si el servidor detecta que la base de datos tiene las tablas de administración (tablas adm_*) se buscará en dichas tablas si existe el terminal y está vinculado a esta base de datos. En caso de que el terminal no esté en las tablas adm, o que no esté vinculado a la base de datos, se rechazará el logon. Si la base de datos no tiene las tablas adm_ el servidor ignorará el dato de IMEI del terminal.

Si la clave se configura con valor TRUE, es obligatorio que la base de datos tenga las tablas adm_ y TAMBIÉN es obligatorio que los terminales manden el IMEI. Por tanto, para que un cliente pueda conectarse a la réplica debe cumplirse que:

• La base de datos del servidor tenga las tablasa adm_
• El terminal esté dado de alta en las tablase adm_
• El terminal esté vinculado al cliente de réplica en las tablas adm_
• El terminal envíe su IMEI
• El IMEI coincida con el que está en las tablas adm_

Si falla alguna de estas condiciones, el servidor responderá con un código 201 (licencia no válida) indicando que este cliente no puede replicar contra esta base de datos. Este sistema es útil en entornos de desarrollo en los que se tiene el mismo terminal dado de alta en bases de datos diferentes para evitar réplicas cruzadas accidentales y en entornos de producción para dificultar más la conexión de terminales no controlados por la administración.

Por defecto,esta clave no está definida, para indicar que la cantidad máxima de unidades de selectividad que se procesan de manera concurrente no tiene límite. En la práctica, sin embargo, hay muchos casos en los que esta configuración provoca un exceso de concurrencia en el servidor de bases de datos, especialmente teniendo en cuenta que las operaciones de selectividad son muy costosas.

En determinados servidores como MySql usando tablas MyISAM, las operaciones de inserción de la selecitividad bloquean las tablas completas, por lo que la concurrencia implica que la mayor parte de los procesos de selectividad se encuentran esperando que terminen las operaciones de selectividad, causando cuellos de botella, ya que no se pueden emplear para replicar ni para atender colas de entrada, etc.

Para solucionar esto sin tener que cambiar la arquitectura de los servidores de bases de datos ni mejorar el hardware de los mismos, la idea es cambiar de estrategia y en vez de usar muchos procesos concurrentes con poco trabajo (SelUnitLen bajo) usar pocos procesos concurrentes con mucho trabajo, (SelUnitLen alto) ya que para el servidor de bases de datos suele ser igual de costoso bloquear la tabla entera para insertar 1.000 operaciones que para insertar 10000. Así pues la idea es darle un valor pequeño a esta clave y uno alto a SelUnitLen, tal como se indica en el ejemplo que sigue.

Ejemplo:

Supongamos que tenemos un servidor de bases de datos con problemas de concurrencia, que cuenta con 4 procesadores lógicos (la cantidad de procesadores del servidor de réplica no es importante para este cálculo) Podemos configurar la selectividad de la siguiente forma:

SelUnitLen=10000
MaxConcurrentSelectiveUnits=6
Es recomendable configurar la cantidad máxima de unidades concurrentes entre n y 2n siendo n la cantidad de procesadores (o núcleos, o unidades de ejecución en su caso).
En los servidores que se configuran de esta manera es necesario subir la cantidad de registros de la unidad de selectividad para compensar el trabajo en base de datos.

Esta clave es opcional, y solamente tiene sentido si está configurado el PUSH para la base de datos (existen los campos correspondientes en las tablas de clientes).

El valor de la clave indica la cantidad de tiempo (en segundos) que esperará el servidor antes de enviarle una notificación PUSH a un cliente cuando haya una cantidad de operaciones suficientes para notificarle.

El valor no puede ser menor que 60 (un minuto) En caso de indicarse un valor menor, el servidor asumirá un minuto. El valor por defecto es de 5 minutos (300 segundos)

Esta clave es opcional, y solamente tiene sentido si está habilitado el PUSH para la base de datos.

El valor de la clave es un número que indica cuántas operaciones tiene que haber disponibles para el dispositivo para que el servidor considere necesario enviarle una notificación.

El valor por defecto es 10. Si la cantidad de operaciones disponibles para bajarse, bien sea en el squeue, en la cola directamente si no hay selectividad o DMIDs para el dispositivo es mayor que este número y ha pasado un tiempo mayor que el configurado para el envío de notificaciones (PushTimeout), el servidor enviará una notificación al cliente.

Opcional. El valor por defecto es “false”. Esta clave permite que el conector de PUSH para Apple comunique a través del sitio de desarrollo en lugar de hacerlo desde el de producción. Esto permite probar las aplicaciones en un entorno controlado antes de sacarlas a producción. Tan pronto como el servidor entre en producción y se instale el certificado para esta fase de proyecto, quitando esta clave se consigue que el servidor envíe las notificaciones a través del portal de producción de Apple.

Esta clave permite cambiar el puerto de notificaciones a través del cual se envían los mensajes al servidor PUSH de Apple. El valor por defecto es 2195. Esta clave no debería tener que cambiarse, así que casi mejor ni tocarla.

Esta clave permite indicarle al servicio el nombre del certificado que se usará para establecer las conexiones TLS con el servidor PUSH. Se pueden usar los campos siguientes para identificar el certificado:

1. Asunto del certificado.
2. Número de serie del certificado.
3. Nombre descriptivo (Friendly Name) del certificado.

Cualquiera de estos campos que contenga la cadena indicada en esta clave y que esté en vigor será usado para autentificar las conexiones PUSH.

El certificado tiene que estar instalado en el almacén LocalMachine/MY del equipo en que está ejecutándose el servicio de réplica. De lo contrario el servidor no será capaz de utilizarlo.

Para entornos de desarrollo o para sistemas en los que no se quiera o no se pueda instalar el certificado en los almacenes del sistema operativo, se puede cargar el certificado (.P12, .PFX) desde un fichero en el sistema de archivos de la máquina. En este caso, dejar vacía la clave que indica el nombre del certificado (o no ponerla) y definir esta clave con la ruta completa del fichero dentro del cual se encuentra el certificado.

Lo más normal cuando se colocan los certificados en ficheros es protegerlos con una clave, la cual debe definirse en la clave AppleCertPwd.

Si se usa un fichero para almacenar el certificado de PUSH para Apple, se configura aquí la clave del certificado. Para utilizar el almacén de máquina esta clave no es necesaria.

Para los dispositivos que usan PUSH de Android esta clave se usa para definir la clave asignada por Google para esta aplicación. Las claves hay que solicitarlas para cada aplicación desarrollada con soporte de PUSH.

Para configurar el PUSH en los dispositivos con Android es necesario que el servidor posea dos credenciales (la clave de acceso y el SenderId) En esta clave se define el segundo de estos parámetros. Cada base de datos de réplica representa una aplicación, por lo que se debe dar de alta en Google Cloud a cada una de ellas por separado, obtener las credenciales y configurarlas en el .INI.

Para configurar el PUSH de Blackberry es necesario configurar la dirección URL del servidor que se encargará de distribuir los mensajes. Este URL cambia para las configuraciones con BIS y las que tienen BES. En cualquiera de los casos será necesario que el cliente configure sus terminales para recibir PUSH bien sea en los servidores de Blackberry o bien en su propio BES.

Puerto para usar en los envíos de notificaciones PUSH a los terminales. El valor por defecto debería ser válido, pero cada servicio debería tener el suyo propio. Una vez dada de alta la aplicación se tendrá el puerto usado para las notificaciones y se debe configurar en esta clave.

En esta sección se configuran aquellas bases de datos que llevan réplica selectiva y/o cola de entrada de operaciones y que por tanto requieren que el servidor cree para ellas un subproceso de monitoreo. Este subproceso será el que se encargue de analizar los registros de los clientes para crear las unidades de trabajo necesarias que serán procesadas por los subprocesos de selectividad y atención a la cola de entrada. Dentro de esta sección se debe declarar una clave para cada una de las bases de datos que se vayan a monitorear.

Cada clave puede tener el nombre que desee el administrador (mientras no se repitan, claro está) y como valor tendrá el número de licencia (usado como clave dentro de la Sección [licenses]) de forma que a través de esta clave el servidor localice la base de datos en memoria y la inicialice para buscar aquellos clientes que sean selectivos.

En caso de que una base de datos no tenga clientes selectivos ni cola de entrada, el subproceso de análisis para ella se terminará, lo cual ocurrirá también si la base de datos no tiene las tablas necesarias para el soporte de la réplica selectiva o cola de entrada. Es importante que las bases de datos que se definan en esta sección estén definidas en la sección de licencias, o de lo contrario los subprocesos de monitoreo para esas bases de datos nunca se lanzarán.

En esta sección se configuran los aspectos generales del proxy. Como este componente es completamente independiente, en el fichero de configuración no habrá mucho más que esta sección y las definiciones de las bases de datos (Sección licenses), aunque normalmente si se trata de un escenario en que el servidor y el proxy estén en la misma máquina, en este mismo fichero están todas las secciones de configuración tanto de un componente como del otro.

Esta clave tiene como valor el nombre de host o la dirección IP del servidor con el cual se conectará el proxy para enviar los comandos que le llegan del cliente.

Si el proxy está en la misma máquina que el servidor real lo que más se verá en esta clave será “localhost” ó “127.0.0.1” que esto no significa que tenga que ser así obligatoriamente. Este campo es obligatorio y no tiene valor por defecto, así que si no se pone, el proxy no funcionará correctamente.

Al igual que para el cliente (recordar que el proxy se comporta a la vez como servidor y como cliente) hay que indicarle por qué puerto está esperando el servidor. Este campo no tiene valor por defecto, así que es obligatorio.

Tiene el mismo significado que para el servidor.

El valor por defecto será tres veces la cantidad de procesadores del sistema, determinadas cuando se arranca el proxy por primera vez. Esto es bueno decirlo en algún momento y es que la primera solicitud que se haga al proxy requerirá que se inicialize toda la DLL de extensión, y entre las cosas que se hacen está precisamente la creación del pool de subprocesos, la creación de estructuras intermedias, etc, por tanto esta primera solicitud demorará su poco, así que no desesperarse, que no son todas tan lentas como la primera.

Aunque se puede configurar el IIS para que acepte un determinado número de conexiones, la extensión como tal tiene un límite dado por la licencia comprada y por las características físicas del hardware en que corre (recordar que cada petición no va simplemente a servir HTML, sino que tiene que consultar un servidor que está limitado en conexiones y en carga por factores similares).

Aquí se puede limitar la cantidad de conexiones por debajo de la licencia que tiene la extensión para aquellos casos en que las características de hardware así lo exijan.

Una vez finalizada la instalación del CGSoft Replicator Server Advanced Edition, tendremos que copiar los ficheros necesarios para proceder a la migración. Estos ficheros se encuentran en la carpeta “Windows” del servidor inicial, y son los siguientes:

• “replicator.ini”. En caso de migración, necesitamos modificar el parámetro ConnString, indicando la nueva configuración de conexión, si es que se ha cambiado. Figura 1
• Fichero con nombre en hexadecimal y con extensión “.LIC”, que es la licencia del servidor de Replica. Figura 2
• Tantos ficheros con nombre de 8 dígitos (podemos identificarlo mirando la licenses del fichero de configuración “replicator.ini”) y extensión “.000” y posteriores “.001”. Obligatoria únicamente la existencia del fichero con extensión “.000”. Figura 2.

Figura 1:

Figura 2: