Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Selesaikan tindakan resharding
Setelah prosedur resharding apa pun di Amazon Kinesis Data Streams, dan sebelum pemrosesan rekaman normal dilanjutkan, prosedur dan pertimbangan lain diperlukan. Bagian berikut menjelaskan ini.
Topik
Tunggu streaming menjadi aktif kembali
Setelah memanggil operasi resharding, salah splitShard satu ataumergeShards, Anda harus menunggu streaming aktif kembali. Kode yang digunakan sama seperti saat Anda menunggu streaming menjadi aktif setelah membuat aliran. Kode itu adalah sebagai berikut:
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" ); }
Pertimbangkan perutean data, persistensi data, dan status pecahan setelah hard ulang
Kinesis Data Streams adalah layanan streaming data real-time. Aplikasi Anda harus mengasumsikan bahwa data mengalir terus menerus melalui pecahan di aliran Anda. Saat Anda melakukan hard ulang, catatan data yang mengalir ke pecahan induk akan dialihkan untuk mengalir ke pecahan turunan berdasarkan nilai kunci hash yang dipetakan oleh kunci partisi rekaman data. Namun, catatan data apa pun yang ada di pecahan induk sebelum reshard tetap berada di pecahan tersebut. Pecahan induk tidak hilang saat rehard terjadi. Mereka bertahan bersama dengan data yang mereka miliki sebelum reshard. Catatan data di pecahan induk dapat diakses menggunakan getRecords operasi getShardIterator dan di Kinesis Data Streams API, atau melalui Kinesis Client Library.
catatan
Catatan data dapat diakses dari saat ditambahkan ke aliran ke periode retensi saat ini. Ini berlaku terlepas dari perubahan apa pun pada pecahan dalam aliran selama periode waktu tersebut. Untuk informasi selengkapnya tentang periode retensi streaming, lihatMengubah periode penyimpanan data.
Dalam proses resharding, pecahan induk bertransisi dari OPEN keadaan ke keadaan ke CLOSED keadaan. EXPIRED
-
BUKA: Sebelum operasi reshard, pecahan induk berada dalam
OPENstatus, yang berarti bahwa catatan data dapat ditambahkan ke shard dan diambil dari pecahan. -
TUTUP: Setelah operasi rehard, pecahan induk bertransisi ke status.
CLOSEDIni berarti bahwa catatan data tidak lagi ditambahkan ke shard. Catatan data yang akan ditambahkan ke pecahan ini sekarang ditambahkan ke pecahan anak sebagai gantinya. Namun, catatan data masih dapat diambil dari pecahan untuk waktu yang terbatas. -
KED ALUWARSA: Setelah periode retensi streaming berakhir, semua catatan data di pecahan induk telah kedaluwarsa dan tidak lagi dapat diakses. Pada titik ini, pecahan itu sendiri bertransisi ke suatu
EXPIREDkeadaan. PanggilangetStreamDescription().getShardsuntuk menghitung pecahan dalam aliran tidak menyertakan pecahan dalamEXPIREDpecahan daftar yang dikembalikan. Untuk informasi selengkapnya tentang periode retensi streaming, lihatMengubah periode penyimpanan data.
Setelah reshard terjadi dan aliran kembali dalam ACTIVE keadaan, Anda dapat segera mulai membaca data dari pecahan anak. Namun, pecahan induk yang tersisa setelah hard ulang mungkin masih berisi data yang belum Anda baca yang ditambahkan ke aliran sebelum hard ulang. Jika Anda membaca data dari pecahan anak sebelum membaca semua data dari pecahan induk, Anda dapat membaca data untuk kunci hash tertentu di luar urutan yang diberikan oleh nomor urut catatan data. Oleh karena itu, dengan asumsi bahwa urutan data itu penting, Anda harus, setelah hard ulang, selalu terus membaca data dari pecahan induk sampai habis. Hanya dengan begitu Anda harus mulai membaca data dari pecahan anak. Saat getRecordsResult.getNextShardIterator kembalinull, ini menunjukkan bahwa Anda telah membaca semua data di pecahan induk.