Completa la acción de refragmentación - Amazon Kinesis Data Streams
Espere a que una transmisión vuelva a activarseConsidere el enrutamiento de datos, la persistencia de los datos y el estado de la partición después de volver a compartirla

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Completa la acción de refragmentación

Después de realizar cualquier tipo de procedimiento que implique cambios en las particiones en Amazon Kinesis Data Streams y antes de reanudar el procesamiento de registros normal, son necesarios otros procedimientos y consideraciones. Estos pasos se describen en las siguientes secciones.

Espere a que una transmisión vuelva a activarse

Tras realizar una operación de refragmentaciónmergeShards, debe splitShard esperar a que la transmisión vuelva a activarse. El código que ha de usar es el mismo que al esperar a que una secuencia se active tras la creación de una secuencia. Ese código es el siguiente:

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" );
}

Considere el enrutamiento de datos, la persistencia de los datos y el estado de la partición después de volver a compartirla

Kinesis Data Streams es un servicio de transmisión de datos en tiempo real. Sus aplicaciones deben asumir que los datos fluyen de forma continua a través de los fragmentos de su transmisión. Cuando realiza cambios en los fragmentos, los registros de datos dirigidos a los fragmentos principales se redireccionan a los fragmentos secundarios en función de los valores de clave hash que asignan las claves de partición de los registros de datos. Sin embargo, los registros de datos que estaban en los fragmentos principales antes de los cambios permanecerán en dichos fragmentos. Los fragmentos principales no desaparecen cuando se produce el nuevo fragmento. Persistirán junto con los datos que contenían antes de los cambios. Se puede acceder a los registros de datos de las particiones principales mediante las getRecords operaciones getShardIteratory de Kinesis Data API Streams o a través de la biblioteca de clientes de Kinesis.

nota

Se puede obtener acceso a los registros de datos a partir del momento en el que se agregan a la secuencia y hasta el periodo de retención actual. Esto es así independientemente de los cambios en los fragmentos de la secuencia durante ese periodo. Para obtener más información acerca del periodo de retención de una secuencia, consulte Cambie el período de retención de los datos.

En el proceso de realizar cambios en los fragmentos, un fragmento principal cambia de un estado OPEN a un estado CLOSED, y después a un estado EXPIRED.

  • OPEN: Antes de una operación de repartición, la partición principal está en ese OPEN estado, lo que significa que los registros de datos se pueden añadir a la partición y recuperar de la misma.

  • CLOSED: Tras una operación de refragmentación, la partición principal pasa a un estado. CLOSED Esto implica que ya no se agregan registros de datos al fragmento. Los registros de datos que se habrían añadido a este fragmento se agregarán a un fragmento secundario en su lugar. Sin embargo, se pueden seguir recuperando registros de datos desde el fragmento durante un tiempo limitado.

  • EXPIRED: Una vez transcurrido el período de retención de la transmisión, todos los registros de datos del fragmento principal caducarán y ya no estarán accesibles. En este punto, el propio fragmento cambia a un estado EXPIRED. Las llamadas a getStreamDescription().getShards para enumerar los fragmentos de la secuencia no incluyen los fragmentos EXPIRED en la lista de fragmentos que devuelve. Para obtener más información acerca del periodo de retención de una secuencia, consulte Cambie el período de retención de los datos.

Tras realizar los cambios en los fragmentos, y cuando la secuencia ha recuperado el estado ACTIVE, podría comenzar inmediatamente a leer datos en los fragmentos secundarios. Sin embargo, es posible que los fragmentos principales que queden después del refragmento contengan datos que aún no hayas leído y que se hayan añadido a la transmisión antes del refragmento. Si lee datos de los fragmentos secundarios antes de haber leído todos los datos de los fragmentos principales, podría leer datos de una clave hash determinada fuera del orden determinado por los números secuenciales de los registros de datos. Por lo tanto, suponiendo que el orden de los datos sea importante, después de un cambio en los fragmentos siempre se deben seguir leyendo datos de los fragmentos principales hasta que se agoten. Solo entonces debería empezar a leer datos de los fragmentos secundarios. Cuando getRecordsResult.getNextShardIterator devuelve null, indica que ya ha leído todos los datos del fragmento principal. Si lee datos con la biblioteca de clientes de Kinesis, es posible que no reciba los datos en orden después de que se vuelva a fragmentar.