Mantenimiento de bases de datos de réplicas

Una base de datos de réplica se debe supervisar como cualquier otra base de datos. Sin el mantenimiento regular de bases de datos, es posible que acumule documentos no válidos causados por interrupciones en el proceso de réplica. Tener muchos documentos no válidos puede dar lugar a un exceso de carga en el clúster cuando el proceso de replicador se reinicia mediante operaciones de IBM® Cloudant® for IBM Cloud®.

Para mantener una base de datos de réplicas, elimine los documentos antiguos. Puede eliminar documentos antiguos determinando su antigüedad y suprimirlos si ya no son necesarios.

El planificador de réplicas

El nuevo planificador de réplicas de IBM Cloudant proporciona una serie de mejoras en comparación con el mecanismo de réplica de IBM Cloudant anterior.

En concreto, el uso de red durante la réplica es más eficiente. El planificador tiene en cuenta la carga actual para nodos de base de datos individuales dentro de un clúster cuando determina la asignación de tareas de réplica.

Por último, el estado de una réplica es ahora más detallado y consta de siete estados distintos:

1. initializing (inicializando): la réplica se ha añadido al planificador, pero todavía no se ha inicializado o no está planificada su ejecución. El estado se produce cuando se almacena un documento de réplica nuevo o actualizado en la base de datos _replicator.
2. error: la réplica no se puede convertir en un trabajo. Este error puede estar causado por varios motivos. Por ejemplo, la réplica debe estar filtrada, pero se ha podido captar el código de filtro de la base de datos de origen.
3. pending (pendiente) : la ejecución del trabajo de réplica está planificada, pero aún no se está ejecutando.
4. running (en ejecución): el trabajo de réplica se está ejecutando.
5. crashing (bloqueando): se ha producido un error temporal que afecta al trabajo de réplica. El trabajo se volverá a intentar automáticamente más tarde.
6. completed (completado): el trabajo de réplica ha finalizado. Este estado no se aplica a las réplicas continuas.
7. failed (anomalía): el trabajo de réplica ha fallado. El error es permanente. Este estado significa que no se intenta crear la réplica utilizando esta tarea de réplica. El error puede deberse a distintas causas, por ejemplo que el URL de origen o de destino no sea válido.

La transición entre estos estados se ilustra en el siguiente diagrama:

El planificador incorpora dos nuevos puntos finales:

• /_scheduler/docs
• /_scheduler/jobs

Puede gestionar y determinar el estado de la réplica de forma más rápida y sencilla utilizando estos puntos finales.

Consulte el proceso típico para utilizar el planificador de réplicas para gestionar y supervisar réplicas:

1. Crea un documento de replicación que describa la replicación necesaria y guárdalo en la base de datos del replicador.
2. Supervise el estado de la réplica utilizando el punto final /_scheduler/docs.

Autenticación durante la réplica

En cualquier aplicación de producción, la seguridad de las bases de datos de origen y destino resulta esencial. Para que la réplica continúe, es necesaria la autenticación para acceder a las bases de datos. Los puntos de control para la replicación están activados por defecto, lo que significa que para replicar la base de datos de origen se necesita acceso de escritura.

Para habilitar la autenticación durante la réplica, incluya un nombre de usuario y una contraseña en el URL de la base de datos. El proceso de réplica utiliza los valores proporcionados para la autenticación básica HTTP.

Consulte el ejemplo siguiente para especificar los valores de nombre de usuario y contraseña para acceder a bases de datos de origen y de destino durante la réplica:

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  }
}

Para las credenciales IAM, utilice el siguiente ejemplo para autenticarse con una clave API IAM:

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  }
}

Réplica filtrada

A veces no desea transferir todos los documentos del origen al destino. Para elegir los documentos que desea transferir, incluya una o varias funciones de filtro en un documento de diseño del origen. A continuación, puede indicar al replicador que utilice estas funciones de filtro.

El filtrado de documentos durante la réplica es similar al proceso de filtrado del canal de información _changes.

Una función de filtro toma dos argumentos:

• El documento que se va a replicar.
• La solicitud de réplica.

Una función de filtro devuelve un valor true o false. Si el resultado es true, el documento se replica.

Para configurar el filtrado, utilice el campo selector siempre que sea posible. Cuando utilice el campo selector, puede especificar un filtro sin tener que replicar toda la base de datos. Este método hace que el filtrado sea más rápido y cause menos carga en IBM Cloudant. Para obtener más información, consulta la documentación sobre el campo « selector ».

Consulte el ejemplo siguiente de una función de filtro:

function(doc, req) {
	return !!(doc.type && doc.type == "foo");
}

Los filtros se almacenan bajo la clave filters superior del documento de diseño.

Consulte el ejemplo siguiente de almacenamiento de una función de filtro en un documento de diseño:

{
	"_id": "_design/myddoc",
	"filters": {
		"myfilter": "function goes here"
	}
}

Una réplica filtrada se inicia utilizando una sentencia JSON que identifica los elementos siguientes:

• La base de datos de origen.
• La base de datos de destino.
• El nombre del filtro almacenado bajo la clave filters del documento de diseño.

Consulte el JSON de ejemplo para iniciar una réplica filtrada:

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter"
}

Se pueden proporcionar argumentos a la función de filtro incluyendo pares de clave:valor en el campo query_params de la invocación.

Consulte el ejemplo de JSON para iniciar una réplica filtrada con parámetros:

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter",
  "query_params": {
    "key": "value"
  }
}

La opción selector proporciona ventajas en cuanto a rendimiento en comparación con el uso de la opción filter. Utilice la opción selector siempre que sea posible. Para obtener más información, consulta la selector documentación.

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"winning_revs_only": true
}

Réplica de documento con nombre

A veces no desea replicar documentos. Para réplicas sencillas, no es necesario que escriba una función de filtro. En su lugar, para replicar documentos específicos, añada la lista de claves como una matriz en el campo doc_ids.

Consulte la siguiente réplica de ejemplo de documentos específicos:

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://127.0.0.1:5984/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"doc_ids": ["foo", "bar", "baz"]
}

La propiedad user_ctx y delegaciones

Los documentos de réplica pueden tener una propiedad user_ctx personalizada. Esta propiedad define el contexto de usuario bajo el cual se ejecuta una réplica.

La forma antigua de activar réplicas, mediante la ejecución de POST sobre el punto final /_replicate/, no necesitaba la propiedad user_ctx. El motivo es que, en el momento de activar la réplica, toda la información necesaria sobre el usuario autenticado está disponible.

Por el contrario, la base de datos del replicador es una base de datos regular. La información sobre el usuario autenticado solo está presente en el momento en que el documento de replicación se guarda en la base de datos. Es decir, la implementación de la base de datos del replicador es similar a una aplicación de consumo de canal de información _changes, con el valor ?include_docs=true establecido.

A efectos de replicación, esta diferencia de implementación implica que, para los usuarios que no son administradores, se debe definir en el documento de replicación una propiedad « user_ctx » que incluya el nombre del usuario y un subconjunto de sus roles. En el documento de replicación. Este requisito se debe a una función de validación presente en el documento de diseño predeterminado de la base de datos del replicador. La función valida cada actualización del documento. Esta función de validación también garantiza que un usuario que no sea administrador no pueda establecer una propiedad de nombre de usuario en la propiedad « user_ctx » que no se corresponda con el nombre de usuario correcto. Este mismo principio también se aplica a los roles.

Consulte el siguiente ejemplo de documento de réplica delegada:

{
	"_id": "my_rep",
	"source": {
	  "url": "https://$SERVER.com:5984/foo",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/bar",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"continuous":  true,
	"user_ctx": {
		"name": "joe",
		"roles": ["erlanger", "researcher"]
	}
}

Para los administradores, la propiedad user_ctx es opcional. Si falta la propiedad, se adopta como valor predeterminado un contexto de usuario con el nombre null y una lista de roles vacía.

La lista de roles vacía significa que los documentos de diseño no se escriben en destinos locales durante la réplica. Si desea escribir documentos de diseño en destinos locales, se debe establecer de forma explícita un contexto de usuario con el rol _admin.

Además, para los administradores, la propiedad user_ctx se puede utilizar para activar una réplica para otro usuario. Este contexto de usuario se pasa a las funciones de validación del documento de base de datos de destino local.

La propiedad user_ctx solo se aplica a los puntos finales locales.

En resumen, para los administradores, la propiedad « user_ctx » es opcional. Mientras que para los usuarios normales (no administradores), es obligatorio. Cuando falta la propiedad de roles de user_ctx, se adopta como valor predeterminado la lista vacía [ ].

Opciones relacionadas con el rendimiento

Se pueden establecer varias opciones relacionadas con el rendimiento para una réplica, incluyéndolas en el documento de réplica.

use_bulk_get

Establézcalo en true para mejorar el rendimiento del trabajo de réplica. Una réplica capta documentos en lotes del origen. El aumento de la tasa de replicación puede consumir la capacidad de las cuentas de origen y destino más rápidamente, y dar lugar a que las solicitudes concurrentes de no replicación en esas cuentas experimenten más 429 HTTP errores.

connection_timeout

El periodo máximo de inactividad para una conexión en milisegundos. Si una conexión está desocupada durante este periodo, se reintenta su solicitud actual. El valor predeterminado es 30000 milisegundos (30 segundos).

http_connections

El número máximo de conexiones HTTP por réplica. Para las réplicas de envío (push), el número efectivo de conexiones HTTP que se utilizan es min(worker_processes + 1, http_connections). Para réplicas de extracción (pull), el número efectivo de conexiones que se utilizan corresponde al valor de este parámetro. El valor predeterminado es 20.

retries_per_request

El número máximo de reintentos por solicitud. Antes de un reintento, el replicador espera un breve periodo de tiempo antes de repetir la solicitud. Este periodo se duplica entre cada reintento consecutivo y nunca supera los 5 minutos. El valor mínimo antes del primer reintento es de 0,25 segundos. El valor predeterminado es 10 reintentos.

socket_options

Una lista de opciones para pasar a los sockets de conexión. Las opciones disponibles se pueden consultar en la documentación de la función de Erlang setopts del módulo inet . El valor predeterminado es [{keepalive, true},{nodelay, false}].

worker_batch_size

Los procesos de trabajador ejecutan lotes de tareas de réplica, donde el tamaño de lote está definido por este parámetro. El tamaño corresponde al número de filas del canal de información _changes. Valores más altos para el tamaño de lote pueden dar lugar a un mejor rendimiento. Valores más bajos significan que la comprobación se realiza con más frecuencia. El valor predeterminado es 500.

worker_processes

El número de procesos que el replicador utiliza en cada tarea de réplica para transferir documentos del origen a la base de datos de destino. Valores más altos pueden dar lugar a un mejor rendimiento debido a un mayor paralelismo en las actividades de red y de E/S de disco, pero esta mejora se produce a costa de requerir más memoria y tiempo de CPU. El valor predeterminado es 4.

Consulte el ejemplo siguiente que incluye las opciones de rendimiento en un documento de réplica:

{
	"source": {
	  "url": "https://example.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT1",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT2",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"connection_timeout": 60000,
	"retries_per_request": 20,
	"http_connections": 30
}

El efecto de gran cantidad de archivos adjuntos

Tener un gran número de archivos adjuntos en documentos puede causar un efecto adverso en el rendimiento de la réplica.

Para obtener más información sobre el efecto de los archivos adjuntos en el rendimiento de la réplica, consulte Consideraciones sobre el rendimiento.