Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pemantauan aliran
penting
Fitur ini disediakan sebagai AWS Pratinjau dan dapat berubah sewaktu-waktu. Untuk informasi selengkapnya, lihat bagian 2, Beta dan Pratinjau, di Ketentuan AWS Layanan
Sebelum ketersediaan umum, kami akan menambahkan jenis operasi baru ("op": "u"untuk pembaruan) ke muatan aliran Anda. Untuk memastikan aplikasi Anda menangani perubahan ini tanpa modifikasi, perlakukan op nilai yang tidak dikenal sebagai peningkatan dengan menerapkan payload. after Lihat Memahami catatan CDC untuk detail.
Ketika Aurora DSQL menemukan kesalahan saat mengirimkan catatan CDC, aliran beralih ke status. IMPAIRED Aliran yang terganggu terus memproses dan mengirimkan catatan lainnya—Aurora DSQL hanya mencoba kembali catatan yang gagal. Aurora DSQL mengukur lag replikasi dari catatan tertua yang tidak terkirim, dan lag bertambah hingga Anda menyelesaikan masalah. Aurora DSQL mempertahankan perubahan yang tidak terkirim secara internal selama satu minggu.
Jika Anda menyelesaikan masalah mendasar dalam jendela ini, percobaan ulang berikutnya berhasil, status kesalahan dihapus, dan aliran beralih kembali ke. ACTIVE Perbaiki masalah eksternal (kebijakan IAM, AWS KMS kunci, kapasitas Amazon Kinesis, dan sebagainya) dan Aurora DSQL mencoba ulang secara otomatis.
Jika kelambatan replikasi melebihi ambang kegagalan, aliran bertransisi ke. FAILED
penting
Aliran yang gagal tidak dapat dipulihkan. Anda harus menghapus aliran yang gagal dan membuat yang baru.
Siklus hidup streaming
Aliran bertransisi melalui status berikut selama siklus hidupnya:
-
CREATING— Aurora DSQL sedang menyiapkan aliran. Aurora DSQL belum mengirimkan catatan CDC. -
ACTIVE— Aliran beroperasi dan mengirimkan catatan CDC ke target. -
IMPAIRED— Aliran telah mengalami masalah yang membutuhkan tindakan Anda. Aurora DSQL mencoba kembali catatan yang gagal dengan backoff eksponensial, meskipun catatan lain dapat terus memberikan. Aurora DSQL mengukur lag replikasi dari catatan tertua yang tidak terkirim, dan lag bertambah hingga Anda menyelesaikan masalah. Aurora DSQL buffer perubahan yang tidak terkirim secara internal selama satu minggu. Lihat Referensi kode kesalahan. -
FAILED— Aliran telah mengalami kesalahan persisten dan tidak lagi mengirimkan catatan CDC. Aliran yang gagal tidak dapat dipulihkan dan Anda harus menghapusnya. Lihat Referensi kode kesalahan kondisi yang menyebabkan aliran memasuki status ini. -
DELETING— Aurora DSQL menghapus sumber daya aliran. -
DELETED— Aurora DSQL telah menghapus aliran. Setelah penghapusan selesai, mengembalikan a.GetStreamResourceNotFoundException
Hubungi GetStream untuk melihat status streaming kapan saja. Ketika aliran IMPAIRED atauFAILED, responsnya menyertakan statusReason objek dengan kode kesalahan dan stempel waktu. Untuk detail selengkapnya tentang bidang GetStream respons, lihat GetStreamdi Referensi API Amazon Aurora DSQL.
Memecahkan masalah aliran yang terganggu atau gagal
Ikuti langkah-langkah ini ketika aliran CDC menjadi terganggu atau gagal. Jika alirannyaFAILED, Anda tidak dapat memulihkannya—hapus aliran, selesaikan masalah mendasar, dan buat yang baru.
-
Dapatkan status streaming. Panggil
GetStreamdan verifikasistatusbidang. Jika statusnyaACTIVE, alirannya sehat.aws dsql get-stream \ --cluster-identifiercluster-id\ --stream-identifierstream-id\ --regionregion -
Baca kode kesalahan. Jika statusnya
IMPAIREDatauFAILED, responsnya termasukstatusReasonobjek.errorBidang berisi kode kesalahan.{ "status": "IMPAIRED", "statusReason": { "error": "KINESIS_THROUGHPUT_EXCEEDED", "updatedAt": "2025-01-15T14:30:00Z" } } -
Ikuti remediasi. Jika alirannya
IMPAIRED, cari kode kesalahan di tabel berikut dan terapkan perbaikan yang disarankan. Aurora DSQL mencoba ulang secara otomatis setelah Anda menyelesaikan masalah mendasar. Jika alirannyaFAILED, hapus, selesaikan masalah, dan buat aliran baru.
Referensi kode kesalahan
Tabel berikut menjelaskan setiap kode kesalahan, penyebabnya, apakah aliran dapat pulih, dan langkah-langkah untuk mengatasinya.
| Kode kesalahan | Penyebab | Dapat dipulihkan? | Cara mengatasinya |
|---|---|---|---|
KINESIS_THROUGHPUT_EXCEEDED |
Aliran data Kinesis Anda melebihi batas throughputnya, atau operasi AWS KMS enkripsi yang dibatasi pada aliran data Kinesis, dan kelambatan replikasi telah bertambah. | Ya | Tingkatkan jumlah pecahan pada aliran data Kinesis Anda, atau beralih ke mode kapasitas sesuai permintaan. Jika aliran data Kinesis menggunakan kunci yang dikelola AWS KMS pelanggan, verifikasi bahwa kuota permintaan kunci cukup besar. Setelah Anda meningkatkan kapasitas, Aurora DSQL mencoba ulang secara otomatis. |
KINESIS_STREAM_NOT_FOUND |
Aliran data Kinesis target tidak ada lagi. | Tidak | Aliran transisi langsung keFAILED. Hapus aliran CDC dan buat yang baru menunjuk ke aliran data Kinesis yang valid. |
ROLE_ACCESS_DENIED |
Aurora DSQL tidak dapat mengasumsikan peran IAM yang ditentukan dalam definisi target. AWS STS AssumeRolePanggilan itu kembaliAccessDenied. |
Ya | Verifikasi kebijakan kepercayaan peran memungkinkan prinsipal layanan Aurora DSQL (dsql.amazonaws.com) untuk mengasumsikannya. Verifikasi aws:SourceAccount dan aws:SourceArn kondisi cocok dengan cluster Anda. Lihat perinciannya di Kebijakan kepercayaan peran layanan. Setelah Anda memperbaiki kebijakan kepercayaan, Aurora DSQL mencoba ulang secara otomatis. |
KINESIS_ACCESS_DENIED |
Peran yang diasumsikan tidak memiliki izin untuk menulis ke aliran data Kinesis. Kinesis kembali. AccessDeniedException |
Ya | Tambahkan kinesis:PutRecord dan kinesis:PutRecords izin ke kebijakan peran untuk aliran data Kinesis target Nama Sumber Daya Amazon (ARN). Setelah Anda memperbaiki kebijakan, Aurora DSQL mencoba ulang secara otomatis. |
KINESIS_KMS_ACCESS_DENIED |
Peran yang diasumsikan tidak memiliki izin untuk menggunakan AWS KMS kunci yang mengenkripsi aliran data Kinesis. Kesalahan ini mencakup penolakan AWS KMS akses dan status kunci yang tidak valid. | Ya | Verifikasi peran memiliki kms:GenerateDataKey izin pada AWS KMS
kunci yang digunakan aliran data Kinesis. Juga verifikasi bahwa AWS KMS kunci dalam status diaktifkan dan valid. Kunci ini adalah kunci enkripsi pada aliran data Kinesis, bukan kunci cluster. AWS KMS Lihat perinciannya di Kebijakan izin peran layanan. Setelah Anda memperbaiki izin atau status kunci, Aurora DSQL mencoba ulang secara otomatis. |
KINESIS_OVERSIZE_RECORD |
Catatan CDC melebihi ukuran rekaman maksimum yang dikonfigurasi pada aliran data Kinesis. | Ya | Tingkatkan MaxRecordSizeInKiB aliran data Kinesis ke 10240 (10 MiB). Anda dapat memperbarui pengaturan ini pada aliran data Kinesis yang ada tanpa menghapusnya. Setelah Anda meningkatkan batas, Aurora DSQL mencoba ulang rekaman besar secara otomatis dan transisi aliran kembali ke. ACTIVE |
CLUSTER_CMK_INACCESSIBLE |
Kunci yang dikelola AWS KMS pelanggan yang mengenkripsi cluster Aurora DSQL tidak dapat diakses. | Ya | Verifikasi kebijakan AWS KMS kunci dan status kunci. Re-enable atau mengembalikan akses ke kunci. Setelah kunci dapat diakses lagi, aliran beralih kembali keACTIVE. |
Tabel sebelumnya mencantumkan setiap StreamFailureErrorCode nilai. Untuk detail tentang bidang statusReason respons, lihat GetStreamdi Referensi API Amazon Aurora DSQL.
Memulihkan aliran yang terganggu
Sebagian besar kesalahan pertama-tama mentransisikan aliran keIMPAIRED. Aliran yang terganggu terus memproses catatan lain dan mencoba ulang catatan yang gagal secara otomatis. FAILEDStreaming tidak dapat dipulihkan — Anda harus menghapusnya dan membuat yang baru.
-
Untuk kesalahan yang dapat dipulihkan: perbaiki masalah eksternal (kebijakan IAM, kunci, kapasitas Kinesis AWS KMS , atau batas ukuran catatan Kinesis). Percobaan ulang berikutnya yang berhasil menghapus status kesalahan dan mentransisikan aliran kembali ke.
ACTIVE -
Untuk
KINESIS_STREAM_NOT_FOUND: transisi aliran langsung keFAILED. Hapus aliran yang gagal dan buat yang baru menunjuk ke aliran data Kinesis yang valid.
Untuk semua kode kesalahan lainnya, jika kelambatan replikasi melebihi ambang kegagalan sebelum Anda menyelesaikan masalah, aliran akan beralih dari IMPAIRED ke. FAILED Aliran yang gagal tidak dapat bertransisi kembali keACTIVE. Hapus aliran yang gagal, selesaikan masalah mendasar, dan buat yang baru.
Pemantauan kesehatan aliran
Gunakan CloudWatch metrik dan GetStream API untuk memantau kesehatan streaming. CloudWatchmetrik memberikan visibilitas berkelanjutan ke kinerja pipa CDC, dan GetStream menyediakan kode kesalahan spesifik ketika aliran terganggu atau gagal.
Untuk daftar lengkap metrik CDC, termasuk,, IsImpairedBehindSourceLag, dan PublishedBytesPublishedRecords, lihat. CloudWatch metrik untuk aliran CDC Untuk detail selengkapnya tentang bidang GetStream respons, lihat GetStreamdi Referensi API Amazon Aurora DSQL.
CloudWatch metrik untuk aliran CDC
Gunakan CloudWatch metrik berikut untuk memantau kesehatan dan throughput setiap aliran CDC. Aurora DSQL menerbitkan metrik ini di namespace dengan dimensi danAWS/AuroraDSQL. ClusterId StreamId Metrik terakhir adalah metrik Amazon Kinesis standar di AWS/Kinesis namespace yang mengukur lag pembacaan hilir.
catatan
Aurora DSQL juga menerbitkan StreamDPU metrik dan di AWS/AuroraDSQL namespace untuk BytesStreamed penggunaan dan pelacakan penagihan. Untuk deskripsi, lihatMetrik aliran CDC.
| Nama metrik | Statistik yang berguna | Deskripsi |
|---|---|---|
IsImpaired |
Maksimum | Menunjukkan apakah aliran terganggu. Nilainya adalah 1 ketika aliran dalam IMPAIRED keadaan, dan 0 ketika aliran sehat. Aurora DSQL memancarkan metrik ini secara terus menerus untuk setiap aliran aktif atau terganggu. Gunakan metrik ini untuk membuat CloudWatch alarm yang memberi tahu Anda saat aliran menjadi terganggu. |
BehindSourceLag |
Rata-rata | Penundaan, dalam milidetik, antara saat transaksi dilakukan di Aurora DSQL dan ketika sistem CDC memproses catatan yang dihasilkan. Nilai yang meningkat menunjukkan bahwa pipa CDC berada di belakang beban kerja tulis. |
PublishedBytes |
Jumlah | Total byte catatan CDC yang ditulis Aurora DSQL ke target selama periode tersebut. Gunakan metrik ini bersama dengan jumlah pecahan Kinesis Anda untuk menentukan apakah Anda telah menyediakan kapasitas tulis yang cukup. |
PublishedRecords |
Jumlah | Jumlah total catatan CDC yang ditulis Aurora DSQL ke target selama periode tersebut. Setiap perubahan baris yang berkomitmen menghasilkan satu catatan. |
GetRecords.IteratorAgeMilliseconds
(AWS/Kinesis) |
Rata-rata | Metrik Kinesis standar yang melaporkan usia rekaman terakhir yang dibaca dari aliran data Kinesis oleh aplikasi hilir Anda, dalam milidetik. Gunakan StreamName dimensi. Nilai yang meningkat menunjukkan bahwa aplikasi hilir Anda tidak dapat mengikuti laju di mana Aurora DSQL menulis catatan CDC ke Kinesis. |
Tab Pemantauan konsol Aurora DSQL menunjukkan nilai latensi end-to-end Rata-rata yang menggabungkan BehindSourceLag (latensi sumber CDC) dan (lag pembaca Kinesis). GetRecords.IteratorAgeMilliseconds Nilai gabungan ini mewakili total penundaan dari komit database ke pembacaan hilir.
Memantau praktik terbaik
Gunakan praktik berikut untuk mendeteksi dan menyelesaikan masalah pipeline CDC sebelum memengaruhi sistem hilir Anda.
Atur alarm BehindSourceLag
Buat CloudWatch alarm yang menyala saat BehindSourceLag melebihi ambang batas yang penting bagi beban kerja Anda. Misalnya, atur 60 detik untuk target latensi satu menit. Peningkatan berkelanjutan dalam metrik ini berarti pipa CDC tertinggal. Jika lag mencapai ambang kegagalan, aliran beralih ke FAILED. Menangkap tren memberi Anda waktu untuk meningkatkan kapasitas Kinesis atau menyelidiki kemacetan throughput sebelum aliran menurun.
Pantau GetRecords.IteratorAgeMillisecondsdi sisi Kinesis
Bahkan ketika Aurora DSQL mengirimkan catatan tepat waktu, aplikasi hilir Anda dapat tertinggal. Buat CloudWatch alarm aktif GetRecords.IteratorAgeMilliseconds (di AWS/Kinesis namespace, dimensiStreamName) untuk mendeteksi lag hilir secara independen. Jika metrik ini naik dan BehindSourceLag tetap datar, kemacetannya ada di aplikasi hilir Anda, bukan di Aurora DSQL.
Lacak PublishedBytesterhadap kapasitas pecahan Kinesis
Setiap pecahan Kinesis mendukung hingga 1 MiB per detik untuk penulisan. Bandingkan PublishedBytes Jumlah per menit dengan total kapasitas tulis pecahan Anda (jumlah pecahan × 60 MiB per menit). Jika penggunaan mendekati 80 persen, tambahkan pecahan atau beralih ke mode kapasitas sesuai permintaan sebelum pemicu pelambatan. KINESIS_THROUGHPUT_EXCEEDED
Alarm menyala IsImpaireduntuk deteksi kerusakan instan
Buat CloudWatch alarm yang menyala ketika IsImpaired Maksimum lebih besar dari atau sama dengan 1 untuk satu periode evaluasi. Ini memberi Anda sinyal langsung ketika aliran memasuki IMPAIRED status, tanpa melakukan polling API. Setelah alarm menyala, panggil GetStream untuk membaca statusReason.error lapangan dan ikuti langkah-langkah remediasi. Memecahkan masalah aliran yang terganggu atau gagal
Polling GetStreamuntuk status terperinci
IsImpairedMetrik memberi tahu Anda bahwa aliran terganggu, tetapi GetStream API menyediakan kode kesalahan dan stempel waktu tertentu. Polling GetStream pada jadwal (misalnya, setiap lima menit) atau sebagai respons terhadap IsImpaired alarm. statusReason.errorLapangan memberi tahu Anda apa yang salah. Pasangkan ini dengan langkah-langkah pemecahan masalah Memecahkan masalah aliran yang terganggu atau gagal untuk resolusi cepat.
Gunakan dasbor untuk mengkorelasikan metrik
Buat CloudWatch dasbor yang menunjukkanIsImpaired,BehindSourceLag,PublishedRecords,PublishedBytes, dan GetRecords.IteratorAgeMilliseconds berdampingan. Mengkorelasikan metrik ini membantu Anda membedakan antara masalah pipa CDC (naikBehindSourceLag) dan masalah pembacaan hilir (meningkat IteratorAge dengan stabil). BehindSourceLag