Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Format tabel tunggal untuk KCL
Dimulai dengan KCL 3.5, Anda dapat mengkonsolidasikan semua metadata DynamoDB ke dalam tabel sewa tunggal menggunakan format tabel tunggal. Secara default, KCL 3.x membuat tiga tabel DynamoDB untuk setiap aplikasi: tabel sewa, tabel metrik pekerja, dan tabel status koordinator. Format tabel tunggal mengurangi ketiga tabel ini menjadi satu, yang membantu Anda menghindari batas tabel tingkat akun DynamoDB.
Cara kerja format tabel tunggal
Dalam format tabel tunggal, KCL menyimpan metrik pekerja dan entri status koordinator dalam tabel sewa bersama entri sewa. Setiap item menyertakan entityType atribut yang membedakan antara jenis rekaman yang berbeda.
Metrik pekerja dan item status koordinator menggunakan struktur kunci utama yang sama dengan tabel sewa tetapi menyertakan nilai yang berbeda. entityType Atribut ini memungkinkan KCL untuk mengidentifikasi tujuan setiap item selama pemindaian tabel.
Setiap komponen KCL menyaring entri yang diperlukan untuk logika bisnisnya berdasarkan atribut. entityType Misalnya, Manajer Penugasan Sewa (LAM) memfilter entri metrik sewa dan pekerja untuk melakukan penugasan sewa.
Konfigurasikan format tabel tunggal
Cara Anda mengaktifkan format tabel tunggal tergantung pada versi KCL Anda saat ini:
-
Jika Anda menggunakan KCL 2.x: Ikuti panduan migrasi yang diperbarui untuk meningkatkan ke KCL 3.5. Format tabel tunggal digunakan secara default untuk migrasi baru dari 2.x ke 3.5.
-
Jika Anda menggunakan KCL 3.0—3.4: Anda harus melakukan penerapan dua fase untuk bermigrasi ke format tabel tunggal. Lihat konfigurasi dan langkah migrasi berikut.
Untuk pelanggan KCL 3.x yang ada, atur opsi migrateAllEntitiesToLeaseTable konfigurasi di. CoordinatorConfig Opsi ini mengontrol apakah KCL menyimpan semua jenis entitas metadata dalam tabel sewa.
| Nilai | Default | Efek |
|---|---|---|
false |
Ya |
KCL menggunakan tabel terpisah untuk metrik pekerja dan status koordinator. Kode aplikasi mendukung format tabel tunggal tetapi tidak mengaktifkannya. |
true |
Tidak |
KCL mulai menulis metrik pekerja dan data status koordinator ke dalam tabel sewa. Tetapkan nilai ini pada penerapan Fase 2 setelah |
Migrasi dari KCL 3.x ke format tabel tunggal memerlukan penerapan dua fase:
-
Fase 1: Terapkan kode KCL 3.5 yang diperbarui dengan
migrateAllEntitiesToLeaseTabledisetel kefalse(default). Ini menginstal kode baru yang mendukung format tabel tunggal tetapi tidak mengaktifkan migrasi. -
Fase 2: Setelah semua pekerja menjalankan kode baru dan
TableMigrationStatusjangkauanDEPLOYED, dan Anda telah memverifikasi bahwa tidak ada regresi, terapkan lagi denganmigrateAllEntitiesToLeaseTablesettrueuntuk memulai migrasi.
Status migrasi
TableMigrationStateMachineMengelola transisi dari format multi-tabel ke format tabel tunggal. KCL melacak status migrasi saat ini dalam entri status koordinator terpisah yang disebut TableMigration3.5 dalam tabel status koordinator. Untuk daftar lengkap status, transisi, dan deskripsi, lihat Status migrasi tabel tunggal KCL
| Status | Deskripsi | Kondisi transisi |
|---|---|---|
INIT |
Keadaan awal. Semua pekerja memancarkan kode dukungan minimum dalam statistik metrik pekerja. Pekerja terus memancarkan metrik pekerja ke dalam tabel lama dan membaca metrik pekerja dan status koordinator dari tabel lama dan sewa. Secara fungsional, tidak ada perbedaan antara INIT dan DEPLOYED. |
Semua pekerja memancarkan kode dukungan minimum dengan mantap untuk waktu memanggang. Aplikasi siap untuk pindah ke penyebaran Fase 2. |
DEPLOYED |
Semua pekerja telah dikerahkan dengan kode baru (Fase 1 selesai). Aplikasi ini mendukung format tabel tunggal tetapi belum mengaktifkannya. |
Penerapan fase 2 dimulai dengan |
PENDING |
Semua pekerja menjalankan kode baru. KCL memigrasikan data dari metrik pekerja dan tabel status koordinator ke dalam tabel sewa. |
Waktu pemanggangan default 24 jam berlalu setelah migrasi selesai. |
COMPLETE |
Migrasi selesai. KCL menggunakan tabel sewa khusus untuk semua membaca dan menulis. Metrik pekerja lama dan tabel status koordinator tidak lagi digunakan. |
Status terminal. Tidak ada transisi lebih lanjut yang terjadi. |
Untuk informasi rinci tentang setiap status, kondisi transisi, dan perilaku mesin status lengkap, lihat mesin status migrasi tabel tunggal KCL
catatan
Waktu pemanggangan default antara status PENDING dan COMPLETE adalah 24 jam, tetapi Anda dapat mengonfigurasinya hingga satu minggu. Selama periode ini, KCL menggunakan tabel sewa untuk semua membaca dan menulis tetapi tidak menghapus tabel lama. Anda harus secara manual menghapus metrik pekerja lama dan tabel status koordinator setelah Anda mengonfirmasi migrasi berhasil. KCL tidak menghapus tabel ini secara otomatis.
Pertimbangan rollback
Dukungan rollback tergantung pada saat ini: TableMigrationStatus
-
Selama Fase 1 (
TableMigrationStatussudahDEPLOYEDatau belum disetel): Anda dapat memutar kembali ke versi sebelumnya dengan aman. Kode baru berjalan dalam mode yang kompatibel ke belakang dan tidak ada data yang ditulis ke entri non-sewa di tabel sewa. -
Selama Fase 2 (
TableMigrationStatusadalahDEPLOYEDatauPENDING): Anda dapat memutar kembali ke Fase 1. Pekerja kembali menggunakan tabel lama (format multi-tabel) untuk metrik pekerja dan status koordinator. Migrasi dibatalkan. -
Setelah status LENGKAP: Rollback tidak didukung. KCL hanya menggunakan tabel sewa untuk semua entitas. Bahkan jika kode berputar kembali ke Fase 1, pekerja terus menggunakan tabel sewa untuk semua entitas dan konfigurasi diabaikan.
Awas
Setelah migrasi mencapai status LENGKAP, aplikasi beroperasi secara eksklusif dalam mode tabel tunggal. migrateAllEntitiesToLeaseTableKonfigurasi diabaikan, dan KCL tidak kembali menggunakan tabel terpisah. Pastikan waktu memanggang sebelum pindah ke COMPLETE sudah cukup, karena setelah itu bahkan rollback kode tidak beralih kembali ke beberapa tabel.
Praktik terbaik
Ikuti praktik terbaik ini saat Anda mengadopsi format tabel tunggal:
-
Setelah penerapan Fase 1, verifikasi bahwa entri status koordinator
TableMigration3.5mencapaiDEPLOYEDstatus. Pastikan tidak ada regresi sebelum melanjutkan ke Fase 2. -
Pantau entri status
TableMigration3.5koordinator untuk melacak kemajuan melalui status DEPLOYED, PENDING, dan COMPLETE.TableMigrationStatusStatus disimpan dalam tabel status koordinator sebagai entri terpisah (bukan dalam tabel sewa) sampai migrasi mencapai LENGKAP. -
Pastikan waktu memanggang sebelum pindah ke COMPLETE sudah cukup, karena setelah itu bahkan rollback kode tidak beralih kembali ke beberapa tabel. Aplikasi hanya berfungsi dalam mode tabel tunggal.
-
Setelah migrasi mencapai LENGKAP, hapus metrik pekerja lama dan tabel status koordinator secara manual. KCL tidak menghapus tabel ini secara otomatis—hanya berhenti menggunakannya.
-
Jika Anda telah mengonfigurasi
CoordinatorConfig.coordinatorStateTableConfigatauLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig, Anda dapat menghapus konfigurasi ini setelah migrasi selesai. Konfigurasi ini tidak digunakan lagi di KCL 3.5 dan yang lebih baru.
