Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Terminez l'action de repartage
Après tout type de procédure de repartitionnement dans Amazon Kinesis Data Streams et avant la reprise du traitement normal des enregistrements, d'autres procédures doivent être effectuées et d'autres éléments doivent être pris en compte. Les sections suivantes décrivent ces procédures et considérations.
Rubriques
Attendre qu'un stream redevienne actif
Après avoir appelé une opération de repartagemergeShards
, splitShard
vous devez attendre que le flux redevienne actif. Le code à utiliser est le même que lorsque vous attendez qu'un flux devienne actif après la création d'un flux. Ce code se présente comme suit :
DescribeStreamRequest describeStreamRequest = new DescribeStreamRequest(); describeStreamRequest.setStreamName( myStreamName ); long startTime = System.currentTimeMillis(); long endTime = startTime + ( 10 * 60 * 1000 ); while ( System.currentTimeMillis() < endTime ) { try { Thread.sleep(20 * 1000); } catch ( Exception e ) {} try { DescribeStreamResult describeStreamResponse = client.describeStream( describeStreamRequest ); String streamStatus = describeStreamResponse.getStreamDescription().getStreamStatus(); if ( streamStatus.equals( "ACTIVE" ) ) { break; } // // sleep for one second // try { Thread.sleep( 1000 ); } catch ( Exception e ) {} } catch ( ResourceNotFoundException e ) {} } if ( System.currentTimeMillis() >= endTime ) { throw new RuntimeException( "Stream " + myStreamName + " never went active" ); }
Tenez compte du routage des données, de la persistance des données et de l'état de la partition après une refonte
Kinesis Data Streams est un service de streaming de données en temps réel. Vos applications doivent partir du principe que les données circulent en continu à travers les fragments de votre flux. Lorsque vous repartitionnez, les enregistrements de données qui étaient acheminés vers les partitions parent sont réacheminés vers les partitions enfant en se basant sur les valeurs de clé de hachage auxquelles sont mappées les clés de partition des enregistrements de données. Toutefois, les enregistrements de données qui se trouvaient dans les partitions parent avant le repartitionnement demeurent dans ces partitions. Les partitions parentes ne disparaissent pas lors du remaniement. Elles demeurent avec les données qu'elles contiennent avant le repartitionnement. Les enregistrements de données des partitions parents sont accessibles à l'aide des getRecords
opérations getShardIteratoret dans les Kinesis Data API Streams ou via la bibliothèque cliente Kinesis.
Note
Les enregistrements de données sont accessibles à partir du moment où ils sont ajoutés au flux jusqu'à la période de conservation actuelle. Cette constatation demeure vraie, quelles que soient les modifications apportées aux partitions du flux au cours de cette période. Pour plus d'informations sur la période de conservation d'un flux, consultez la page Modifier la période de conservation des données.
Au cours du processus de repartitionnement, une partition parent passe de l'état OPEN
à l'état CLOSED
, puis à l'état EXPIRED
.
-
OPEN: Avant une opération de refonte, une partition parent est dans l'
OPEN
état, ce qui signifie que les enregistrements de données peuvent être à la fois ajoutés à la partition et extraits de la partition. -
CLOSED: Après une opération de refonte, la partition parent passe à un
CLOSED
état. Cela signifie qu'aucun enregistrement de données n'est plus ajouté à la partition. Les enregistrements de données qui auraient été ajoutés à cette partition sont maintenant ajoutés à une partition enfant. Toutefois, des enregistrements de données peuvent encore être extraits de la partition pendant une durée limitée. -
EXPIRED: une fois la période de conservation du flux expirée, tous les enregistrements de données de la partition parent ont expiré et ne sont plus accessibles. À ce stade, la partition elle-même passe à l'état
EXPIRED
. Les appels degetStreamDescription().getShards
pour énumérer les partitions du flux n'incluent pas les partitions à l'étatEXPIRED
dans la liste des partitions renvoyées. Pour plus d'informations sur la période de conservation d'un flux, consultez la page Modifier la période de conservation des données.
Lorsque le repartitionnement est terminé et que le flux a de nouveau l'état ACTIVE
, vous pouvez commencer immédiatement à lire les données dans les partitions enfant. Cependant, les partitions parentes qui restent après la refonte peuvent toujours contenir des données que vous n'avez pas encore lues et qui ont été ajoutées au flux avant la refonte. Si vous lisez les données des partitions enfant avant d'avoir lu toutes les données des partitions parent, vous pouvez lire les données pour une clé de hachage spécifique sans respecter l'ordre donné par les numéros de séquence des enregistrements de données. Par conséquent, en supposant que l'ordre des données soit important, après un repartitionnement, vous devez toujours continuer à lire les données des partitions parentes jusqu'à leur épuisement. Ensuite seulement, vous devez commencer à lire les données des partitions enfants. Lorsque getRecordsResult.getNextShardIterator
renvoie null
, cela indique que vous avez lu toutes les données de la partition parent. Si vous lisez des données à l'aide de la bibliothèque cliente Kinesis, il est possible que vous ne les receviez pas dans l'ordre après une refonte.