Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo dei flussi di modifica con Amazon DocumentDB
La funzionalità Change Streams di Amazon DocumentDB (con compatibilità con MongoDB) fornisce una sequenza temporale di eventi di modifica che si verificano all'interno delle raccolte del cluster. Puoi leggere gli eventi da un flusso di modifica per implementare molti casi d'uso diversi, inclusi i seguenti:
+ Notifica di modifica
+ Ricerca di testo completo con Amazon OpenSearch Service (OpenSearch Service)
+ Analisi con Amazon Redshift
Le applicazioni possono utilizzare i flussi di modifica per sottoscrivere tutte le modifiche ai dati su singole raccolte. Gli eventi di flussi di modifica vengono ordinati man mano che si verificano nel cluster e vengono archiviati per 3 ore (valore predefinito) dopo la registrazione dell'evento. Il periodo di conservazione può essere esteso fino a 7 giorni utilizzando il `change_stream_log_retention_duration` parametro. Per modificare il periodo di conservazione del flusso di modifica, consulta [Modifica della durata di conservazione del registro del flusso di modifica](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html#change_streams-modifying_log_retention).
**Topics**
+ [Operazioni supportate](#change_streams-supported_ops)
+ [Fatturazione](#change_streams-billing)
+ [Limitazioni](#change_streams-limitations)
+ [Abilitare i flussi di modifica](#change_streams-enabling)
+ [Esempio: utilizzo dei flussi di modifica con Python](#change_streams-using_example)
+ [Ricerca completa del documento](#change_streams-lookup)
+ [Ripresa di un flusso di modifiche](#change_streams-resuming)
+ [Ripresa di un flusso di modifiche con `startAtOperationTime`](#change_streams-startAtOperation)
+ [Ripresa di un flusso di modifiche con `postBatchResumeToken`](#change_streams-postBatchResumeToken)
+ [Transazioni nei flussi di modifica](#change_streams-transactions)
+ [Modifica della durata di conservazione del registro del flusso di modifiche](#change_streams-modifying_log_retention)
+ [Utilizzo dei flussi di modifica su istanze secondarie](#change-streams-secondary-instances)
## Operazioni supportate
Amazon DocumentDB supporta le seguenti operazioni per i flussi di modifica:
+ Tutti gli eventi di modifica supportati in `db.collection.watch()` MongoDB `db.watch()` e nell'API. `client.watch()`
+ Ricerca completa dei documenti per gli aggiornamenti.
+ Fasi di aggregazione:`$match`, `$project``$redact`, e e. `$addFields` `$replaceRoot`
+ Ripresa di un flusso di modifiche da un token di curriculum
+ Ripresa di un flusso di modifiche da un timestamp utilizzando `startAtOperation` (applicabile a Amazon DocumentDB 4.0\$1)
## Fatturazione
La funzionalità dei flussi di modifica di Amazon DocumentDB è disabilitata per impostazione predefinita e non comporta costi aggiuntivi finché non viene abilitata. L'utilizzo di flussi di modifiche in un cluster comporta costi di lettura e scrittura e di archiviazione aggiuntivi. IOs È possibile utilizzare l'operazione `modifyChangeStreams` API per abilitare questa funzionalità per il cluster. Per ulteriori informazioni sui prezzi, consulta i prezzi di [Amazon DocumentDB.](https://aws.amazon.com/documentdb/pricing/)
## Limitazioni
I flussi di modifica presentano le seguenti limitazioni in Amazon DocumentDB:
+ Su Amazon DocumentDB 3.6. e Amazon DocumentDB 4.0, i flussi di modifica possono essere aperti solo da una connessione all'istanza principale di un cluster Amazon DocumentDB. La lettura dai flussi di modifica su un'istanza di replica non è supportata su Amazon DocumentDB 3.6. e Amazon DocumentDB 4.0. Quando si richiama l'operazione API `watch()`, è necessario specificare una preferenza di lettura `primary` per assicurare che tutte le letture siano indirizzate all'istanza primaria (consulta la sezione [Esempio](#change_streams-using_example)).
+ Su Amazon DocumentDB 5.0, i flussi di modifica possono essere aperti sia da istanze primarie che da istanze secondarie, inclusi i cluster globali. Puoi specificare una preferenza di lettura secondaria per reindirizzare i flussi di modifica verso istanze secondarie. [Utilizzo dei flussi di modifica su istanze secondarie](#change-streams-secondary-instances)Per ulteriori best practice e limitazioni, consulta la sezione.
+ Gli eventi scritti in un flusso di modifiche per una raccolta sono disponibili per un massimo di 7 giorni (l'impostazione predefinita è 3 ore). I dati dei flussi di modifiche vengono eliminati dopo la finestra della durata di conservazione del log, anche se non si sono verificate nuove modifiche.
+ Un'operazione di scrittura di lunga durata su una raccolta come `updateMany` o `deleteMany` può temporaneamente bloccare la scrittura degli eventi dei flussi di modifica fino al completamento della lunga operazione di scrittura.
+ Amazon DocumentDB non supporta il log delle operazioni MongoDB (). `oplog`
+ Con Amazon DocumentDB, devi abilitare esplicitamente i flussi di modifica su una determinata raccolta.
+ Se la dimensione totale di un evento di flussi di modifica (inclusi i dati di modifica e il documento completo, se richiesto) è maggiore di `16 MB`, il client incontrerà un errore di lettura nei flussi di modifiche.
+ Il driver Ruby non è attualmente supportato quando si utilizza `db.watch()` e `client.watch()` con Amazon DocumentDB 3.6.
+ L'output del `updateDescription` comando nei flussi di modifica è diverso in Amazon DocumentDB rispetto a MongoDB quando il valore aggiornato del campo è lo stesso di quello precedente:
+ Amazon DocumentDB non restituisce un campo nell'`updateDescription`output se il campo fornito è specificato nel `$set` comando e il suo valore di destinazione è già uguale al valore di origine.
+ MongoDB restituisce il campo nell'output, anche se il valore specificato è uguale al valore corrente.
## Abilitare i flussi di modifica
Puoi abilitare i flussi di modifica di Amazon DocumentDB per tutte le raccolte all'interno di un determinato database o solo per raccolte selezionate. Di seguito sono riportati esempi di come abilitare i flussi di modifica per diversi casi d'uso utilizzando la shell mongo. Le stringhe vuote vengono trattate come caratteri jolly quando si specificano i nomi del database e della raccolta.
```
//Enable change streams for the collection "foo" in database "bar"
db.adminCommand({modifyChangeStreams: 1,
database: "bar",
collection: "foo",
enable: true});
```
```
//Disable change streams on collection "foo" in database "bar"
db.adminCommand({modifyChangeStreams: 1,
database: "bar",
collection: "foo",
enable: false});
```
```
//Enable change streams for all collections in database "bar"
db.adminCommand({modifyChangeStreams: 1,
database: "bar",
collection: "",
enable: true});
```
```
//Enable change streams for all collections in all databases in a cluster
db.adminCommand({modifyChangeStreams: 1,
database: "",
collection: "",
enable: true});
```
I flussi di modifica saranno abilitati per una raccolta se una delle seguenti condizioni è vera:
+ Sia il database sia la raccolta sono abilitati in modo esplicito.
+ Il database contenente la raccolta è abilitato.
+ Tutti i database sono abilitati.
L'eliminazione di una raccolta da un database non disabilita i flussi di modifica per tale raccolta se il database padre dispone anche di flussi di modifiche abilitati o se tutti i database nel cluster sono abilitati. Se viene creata una nuova raccolta con lo stesso nome della raccolta eliminata, i flussi di modifica verranno abilitati per tale raccolta.
È possibile elencare tutti i flussi di modifiche abilitati del cluster utilizzando la fase della pipeline di aggregazione `$listChangeStreams`. Tutte le fasi di aggregazione supportate da Amazon DocumentDB possono essere utilizzate nella pipeline per ulteriori elaborazioni. Se una raccolta precedentemente abilitata è stata disabilitata, non verrà visualizzata nell'output `$listChangeStreams`.
```
//List all databases and collections with change streams enabled
cursor = new DBCommandCursor(db,
db.runCommand(
{aggregate: 1,
pipeline: [{$listChangeStreams: 1}],
cursor:{}}));
```
```
//List of all databases and collections with change streams enabled
{ "database" : "test", "collection" : "foo" }
{ "database" : "bar", "collection" : "" }
{ "database" : "", "collection" : "" }
```
```
//Determine if the database “bar” or collection “bar.foo” have change streams enabled
cursor = new DBCommandCursor(db,
db.runCommand(
{aggregate: 1,
pipeline: [{$listChangeStreams: 1},
{$match: {$or: [{database: "bar", collection: "foo"},
{database: "bar", collection: ""},
{database: "", collection: ""}]}}
],
cursor:{}}));
```
## Esempio: utilizzo dei flussi di modifica con Python
Di seguito è riportato un esempio di utilizzo di un flusso di modifiche di Amazon DocumentDB con Python a livello di raccolta.
```
import os
import sys
from pymongo import MongoClient, ReadPreference
username = "DocumentDBusername"
password =
clusterendpoint = "DocumentDBClusterEndpoint”
client = MongoClient(clusterendpoint, username=username, password=password, tls='true', tlsCAFile='global-bundle.pem')
db = client['bar']
#While ‘Primary’ is the default read preference, here we give an example of
#how to specify the required read preference when reading the change streams
coll = db.get_collection('foo', read_preference=ReadPreference.PRIMARY)
#Create a stream object
stream = coll.watch()
#Write a new document to the collection to generate a change event
coll.insert_one({'x': 1})
#Read the next change event from the stream (if any)
print(stream.try_next())
"""
Expected Output:
{'_id': {'_data': '015daf94f600000002010000000200009025'},
'clusterTime': Timestamp(1571788022, 2),
'documentKey': {'_id': ObjectId('5daf94f6ea258751778163d6')},
'fullDocument': {'_id': ObjectId('5daf94f6ea258751778163d6'), 'x': 1},
'ns': {'coll': 'foo', 'db': 'bar'},
'operationType': 'insert'}
"""
#A subsequent attempt to read the next change event returns nothing, as there are no new changes
print(stream.try_next())
"""
Expected Output:
None
"""
#Generate a new change event by updating a document
result = coll.update_one({'x': 1}, {'$set': {'x': 2}})
print(stream.try_next())
"""
Expected Output:
{'_id': {'_data': '015daf99d400000001010000000100009025'},
'clusterTime': Timestamp(1571789268, 1),
'documentKey': {'_id': ObjectId('5daf9502ea258751778163d7')},
'ns': {'coll': 'foo', 'db': 'bar'},
'operationType': 'update',
'updateDescription': {'removedFields': [], 'updatedFields': {'x': 2}}}
"""
```
Di seguito è riportato un esempio di utilizzo di un flusso di modifiche di Amazon DocumentDB con Python a livello di database.
```
import os
import sys
from pymongo import MongoClient
username = "DocumentDBusername"
password =
clusterendpoint = "DocumentDBClusterEndpoint”
client = MongoClient(clusterendpoint, username=username, password=password, tls='true', tlsCAFile='global-bundle.pem')
db = client['bar']
#Create a stream object
stream = db.watch()
coll = db.get_collection('foo')
#Write a new document to the collection foo to generate a change event
coll.insert_one({'x': 1})
#Read the next change event from the stream (if any)
print(stream.try_next())
"""
Expected Output:
{'_id': {'_data': '015daf94f600000002010000000200009025'},
'clusterTime': Timestamp(1571788022, 2),
'documentKey': {'_id': ObjectId('5daf94f6ea258751778163d6')},
'fullDocument': {'_id': ObjectId('5daf94f6ea258751778163d6'), 'x': 1},
'ns': {'coll': 'foo', 'db': 'bar'},
'operationType': 'insert'}
"""
#A subsequent attempt to read the next change event returns nothing, as there are no new changes
print(stream.try_next())
"""
Expected Output:
None
"""
coll = db.get_collection('foo1')
#Write a new document to another collection to generate a change event
coll.insert_one({'x': 1})
print(stream.try_next())
"""
Expected Output: Since the change stream cursor was the database level you can see change events from different collections in the same database
{'_id': {'_data': '015daf94f600000002010000000200009025'},
'clusterTime': Timestamp(1571788022, 2),
'documentKey': {'_id': ObjectId('5daf94f6ea258751778163d6')},
'fullDocument': {'_id': ObjectId('5daf94f6ea258751778163d6'), 'x': 1},
'ns': {'coll': 'foo1', 'db': 'bar'},
'operationType': 'insert'}
"""
```
## Ricerca completa del documento
L'evento di modifica dell'aggiornamento non include il documento completo, ma include solo la modifica apportata. Se il caso d'uso richiede il documento completo interessato da un aggiornamento, è possibile abilitare la ricerca completa del documento all'apertura del flusso.
Il documento `fullDocument` per un evento di aggiornamento del flusso di modifiche rappresenta la versione più recente del documento aggiornato al momento della ricerca del documento. Se si sono verificate modifiche tra l'operazione di aggiornamento e la ricerca `fullDocument`, il documento `fullDocument` potrebbe non rappresentare lo stato del documento al momento dell'aggiornamento.
Per creare un oggetto stream con la ricerca degli aggiornamenti abilitata, utilizzate questo esempio:
```
stream = coll.watch(full_document='updateLookup')
#Generate a new change event by updating a document
result = coll.update_one({'x': 2}, {'$set': {'x': 3}})
stream.try_next()
```
L'output dell'oggetto stream sarà simile al seguente:
```
{'_id': {'_data': '015daf9b7c00000001010000000100009025'},
'clusterTime': Timestamp(1571789692, 1),
'documentKey': {'_id': ObjectId('5daf9502ea258751778163d7')},
'fullDocument': {'_id': ObjectId('5daf9502ea258751778163d7'), 'x': 3},
'ns': {'coll': 'foo', 'db': 'bar'},
'operationType': 'update',
'updateDescription': {'removedFields': [], 'updatedFields': {'x': 3}}}
```
## Ripresa di un flusso di modifiche
È possibile riprendere un flusso di modifiche successivamente utilizzando un token di ripresa, che è uguale al campo `_id` dell'ultimo documento dell'evento di modifica recuperato.
```
import os
import sys
from pymongo import MongoClient
username = "DocumentDBusername"
password =
clusterendpoint = "DocumentDBClusterEndpoint”
client = MongoClient(clusterendpoint, username=username, password=password, tls='true', tlsCAFile='global-bundle.pem', retryWrites='false')
db = client['bar']
coll = db.get_collection('foo')
#Create a stream object
stream = db.watch()
coll.update_one({'x': 1}, {'$set': {'x': 4}})
event = stream.try_next()
token = event['_id']
print(token)
"""
Output: This is the resume token that we will later us to resume the change stream
{'_data': '015daf9c5b00000001010000000100009025'}
"""
#Python provides a nice shortcut for getting a stream’s resume token
print(stream.resume_token)
"""
Output
{'_data': '015daf9c5b00000001010000000100009025'}
"""
#Generate a new change event by updating a document
result = coll.update_one({'x': 4}, {'$set': {'x': 5}})
#Generate another change event by inserting a document
result = coll.insert_one({'y': 5})
#Open a stream starting after the selected resume token
stream = db.watch(full_document='updateLookup', resume_after=token)
#Our first change event is the update with the specified _id
print(stream.try_next())
"""
#Output: Since we are resuming the change stream from the resume token, we will see all events after the first update operation. In our case, the change stream will resume from the update operation {x:5}
{'_id': {'_data': '015f7e8f0c000000060100000006000fe038'},
'operationType': 'update',
'clusterTime': Timestamp(1602129676, 6),
'ns': {'db': 'bar', 'coll': 'foo'},
'documentKey': {'_id': ObjectId('5f7e8f0ac423bafbfd9adba2')},
'fullDocument': {'_id': ObjectId('5f7e8f0ac423bafbfd9adba2'), 'x': 5},
'updateDescription': {'updatedFields': {'x': 5}, 'removedFields': []}}
"""
#Followed by the insert
print(stream.try_next())
"""
#Output:
{'_id': {'_data': '015f7e8f0c000000070100000007000fe038'},
'operationType': 'insert',
'clusterTime': Timestamp(1602129676, 7),
'ns': {'db': 'bar', 'coll': 'foo'},
'documentKey': {'_id': ObjectId('5f7e8f0cbf8c233ed577eb94')},
'fullDocument': {'_id': ObjectId('5f7e8f0cbf8c233ed577eb94'), 'y': 5}}
"""
```
## Ripresa di un flusso di modifiche con `startAtOperationTime`
È possibile riprendere un flusso di modifiche in un secondo momento da un determinato timestamp utilizzando. `startAtOperationTime`
**Nota**
La capacità di utilizzo `startAtOperationTime` è disponibile in Amazon DocumentDB 4.0\$1. Quando viene utilizzato`startAtOperationTime`, il cursore del flusso di modifica restituirà solo le modifiche avvenute in corrispondenza o dopo il timestamp specificato. I `resumeAfter` comandi `startAtOperationTime` and si escludono a vicenda e quindi non possono essere usati insieme.
```
import os
import sys
from pymongo import MongoClient
username = "DocumentDBusername"
password =
clusterendpoint = "DocumentDBClusterEndpoint”
client = MongoClient(clusterendpoint, username=username, password=password, tls='true', tlsCAFile='rds-root-ca-2020.pem',retryWrites='false')
db = client['bar']
coll = db.get_collection('foo')
#Create a stream object
stream = db.watch()
coll.update_one({'x': 1}, {'$set': {'x': 4}})
event = stream.try_next()
timestamp = event['clusterTime']
print(timestamp)
"""
Output
Timestamp(1602129114, 4)
"""
#Generate a new change event by updating a document
result = coll.update_one({'x': 4}, {'$set': {'x': 5}})
result = coll.insert_one({'y': 5})
#Generate another change event by inserting a document
#Open a stream starting after specified time stamp
stream = db.watch(start_at_operation_time=timestamp)
print(stream.try_next())
"""
#Output: Since we are resuming the change stream at the time stamp of our first update operation (x:4), the change stream cursor will point to that event
{'_id': {'_data': '015f7e941a000000030100000003000fe038'},
'operationType': 'update',
'clusterTime': Timestamp(1602130970, 3),
'ns': {'db': 'bar', 'coll': 'foo'},
'documentKey': {'_id': ObjectId('5f7e9417c423bafbfd9adbb1')},
'updateDescription': {'updatedFields': {'x': 4}, 'removedFields': []}}
"""
print(stream.try_next())
"""
#Output: The second event will be the subsequent update operation (x:5)
{'_id': {'_data': '015f7e9502000000050100000005000fe038'},
'operationType': 'update',
'clusterTime': Timestamp(1602131202, 5),
'ns': {'db': 'bar', 'coll': 'foo'},
'documentKey': {'_id': ObjectId('5f7e94ffc423bafbfd9adbb2')},
'updateDescription': {'updatedFields': {'x': 5}, 'removedFields': []}}
"""
print(stream.try_next())
"""
#Output: And finally the last event will be the insert operation (y:5)
{'_id': {'_data': '015f7e9502000000060100000006000fe038'},
'operationType': 'insert',
'clusterTime': Timestamp(1602131202, 6),
'ns': {'db': 'bar', 'coll': 'foo'},
'documentKey': {'_id': ObjectId('5f7e95025c4a569e0f6dde92')},
'fullDocument': {'_id': ObjectId('5f7e95025c4a569e0f6dde92'), 'y': 5}}
"""
```
## Ripresa di un flusso di modifiche con `postBatchResumeToken`
Il flusso di modifiche di Amazon DocumentDB ora restituisce un campo aggiuntivo chiamato. `postBatchResumeToken` Questo campo viene restituito dal `$changestream` comando e dal `getMore` comando.
Esempio del `$changestream` comando in Python:
```
db.command({"aggregate": "sales", "pipeline": [{ "$changeStream": {}}], "cursor": {"batchSize": 1}})
```
Output previsto:
```
cursor" : {
"firstBatch" : [ ],
"postBatchResumeToken" : {"_data" : "0167c8cbe60000000004"},
"id" : NumberLong("9660788144470"),
"ns" : "test.sales"
}
```
Esempio del `getMore` comando in Python:
```
db.command({"getMore": NumberLong(), "collection": "sales", "batchSize": 1 })
```
Output previsto
```
cursor" : {
"nextBatch" : [ ],
"postBatchResumeToken" : {"_data" : "0167c8cbe60000000004"},
"id" : NumberLong("9660788144470"),
"ns" : "test.sales"
}
```
Il `postBatchResumeToken` campo può essere utilizzato per aprire nuovi cursori Change Stream nel `resumeAfter` campo, in modo simile a come viene utilizzato il token resume.
Apri uno stream che inizia dopo quello selezionato: `postBatchResumeToken`
```
post_batch_resume_token = output['cursor']['postBatchResumeToken']
stream = db.watch(full_document='updateLookup', resume_after=post_batch_resume_token)
```
A differenza di un normale token di curriculum che corrisponde sempre a una voce del registro delle operazioni (oplog) che riflette un evento effettivo, `postBatchResumeToken` corrisponde a una voce oplog rilevata dal flusso di modifiche sul server, che non è necessariamente una modifica corrispondente.
Il tentativo di riprendere con un vecchio token di riavvio normale forzerà il database a scansionare tutte le voci oplog comprese tra il timestamp specificato e l'ora corrente. Ciò può generare molte query internamente con ogni sottoquery che esegue la scansione per un breve periodo di tempo. Ciò causerà un picco nell'utilizzo della CPU e ridurrà le prestazioni del database. La ripresa con l'ultimo `postBatchResumeToken` salta la scansione delle voci di oplog non corrispondenti.
## Transazioni nei flussi di modifica
Gli eventi Change Stream non conterranno eventi derivanti da transazioni interrotte senza impegno and/or . Ad esempio, se si avvia una transazione con una sola `INSERT` operazione e se `UPDATE` l'operazione ha esito positivo, ma l'`INSERT``UPDATE`operazione ha esito negativo, la transazione verrà annullata. Poiché questa transazione è stato ripristinato, il flusso di modifiche non conterrà alcun evento relativo a questa transazione.
## Modifica della durata di conservazione del registro del flusso di modifiche
È possibile modificare la durata di conservazione del registro del flusso di modifiche in modo che sia compresa tra 1 ora e 7 giorni utilizzando il Console di gestione AWS AWS CLI.
------
#### [ Using the Console di gestione AWS ]
**Per modificare la durata di conservazione del registro del flusso di modifica**
1. [Accedi a e apri Console di gestione AWS la console Amazon DocumentDB all'indirizzo https://console.aws.amazon.com /docdb.](https://console.aws.amazon.com/docdb)
1. Nel riquadro di navigazione scegliere **Parameter groups (Gruppi di parametri)**.
**Suggerimento**
Se il riquadro di navigazione non viene visualizzato sul lato sinistro della schermata, scegliere l'icona del menu (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/it_it/documentdb/latest/developerguide/images/docdb-menu-icon.png)) nell'angolo in alto a sinistra della pagina.
1. Nel riquadro **Parameter groups (Gruppi di parametri)** scegliere il gruppo di parametri cluster associato al cluster. Per identificare il gruppo di parametri del cluster associato al cluster, consulta [Determinazione del gruppo di parametri di un cluster Amazon DocumentDB](cluster_parameter_groups-describe.md#cluster_parameter_groups-determine).
1. La pagina risultante mostra i parametri e i relativi dettagli corrispondenti per questo gruppo di parametri del cluster. Selezionare il parametro `change_stream_log_retention_duration`.
1. In alto a destra della pagina, scegliere **Edit (Modifica)** per modificare il valore del parametro. Il `change_stream_log_retention_duration` parametro può essere modificato per essere compreso tra 1 ora e 7 giorni.
1. Apportare la modifica, quindi scegliere **Modify cluster parameter (Modifica parametro cluster)** per salvare le modifiche. Per annullare le modifiche, selezionare **Cancel (Annulla)**.
------
#### [ Using the AWS CLI ]
Per modificare il parametro `change_stream_log_retention_duration` di un gruppo di parametri del cluster, utilizzare l'operazione `modify-db-cluster-parameter-group` con i parametri seguenti.
+ **--db-cluster-parameter-group-name**: obbligatorio. Il nome del gruppo di parametri del cluster che stai modificando. Per identificare il gruppo di parametri del cluster associato al cluster, consulta [Determinazione del gruppo di parametri di un cluster Amazon DocumentDB](cluster_parameter_groups-describe.md#cluster_parameter_groups-determine).
+ **--parameters**: obbligatorio. Il parametro che stai modificando. Ogni voce del parametro deve includere:
+ **ParameterName**— Il nome del parametro che state modificando. In questo caso, è `change_stream_log_retention_duration`
+ **ParameterValue**— Il nuovo valore per questo parametro.
+ **ApplyMethod**— Come si desidera applicare le modifiche a questo parametro. I valori consentiti sono `immediate` e `pending-reboot`.
**Nota**
I parametri con `ApplyType` per `static` devono avere `ApplyMethod` per `pending-reboot`.
1. Per modificare i valori del parametro `change_stream_log_retention_duration`, eseguire il comando seguente e sostituire `parameter-value` con il valore a cui si desidera modificare il parametro.
Per Linux, macOS o Unix:
```
aws docdb modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name sample-parameter-group \
--parameters "ParameterName=change_stream_log_retention_duration,ParameterValue=,ApplyMethod=immediate"
```
Per Windows:
```
aws docdb modify-db-cluster-parameter-group ^
--db-cluster-parameter-group-name sample-parameter-group ^
--parameters "ParameterName=change_stream_log_retention_duration,ParameterValue=,ApplyMethod=immediate"
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"DBClusterParameterGroupName": "sample-parameter-group"
}
```
1. Attendi almeno 5 minuti.
1. Elenca i valori dei parametri di `sample-parameter-group` per essere certo che le modifiche siano state apportate.
Per Linux, macOS o Unix:
```
aws docdb describe-db-cluster-parameters \
--db-cluster-parameter-group-name sample-parameter-group
```
Per Windows:
```
aws docdb describe-db-cluster-parameters ^
--db-cluster-parameter-group-name sample-parameter-group
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"Parameters": [
{
"ParameterName": "audit_logs",
"ParameterValue": "disabled",
"Description": "Enables auditing on cluster.",
"Source": "system",
"ApplyType": "dynamic",
"DataType": "string",
"AllowedValues": "enabled,disabled",
"IsModifiable": true,
"ApplyMethod": "pending-reboot"
},
{
"ParameterName": "change_stream_log_retention_duration",
"ParameterValue": "12345",
"Description": "Duration of time in seconds that the change stream log is retained and can be consumed.",
"Source": "user",
"ApplyType": "dynamic",
"DataType": "integer",
"AllowedValues": "3600-86400",
"IsModifiable": true,
"ApplyMethod": "immediate"
}
]
}
```
------
**Nota**
La conservazione dei log del flusso di modifiche non eliminerà i log più vecchi del `change_stream_log_retention_duration` valore configurato finché la dimensione del registro non sarà superiore a (>) 51.200 MB.
## Utilizzo dei flussi di modifica su istanze secondarie
Per iniziare a utilizzare change stream su istanze secondarie, apri il cursore change stream con `readPreference` come secondario.
Puoi aprire un cursore del flusso di modifica per controllare gli eventi di modifica su una raccolta specifica o su tutte le raccolte in un cluster o database. Puoi aprire un cursore Change Stream su qualsiasi istanza Amazon DocumentDB e recuperare documenti Change Stream da entrambe le istanze Writer e Reader. Puoi condividere i token change stream (come `resumeToken` or`startOperationTime`) tra diversi cursori di change stream aperti su un'istanza writer e reader.
**Esempio**
```
import os
import sys
from pymongo import MongoClient, ReadPreference
username = "DocumentDBusername"
password =
clusterendpoint = "DocumentDBClusterEndpoint"
client = MongoClient(clusterendpoint, username=username, password=password, tls='true', tlsCAFile='global-bundle.pem')
db = client['bar']
# Make sure to use SECONDARY to redirect cursor reads from secondary instances
coll = db.get_collection('foo', read_preference=ReadPreference.SECONDARY)
# Create a stream object on RO. The token needs to generated from PRIMARY.
stream = coll.watch(resumeAfter=token)
for event in stream:
print(event)
```
**Linee guida e limitazioni per i flussi di modifica sulle istanze secondarie**
+ Gli eventi del flusso di modifiche devono essere replicati dall'istanza principale alle istanze secondarie. Puoi monitorare il ritardo dalla `DBInstanceReplicaLag` metrica in Amazon. CloudWatch
+ I timestamp sulle istanze secondarie potrebbero non essere sempre sincronizzati con l'istanza principale. In questo caso, aspettatevi ritardi sul timestamp dell'istanza secondaria in modo che possa recuperare il ritardo. Come procedura ottimale, consigliamo di utilizzare `startAtOperationTime` o `resumeToken` avviare l'orologio sull'istanza secondaria.
+ Potresti riscontrare un throughput inferiore sulle istanze secondarie rispetto all'istanza principale se le dimensioni del documento sono grandi`fullDocumentLookup`, lo stai facendo e il carico di lavoro di scrittura simultanea sull'istanza principale è elevato. Come procedura ottimale, ti consigliamo di monitorare il rapporto di accessi della cache del buffer sulla cache secondaria e di assicurarti che il rapporto di accessi della cache del buffer sia elevato.