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](https://aws.amazon.com/service-terms/). Untuk mempelajari lebih lanjut tentang harga untuk aliran CDC, lihat halaman harga [Aurora](https://aws.amazon.com/rds/aurora/dsql/pricing/) DSQL.
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](cdc-record-format.md) 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](#cdc-failure-reasons).
+ **`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](#cdc-failure-reasons) 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. `GetStream` `ResourceNotFoundException`
Hubungi `GetStream` untuk melihat status streaming kapan saja. Ketika aliran `IMPAIRED` atau`FAILED`, responsnya menyertakan `statusReason` objek dengan kode kesalahan dan stempel waktu. Untuk detail selengkapnya tentang bidang `GetStream` respons, lihat [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)di Referensi API Amazon Aurora DSQL.
## Memecahkan masalah aliran yang terganggu atau gagal
Ikuti langkah-langkah ini ketika aliran CDC menjadi terganggu atau gagal. Jika alirannya`FAILED`, Anda tidak dapat memulihkannya—hapus aliran, selesaikan masalah mendasar, dan buat yang baru.
1. **Dapatkan status streaming.** Panggil `GetStream` dan verifikasi `status` bidang. Jika statusnya`ACTIVE`, alirannya sehat.
```
aws dsql get-stream \
--cluster-identifier {{cluster-id}} \
--stream-identifier {{stream-id}} \
--region {{region}}
```
1. **Baca kode kesalahan.** Jika statusnya `IMPAIRED` atau`FAILED`, responsnya termasuk `statusReason` objek. `error`Bidang berisi kode kesalahan.
```
{
"status": "IMPAIRED",
"statusReason": {
"error": "KINESIS_THROUGHPUT_EXCEEDED",
"updatedAt": "2025-01-15T14:30:00Z"
}
}
```
1. **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 alirannya`FAILED`, 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](cdc-iam.md#cdc-iam-trust-policy). 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](cdc-iam.md#cdc-iam-permissions-policy). 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 [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)di Referensi API [Amazon Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_api_reference.html).
## Memulihkan aliran yang terganggu
Sebagian besar kesalahan pertama-tama mentransisikan aliran ke`IMPAIRED`. Aliran yang terganggu terus memproses catatan lain dan mencoba ulang catatan yang gagal secara otomatis. `FAILED`Streaming 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 ke`FAILED`. 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 ke`ACTIVE`. 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,, `IsImpaired``BehindSourceLag`, dan `PublishedBytes``PublishedRecords`, lihat. [CloudWatch metrik untuk aliran CDC](#cdc-cloudwatch-metrics) Untuk detail selengkapnya tentang bidang `GetStream` respons, lihat [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)di 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 dan`AWS/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, lihat[Metrik aliran CDC](cloudwatch-monitoring.md#cdc-stream-metrics).
| 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.IteratorAgeMilliseconds`di 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, dimensi`StreamName`) 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 `PublishedBytes`terhadap 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 `IsImpaired`untuk 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](#cdc-troubleshooting)
**Polling `GetStream`untuk status terperinci**
`IsImpaired`Metrik 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.error`Lapangan memberi tahu Anda apa yang salah. Pasangkan ini dengan langkah-langkah pemecahan masalah [Memecahkan masalah aliran yang terganggu atau gagal](#cdc-troubleshooting) untuk resolusi cepat.
**Gunakan dasbor untuk mengkorelasikan metrik**
Buat CloudWatch dasbor yang menunjukkan`IsImpaired`,`BehindSourceLag`,`PublishedRecords`,`PublishedBytes`, dan `GetRecords.IteratorAgeMilliseconds` berdampingan. Mengkorelasikan metrik ini membantu Anda membedakan antara masalah pipa CDC (naik`BehindSourceLag`) dan masalah pembacaan hilir (meningkat `IteratorAge` dengan stabil). `BehindSourceLag`