Memantau basis data global Amazon Aurora - Amazon Aurora

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memantau basis data global Amazon Aurora

Ketika Anda membuat klaster DB Aurora yang membentuk basis data global Aurora Anda, Anda dapat memilih banyak pilihan yang memungkinkan Anda memantau performa DB klaster Anda. Opsi ini mencakup hal berikut:

  • Wawasan Performa Amazon RDS - Mengaktifkan skema performa di mesin basis data Aurora yang mendasari. Untuk mempelajari selengkapnya tentang Wawasan Performa dan basis data global Aurora, lihat Memantau basis data global Amazon Aurora dengan Wawasan Performa Amazon RDS.

  • Pemantauan yang ditingkatkan – Menghasilkan metrik untuk pemanfaatan proses atau thread pada CPU. Untuk mempelajari tentang pemantauan yang ditingkatkan, lihat Memantau metrik OS dengan Pemantauan yang Ditingkatkan.

  • Amazon CloudWatch Logs - Menerbitkan jenis log tertentu ke CloudWatch Log. Log kesalahan diterbitkan secara default, tetapi Anda dapat memilih log lain khusus untuk mesin basis data Aurora Anda.

    • Untuk klaster DB Aurora berbasis Aurora MySQL, Anda dapat mengekspor log audit, log umum, dan log kueri lambat.

    • Untuk klaster DB Aurora berbasis Aurora PostgreSQL, Anda dapat mengekspor log PostgreSQL.

  • Untuk basis data global berbasis Aurora MySQL, Anda dapat mengueri tabel information_schema tertentu untuk memeriksa status basis data global Aurora Anda dan instansnya. Untuk mempelajari caranya, lihat Memantau basis data global berbasis Aurora MySQL.

  • Untuk basis data global berbasis Aurora PostgreSQL, Anda dapat menggunakan fungsi-fungsi tertentu untuk memeriksa status basis data global Aurora Anda dan instansnya. Untuk mempelajari caranya, lihat Memantau basis data global berbasis Aurora PostgreSQL.

Tangkapan layar berikut menunjukkan beberapa pilihan yang tersedia pada tab Pemantauan klaster DB Aurora primer dalam basis data global Aurora.

Tab pemantauan: Memantau dropdown yang ditampilkan CloudWatch, Pemantauan yang disempurnakan, daftar proses OS, dan opsi Performance Insights.

Untuk informasi selengkapnya, lihat Memantau metrik di klaster Amazon Aurora.

Memantau basis data global Amazon Aurora dengan Wawasan Performa Amazon RDS

Anda dapat menggunakan Wawasan Performa Amazon RDS untuk basis data global Aurora Anda. Anda mengaktifkan fitur ini secara individual, untuk setiap klaster DB Aurora dalam basis data global Aurora Anda. Untuk melakukannya, pilih Aktifkan Wawasan Performa di bagian Konfigurasi tambahan pada halaman Buat basis data. Atau Anda dapat memodifikasi klaster DB Aurora Anda untuk menggunakan fitur ini setelah tersedia dan berjalan. Anda dapat mengaktifkan atau menonaktifkan Wawasan Performa untuk setiap klaster yang merupakan bagian dari basis data global Aurora Anda.

Pernyataan yang dibuat oleh Wawasan Performa berlaku untuk setiap klaster dalam global basis data. Saat Anda menambahkan sekunder baru AWS Region ke database global Aurora yang sudah menggunakan Performance Insights, pastikan Anda mengaktifkan Performance Insights di cluster yang baru ditambahkan. Klaster tersebut tidak mewarisi pengaturan Wawasan Performa dari basis data global yang sudah ada.

Anda dapat beralih Wilayah AWS saat melihat halaman Performance Insights untuk instance DB yang dilampirkan ke database global. Namun, Anda mungkin tidak melihat informasi kinerja segera setelah beralih Wilayah AWS. Meskipun instans DB mungkin memiliki nama yang identik di masing-masing AWS Region, URL Performance Insights terkait berbeda untuk setiap instans DB. Setelah beralih Wilayah AWS, pilih nama instans DB lagi di panel navigasi Performance Insights.

Untuk instans DB yang dikaitkan dengan global basis data, faktor yang memengaruhi performa mungkin berbeda di setiap AWS Region. Misalnya, instans DB di masing-masing AWS Region mungkin memiliki kapasitas yang berbeda.

Untuk mempelajari lebih lanjut tentang menggunakan Wawasan Performa, lihat Memantau muatan DB dengan Wawasan Performa di Amazon Aurora.

Memantau basis data global Aurora dengan Aliran Aktivitas Basis Data

Dengan menggunakan fitur Aliran Aktivitas Basis Data, Anda dapat memantau dan mengatur alarm untuk aktivitas audit di klaster DB di basis data global Anda. Anda memulai aliran aktivitas basis data pada setiap klaster DB secara terpisah. Setiap klaster mengirimkan data audit ke aliran Kinesis-nya sendiri dalam AWS Region-nya sendiri. Untuk informasi selengkapnya, lihat Memantau Amazon Aurora dengan Aliran Aktivitas Basis Data.

Memantau basis data global berbasis Aurora MySQL

Untuk melihat status basis data global berbasis Aurora MySQL, lakukan kueri pada tabel information_schema.aurora_global_db_status dan information_schema.aurora_global_db_instance_status.

catatan

Tabel information_schema.aurora_global_db_status dan information_schema.aurora_global_db_instance_status hanya tersedia dengan Aurora MySQL versi 3.04.0 dan basis data global yang lebih tinggi.

Memantau basis data global Aurora berbasis Aurora MySQL
  1. Buat koneksi ke titik akhir klaster primer basis data global yang menggunakan klien MySQL. Untuk informasi selengkapnya tentang cara membuat koneksi, lihat Menghubungkan ke Amazon Aurora Global Database.

  2. Lakukan kueri ke tabel information_schema.aurora_global_db_status dalam perintah mysql untuk membuat daftar volume primer dan sekunder. Kueri ini memunculkan waktu lag klaster DB sekunder basis data global, seperti pada contoh berikut.

    mysql> select * from information_schema.aurora_global_db_status;
    AWS_REGION | HIGHEST_LSN_WRITTEN | DURABILITY_LAG_IN_MILLISECONDS | RPO_LAG_IN_MILLISECONDS | LAST_LAG_CALCULATION_TIMESTAMP | OLDEST_READ_VIEW_TRX_ID -----------+---------------------+--------------------------------+------------------------+---------------------------------+------------------------ us-east-1 | 183537946 | 0 | 0 | 1970-01-01 00:00:00.000000 | 0 us-west-2 | 183537944 | 428 | 0 | 2023-02-18 01:26:41.925000 | 20806982 (2 rows)

    Output mencakup baris untuk setiap klaster DB basis data global yang berisi kolom berikut:

    • AWS_REGION— Di AWS Region mana cluster DB ini berada. Untuk daftar tabel Wilayah AWS berdasarkan mesin, lihatKetersediaan wilayah.

    • HIGHEST_LSN_WRITTEN – Log sequence number (LSN) tertinggi yang saat ini tertulis pada klaster DB ini.

      Nomor urutan log (LSN) adalah nomor urut unik yang mengidentifikasi catatan dalam log transaksi database. LSNs dipesan sedemikian rupa sehingga LSN yang lebih besar mewakili transaksi selanjutnya.

    • DURABILITY_LAG_IN_MILLISECONDS — Perbedaan nilai stempel waktu antara HIGHEST_LSN_WRITTEN di klaster DB sekunder dan HIGHEST_LSN_WRITTEN di klaster DB primer. Nilai ini selalu 0 pada klaster DB primer basis data global Aurora.

    • RPO_LAG_IN_MILLISECONDS – Lag sasaran titik pemulihan (RPO). Lag RPO adalah waktu yang dibutuhkan untuk COMMIT transaksi pengguna terbaru untuk disimpan di klaster DB sekunder setelah disimpan di klaster DB primer basis data global Aurora. Nilai ini selalu 0 pada klaster DB primer basis data global Aurora.

      Secara sederhana, metrik ini menghitung sasaran titik pemulihan untuk setiap klaster DB Aurora MySQL di basis data global Aurora, yaitu, berapa banyak data yang mungkin hilang jika ada pemadaman. Seperti halnya lag, RPO diukur dalam waktu.

    • LAST_LAG_CALCULATION_TIMESTAMP – Stempel waktu yang menentukan kapan nilai dihitung terakhir kali untuk DURABILITY_LAG_IN_MILLISECONDS dan RPO_LAG_IN_MILLISECONDS. Nilai waktu seperti 1970-01-01 00:00:00+00 berarti ini adalah klaster DB primer.

    • OLDEST_READ_VIEW_TRX_ID – ID transaksi terlama yang dapat dihapus oleh instans DB penulis.

  3. Lakukan kueri ke tabel information_schema.aurora_global_db_instance_status untuk membuat daftar semua instans DB sekunder baik untuk klaster DB primer maupun klaster DB sekunder.

    mysql> select * from information_schema.aurora_global_db_instance_status;
    SERVER_ID | SESSION_ID | AWS_REGION | DURABLE_LSN | HIGHEST_LSN_RECEIVED | OLDEST_READ_VIEW_TRX_ID | OLDEST_READ_VIEW_LSN | VISIBILITY_LAG_IN_MSEC ---------------------+--------------------------------------+------------+-------------+----------------------+-------------------------+----------------------+------------------------ ams-gdb-primary-i2 | MASTER_SESSION_ID | us-east-1 | 183537698 | 0 | 0 | 0 | 0 ams-gdb-secondary-i1 | cc43165b-bdc6-4651-abbf-4f74f08bf931 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 0 ams-gdb-secondary-i2 | 53303ff0-70b5-411f-bc86-28d7a53f8c19 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 677 ams-gdb-primary-i1 | 5af1e20f-43db-421f-9f0d-2b92774c7d02 | us-east-1 | 183537697 | 183537698 | 20806930 | 183537691 | 21 (4 rows)

    Output mencakup baris untuk setiap instans DB basis data global yang berisi kolom berikut:

    • SERVER_ID – Pengidentifikasi server untuk instans DB.

    • SESSION_ID – Pengidentifikasi unik untuk sesi saat ini. Nilai MASTER_SESSION_ID mengidentifikasi instans DB (primer) Penulis.

    • AWS_REGION— Di mana AWS Region instans DB ini ada di. Untuk daftar tabel Wilayah AWS berdasarkan mesin, lihatKetersediaan wilayah.

    • DURABLE_LSN – LSN yang dibuat durabel di dalam penyimpanan.

    • HIGHEST_LSN_RECEIVED — LSN tertinggi yang diterima oleh instans DB dari instans DB penulis.

    • OLDEST_READ_VIEW_TRX_ID – ID transaksi terlama yang dapat dihapus oleh instans DB penulis.

    • OLDEST_READ_VIEW_LSN – LSN terlama yang digunakan oleh instans DB untuk membaca dari penyimpanan.

    • VISIBILITY_LAG_IN_MSEC – Untuk pembaca di klaster DB primer, seberapa jauh instans DB ini tertinggal di belakang instans DB penulis dalam milidetik. Untuk pembaca di DB klaster sekunder, seberapa jauh DB instans ini tetap tertinggal di belakang volume sekunder dalam milidetik.

Untuk melihat perubahan nilai ini dari waktu ke waktu, pertimbangkan blok transaksi berikut di mana sisipan tabel memakan waktu satu jam.

mysql> BEGIN; mysql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; mysql> COMMIT;

Dalam beberapa kasus, mungkin terdapat pemutusan jaringan antara klaster DB primer dan klaster DB sekunder setelah pernyataan BEGIN. Jika ya, nilai DURABILITY_LAG_IN_MILLISECONDS klaster DB sekunder mulai meningkat. Pada akhir pernyataan INSERT, nilai DURABILITY_LAG_IN_MILLISECONDS adalah 1 jam. Namun, nilai RPO_LAG_IN_MILLISECONDS adalah 0 karena semua data pengguna yang di-commit antara klaster DB primer dan klaster DB sekunder masih sama. Segera setelah pernyataan COMMIT selesai, nilai RPO_LAG_IN_MILLISECONDS meningkat.

Memantau basis data global berbasis Aurora PostgreSQL

Untuk melihat status basis data global berbasis Aurora PostgreSQL, gunakan fungsi aurora_global_db_status dan aurora_global_db_instance_status.

catatan

Hanya Aurora PostgreSQL yang mendukung fungsi aurora_global_db_status dan aurora_global_db_instance_status.

Memantau basis data global Aurora berbasis Aurora PostgreSQL
  1. Buat koneksi ke titik akhir klaster primer basis data global yang menggunakan utilitas PostgreSQL seperti psql. Untuk informasi selengkapnya tentang cara membuat koneksi, lihat Menghubungkan ke Amazon Aurora Global Database.

  2. Gunakan fungsi aurora_global_db_status dalam perintah psql untuk mencantumkan volume primer dan sekunder. Ini menunjukkan waktu lag klaster DB sekunder global basis data.

    postgres=> select * from aurora_global_db_status();
    aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin ------------+---------------------+------------------------+-----------------+----------------------------+----------------+--------------- us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0 us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243 (2 rows)

    Output mencakup baris untuk setiap klaster DB basis data global yang berisi kolom berikut:

    • aws_region - Tempat cluster DB ini berada AWS Region . Untuk daftar tabel Wilayah AWS berdasarkan mesin, lihatKetersediaan wilayah.

    • highest_lsn_written – Log sequence number (LSN) tertinggi yang saat ini tertulis pada klaster DB ini.

      Nomor urutan log (LSN) adalah nomor urut unik yang mengidentifikasi catatan dalam log transaksi database. LSNs dipesan sedemikian rupa sehingga LSN yang lebih besar mewakili transaksi selanjutnya.

    • durability_lag_in_msec – Perbedaan stempel waktu antara log sequence number tertinggi pada klaster DB sekunder (highest_lsn_written) dan highest_lsn_written pada klaster DB primer.

    • rpo_lag_di_msec – Lag sasaran titik pemulihan (RPO). Lag ini adalah perbedaan waktu antara transaksi pengguna terbaru yang disimpan di DB klaster sekunder dan transaksi pengguna terbaru yang disimpan di DB klaster primer.

    • last_lag_calculation_time – Stempel waktu ketika nilai terakhir dihitung untuk durability_lag_in_msec dan rpo_lag_in_msec.

    • feedback_epoch – Masa yang digunakan klaster DB sekunder saat menghasilkan informasi hot standby.

      Hot standby adalah ketika klaster DB dapat terhubung dan mengueri saat server berada dalam mode pemulihan atau mode siaga. Umpan balik hot standby adalah informasi tentang klaster DB saat dalam status hot standby. Untuk informasi selengkapnya, lihat Hot standby di dokumentasi PostgreSQL.

    • feedback_xmin – ID transaksi aktif minimum (terlama) yang digunakan oleh klaster DB sekunder.

  3. Gunakan fungsi aurora_global_db_instance_status untuk membuat daftar semua instans DB sekunder baik untuk klaster DB primer maupun klaster DB sekunder.

    postgres=> select * from aurora_global_db_instance_status();
    server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec --------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------ apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | | apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10 apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017 (3 rows)

    Output mencakup baris untuk setiap instans DB basis data global yang berisi kolom berikut:

    • server_id – Pengidentifikasi server untuk instans DB.

    • session_id – Pengidentifikasi unik untuk sesi saat ini.

    • aws_region - Tempat instans DB ini berada AWS Region . Untuk daftar tabel Wilayah AWS berdasarkan mesin, lihatKetersediaan wilayah.

    • durable_lsn – LSN yang dibuat durabel di dalam penyimpanan.

    • highest_lsn_received — LSN tertinggi yang diterima oleh instans DB dari instans DB penulis.

    • feedback_epoch – Masa yang digunakan instans DB saat menghasilkan informasi hot standby.

      Hot standby adalah ketika instans DB dapat terhubung dan mengueri saat server berada dalam mode pemulihan atau mode siaga. Umpan balik hot standby adalah informasi tentang instans DB saat dalam status hot standby. Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL tentang Hot standby.

    • feedback_xmin – ID transaksi aktif minimum (terlama) yang digunakan oleh instans DB.

    • oldest_read_view_lsn – LSN terlama yang digunakan oleh instans DB untuk membaca dari penyimpanan.

    • visibility_lag_in_msec – Seberapa jauh instans DB ini tertinggal di belakang instans DB penulis.

Untuk melihat perubahan nilai ini dari waktu ke waktu, pertimbangkan blok transaksi berikut di mana sisipan tabel memakan waktu satu jam.

psql> BEGIN; psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; psql> COMMIT;

Dalam beberapa kasus, mungkin terdapat pemutusan jaringan antara klaster DB primer dan klaster DB sekunder setelah pernyataan BEGIN. Jika ya, nilai durability_lag_in_msec klaster DB sekunder mulai meningkat. Pada akhir pernyataan INSERT, nilai durability_lag_in_msec adalah 1 jam. Namun, nilai rpo_lag_in_msec adalah 0 karena semua data pengguna yang di-commit antara klaster DB primer dan klaster DB sekunder masih sama. Segera setelah pernyataan COMMIT selesai, nilai rpo_lag_in_msec akan meningkat.