Replica avanzata

È possibile conoscere i concetti e le attività di replica avanzate, come quelli nel seguente elenco e altro ancora:

Manutenzione del database di replica
Pianificazione e monitoraggio delle repliche
Autenticazione durante la replica

Potrebbe anche essere utile esaminare i dettagli del protocollo di replicae controlla la documentazione Riferimento API.

Manutenzione database di replica

Un database di replica deve essere monitorato come qualsiasi altro database. Senza una regolare manutenzione del database, è possibile accumulare documenti non validi causati da interruzioni del processo di replica. Avere molti documenti non validi può causare un sovraccarico del tuo cluster quando il processo del replicatore viene riavviato dalle operazioni IBM® Cloudant® for IBM Cloud®.

Per gestire un database di replica, rimuovere i vecchi documenti. Puoi rimuovere i vecchi documenti determinandone l'età e eliminandoli se non sono più necessari.

Lo scheduler di replica

Il nuovo scheduler di replica IBM Cloudant fornisce una serie di miglioramenti e miglioramenti rispetto al precedente meccanismo di replica IBM Cloudant.

In particolare, l'utilizzo della rete durante la replicazione è più efficiente. Lo scheduler considera il carico corrente per i singoli nodi di database all'interno di un cluster quando determina l'assegnazione delle attività di replica.

Infine, lo stato di una replica è ora più dettagliato e consiste in sette stati distinti:

initializing- La duplicazione è stata aggiunta allo scheduler, ma non è ancora inizializzata o pianificata per l'esecuzione. Lo stato si verifica quando un documento di replica nuovo o aggiornato viene memorizzato nel database _replicator.
error- La duplicazione non può essere trasformata in un lavoro. Questo errore potrebbe essere causato in diversi modi. Ad esempio, la replica deve essere filtrata, ma non è stato possibile recuperare il codice filtro dal database di origine.
pending- Il processo di replica è pianificato per essere eseguito, ma non è ancora in esecuzione.
running- Il lavoro di replica è in esecuzione.
crashing- Si verifica un errore temporaneo che influisce sul lavoro di replica. Il lavoro viene ritentato automaticamente in seguito.
completed- Il lavoro di replica è stato completato. Questo stato non si applica alle repliche continue.
failed- Il processo di replica non è andato a buon fine. L'errore è permanente. Questo stato indica che non viene effettuato alcun ulteriore tentativo di replica utilizzando questa attività di replica. L'errore potrebbe essere causato in diversi modi, ad esempio, se gli URL di origine o di destinazione non sono validi.

La transizione tra questi stati è illustrata nel diagramma seguente:

La transizione tra gli stati è descritta in , , e . — Stati dello Scheduler di replica

Il programma di pianificazione introduce due nuovi endpoint:

È possibile gestire e determinare lo stato della replica in modo più rapido e semplice utilizzando questi endpoint.

Consultare il processo tipico per l'uso dello scheduler di replica per gestire e monitorare le replica:

Creare un documento di replica che descrive la replica necessaria e memorizzare il documento nel database del replicatore.
Monitorare lo stato della replica utilizzando l'endpoint /_scheduler/docs.

Autenticazione durante la replica

In qualsiasi applicazione di produzione, la sicurezza dei database di origine e di destinazione è essenziale. Per continuare la replica, l'autenticazione è necessaria per accedere ai database. I punti di controllo per la replica sono abilitati per impostazione predefinita, il che significa che la replica del database di origine richiede l'accesso in scrittura.

Per abilitare l'autenticazione durante la replica, includere un nome utente e una password nel database URL. Il processo di replica utilizza i valori forniti per HTTP Basic Authentication.

Consultare il seguente esempio di specifica dei valori di nome utente e password per accedere ai database di origine e di destinazione durante la replica:

{
  "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"
      }
    }
  }
}

Per le credenziali IAM, utilizzare l'esempio seguente per autenticarsi con una chiave API IAM:

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

Replica filtrata

A volte non si desidera trasferire tutti i documenti dall'origine alla destinazione. Per scegliere quali documenti trasferire, includere una o più funzioni di filtro in un documento di progettazione sull'origine. È quindi possibile indicare al replicatore di utilizzare queste funzioni di filtro.

Il filtro dei documenti durante la duplicazione è simile al processo di filtro del feed _changes.

Una funzione di filtro richiede due argomenti:

Il documento da replicare.
La richiesta di replica.

Una funzione di filtro restituisce un valore true o false. Se il risultato è true, il documento viene replicato.

Per impostare il filtro, utilizzare il campo selector quando possibile. Quando si utilizza il campo selector, è possibile specificare un filtro senza dover replicare l'intero database. Questo metodo rende il filtraggio più rapido e causa un minor carico su IBM Cloudant. Per ulteriori informazioni, consultare la documentazione del campo selector.

Si veda il seguente esempio di funzione di filtro:

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

I filtri vengono memorizzati nella chiave filters più in alto del documento di progettazione.

Vedere il seguente esempio di memorizzazione di una funzione di filtro in un documento di progettazione:

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

Una replica filtrata viene avviata utilizzando un'istruzione JSON che identifica i seguenti elementi:

Il database di origine.
Il database di destinazione.
Il nome del filtro memorizzato nella chiave filters del documento di progettazione.

Vedi il JSON di esempio per avviare una replica filtrata:

{
  "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"
}

Gli argomenti possono essere forniti alla funzione di filtro includendo le coppie chiave: valore nel campo query_params del richiamo.

Vedi il JSON di esempio per l'avvio di una replica filtrata con i parametri forniti:

{
  "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"
  }
}

L'opzione selector fornisce vantaggi di prestazioni rispetto all'utilizzo dell'opzione filter. Utilizzare l'opzione selector quando possibile. Per ulteriori informazioni, consultare la documentazione di selector.

Eliminazione dei conflitti che utilizzano la replica

Utilizzare l'opzione winning_revs_only: true per replicare solo le revisioni di documenti vincenti. Queste revisioni sono le revisioni che verrebbero restituite dall'endpoint API GET $ACCOUNT/$DATABASE/$DOCID per impostazione predefinita o visualizzate nel Feed _changes con i parametri predefiniti.

{
	"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
}

La replica con questa modalità elimina le revisioni in conflitto, quindi potrebbe essere un modo per rimuovere i conflitti tramite la replica.

ID di replica e ID di checkpoint, generati da winning_revs_only: true Le repliche sono diverse da quelle generate per impostazione predefinita, quindi è possibile replicare prima le revisioni vincenti e, successivamente, recuperare il resto delle revisioni con un’operazione di replica regolare.

L'opzione winning_revs_only: true può essere combinata con filtri o altre opzioni come continuous: true o create_target: true.

Replica documento denominato

A volte non si desidera replicare i documenti. Per repliche semplici, non è necessario scrivere una funzione filtro. Invece, per replicare documenti specifici, aggiungere l'elenco di chiavi come un array nel campo doc_ids.

Vedere il seguente esempio di replica di documenti specifici:

{
	"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 proprietà `user_ctx` e le delegazioni

I documenti di replica possono avere una proprietà user_ctx personalizzata. Questa proprietà definisce il contesto utente in cui viene eseguita una replica.

Un modo meno recente di attivare le repliche, creando un POST sull'endpoint /_replicate/, non aveva bisogno della proprietà user_ctx. Il motivo è che al momento dell'attivazione della replica, sono disponibili tutte le informazioni necessarie sull'utente autenticato.

Al contrario, il database replicatore è un normale database. Le informazioni relative all'utente autenticato sono presenti solo nel momento in cui il documento di replica viene scritto sul database. In altre parole, l'implementazione del database del replicatore è simile a un'applicazione di consumo feed _changes, con ?include_docs=true impostato.

Per la replica, questa differenza di implementazione significa che per gli utenti non admin, una proprietà user_ctx che includa il nome dell'utente e un sottoinsieme dei relativi ruoli deve essere definita nel documento di replica. Questo requisito viene risolto da una funzione di convalida presente nel documento di progettazione predefinito del database del replicatore. La funzione convalida ogni aggiornamento del documento. Questa funzione di convalida garantisce inoltre che un utente non amministratore non possa impostare una proprietà username nella proprietà user_ctx che non corrisponde al nome utente corretto. Lo stesso principio vale anche per i ruoli.

Vedere il seguente documento di replica delegata di esempio:

{
	"_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"]
	}
}

Per gli amministratori, la proprietà user_ctx è facoltativa. Se la proprietà non è presente, il valore predefinito è un contesto utente con il nome null e un elenco di ruoli vuoto.

L'elenco vuoto dei ruoli indica che i documenti di progetto non vengono scritti nelle destinazioni locali durante la replica. Se si desidera scrivere documenti di progetto su destinazioni locali, è necessario impostare esplicitamente un contesto utente con il ruolo _admin.

Inoltre, per gli amministratori, la proprietà user_ctx può essere utilizzata per attivare una replica per un altro utente. Questo contesto utente viene passato alle funzioni di convalida del documento del database di destinazione locale.

La proprietà user_ctx si applica solo agli endpoint locali.

In sintesi, per gli amministratori, la proprietà user_ctx è facoltativa. Mentre per gli utenti normali (non amministratori), è obbligatorio. Quando la proprietà dei ruoli di user_ctx è mancante, per impostazione predefinita viene utilizzato l'elenco vuoto [ ].

È possibile impostare diverse opzioni relative alle prestazioni per una replica, includendole nel documento di replica.

use_bulk_get: Impostare su true per migliorare le prestazioni del lavoro di replica. Una replica richiama i documenti in batch dall'origine. L'aumento della velocità di replica può consumare più rapidamente la capacità degli account di origine e di destinazione e far sì che le richieste non replicate simultanee su tali account presentino più errori 429 HTTP errori.
connection_timeout: Il periodo massimo di inattività per una connessione in millisecondi. Se una connessione è inattiva per questo periodo, la richiesta corrente viene ritentata. Il valore predefinito è 30000 millisecondi (30 secondi).
http_connections: Il numero massimo di connessioni a HTTP per ogni replica. Per le repliche push, il numero effettivo di connessioni HTTP utilizzate è min(worker_processes + 1, http_connections). Per le repliche di pull, il numero effettivo di connessioni utilizzate corrisponde al valore di questo parametro. Il valore predefinito è 20.
retries_per_request: Il numero massimo di tentativi per richiesta. Prima di un nuovo tentativo, il replicatore attende per un breve periodo prima di ripetere la richiesta. Questo periodo raddoppia ogni tentativo consecutivo e non supera mai i 5 minuti. Il valore minimo prima del primo tentativo è 0.25 secondi. Il valore predefinito è 10 tentativi.
socket_options: Un elenco di opzioni da passare ai socket di collegamento. Le opzioni disponibili possono essere trovate nella documentazione per la funzione Erlang setopts del inet modulo. Il valore predefinito è [{keepalive, true},{nodelay, false}].
worker_batch_size: I processi di lavoro eseguono batch di attività di replica, in cui la dimensione del batch è definita da questo parametro. La dimensione corrisponde al numero di righe di feed _changes. Valori più elevati per la dimensione batch potrebbero determinare prestazioni migliori. Valori più piccoli indicano che il checkpoint viene eseguito più frequentemente. Il valore predefinito è 500.
worker_processes: Il numero di processi utilizzati dal replicatore in ogni attività di replica per trasferire documenti dal database di origine al database di destinazione. Valori più elevati potrebbero produrre una migliore velocità di trasmissione a causa di un maggiore parallelismo nelle attività IO di rete e disco, ma questo miglioramento comporta il costo di richiedere più memoria e potenzialmente tempo CPU. Il valore predefinito è 4.

Vedere il seguente esempio che include le opzioni di prestazioni in un documento di replica:

{
	"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
}

L'effetto di grandi attaccamenti

Avere un numero elevato di allegati sui documenti potrebbe causare un effetto negativo sulle prestazioni di replica.

Per ulteriori informazioni sull'effetto degli allegati sulle prestazioni della replica, consultare Considerazioni sulle prestazioni.

Come evitare l'endpoint `/_replicate`

Utilizzare il programma di pianificazione _replicator invece dell'endpoint /_replicate.

Se si verifica un problema durante la replica, ad esempio un blocco, un timeout o un arresto anomalo dell'applicazione, una replica definita nel database _replicator viene riavviata automaticamente dal sistema. Tuttavia, se definisci una replica inviando una richiesta all'endpoint /_replicate, non può essere riavviata dal sistema se si verifica un problema perché la richiesta di replica non persiste. Le repliche definite nel database _replicator sono più semplici da monitorare.

Replica avanzata

Replica avanzata

Manutenzione database di replica

Lo scheduler di replica

Autenticazione durante la replica

Replica filtrata

Eliminazione dei conflitti che utilizzano la replica

Replica documento denominato

La proprietà user_ctx e le delegazioni

Opzioni relative alle prestazioni

L'effetto di grandi attaccamenti

Come evitare l'endpoint /_replicate

La proprietà `user_ctx` e le delegazioni

Come evitare l'endpoint `/_replicate`