Pemecahan Masalah untuk Amazon RDS

Mode fokus

Pemecahan Masalah untuk Amazon RDS - Layanan Basis Data Relasional Amazon

Tidak dapat terhubung ke instans DB Masalah keamanan Memecahkan masalah status jaringan yang tidak kompatibel Mengatur ulang kata sandi pemilik instans DB Penghentian atau boot ulang instans DB Perubahan parameter tidak diberlakukan Instans DB kehabisan ruang penyimpanan Instans DB tidak cukup tersedia Masalah memori RDS yang dapat dikosongkan Masalah MySQL dan MariaDB Tidak dapat mengatur periode retensi cadangan menjadi 0

Gunakan bagian berikut untuk membantu memecahkan masalah yang Anda miliki dengan instans DB di Amazon RDS dan Amazon Aurora.

Topik

Tidak dapat terhubung ke instans DB Amazon RDS
Masalah keamanan Amazon RDS
Memecahkan masalah status jaringan yang tidak kompatibel
Mengatur ulang kata sandi pemilik instans DB
Penghentian atau boot ulang instans DB Amazon RDS
Perubahan parameter DB Amazon RDS tidak diberlakukan
Instans DB Amazon RDS kehabisan ruang penyimpanan
Instans DB Amazon RDS tidak cukup tersedia
Masalah memori yang dapat dikosongkan di Amazon RDS
Masalah MySQL dan MariaDB MySQL
Tidak dapat mengatur periode retensi cadangan menjadi 0

Untuk informasi tentang masalah debug menggunakan API Amazon RDS, lihat Pemecahan masalah aplikasi di Amazon RDS.

Tidak dapat terhubung ke instans DB Amazon RDS

Jika Anda tidak dapat terhubung ke instans DB, berikut adalah penyebab-penyebab umumnya:

Aturan masuk – Aturan akses yang diberlakukan oleh firewall lokal dan alamat IP yang diizinkan untuk mengakses instans DB mungkin tidak cocok. Kemungkinan besar masalahnya adalah aturan masuk dalam grup keamanan Anda.

Secara default, instans DB tidak mengizinkan akses. Akses diberikan melalui grup keamanan yang terkait dengan VPC yang mengizinkan lalu lintas masuk dan keluar dari instans DB. Jika perlu, tambahkan aturan masuk dan keluar untuk situasi khusus Anda ke grup keamanan. Anda dapat menentukan alamat IP, rentang alamat IP, atau grup keamanan VPC lainnya.

catatan
Saat menambahkan aturan masuk baru, Anda dapat memilih IP Saya untuk Sumber agar dapat mengizinkan akses ke instans DB dari alamat IP yang terdeteksi di browser.

Untuk informasi selengkapnya tentang menyiapkan grup keamanan, lihat Berikan akses ke instans DB Anda VPC dengan membuat grup keamanan.

catatan
Koneksi klien dari alamat IP di dalam rentang 169.254.0.0/16 tidak diizinkan. Rentang ini adalah Automatic Private IP Addressing Range (APIPA) yang digunakan untuk alamat tautan lokal.
Aksesibilitas publik – Untuk terhubung ke instans DB dari luar VPC, seperti menggunakan aplikasi klien, instans harus memiliki alamat IP publik yang ditetapkan untuk instans tersebut.

Agar instans dapat diakses oleh publik, ubah instans dan pilih Ya di bagian Aksesibilitas publik. Untuk informasi selengkapnya, lihat Menyembunyikan instans DB dalam VPC dari internet.
Port — Port yang Anda tentukan saat membuat instans DB tidak dapat digunakan untuk mengirim atau menerima komunikasi karena pembatasan firewall lokal Anda. Untuk menentukan apakah jaringan Anda memungkinkan port tertentu digunakan untuk komunikasi masuk dan keluar, hubungi administrator jaringan Anda.
Ketersediaan – Untuk instans DB yang baru dibuat, instans DB memiliki status creating hingga instans DB siap digunakan. Ketika statusnya berubah menjadi available, Anda dapat terhubung ke instans DB. Tergantung pada ukuran instans DB Anda, perlu waktu hingga 20 menit sebelum instans tersedia.
Gateway internet – Agar instans DB dapat diakses publik, subnet dalam grup subnet DB tersebut harus memiliki gateway internet.
Mengonfigurasi gateway internet untuk subnet
1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.
2. Di panel navigasi, pilih Basis Data lalu pilih instans DB.
3. Di tab Konektivitas & keamanan, tuliskan nilai ID VPC di VPC dan subnet ID di Subnet.
4. Buka konsol VPC Amazon di. https://console.aws.amazon.com/vpc/
5. Di panel navigasi, pilih Gateway Internet. Pastikan ada gateway internet yang dilampirkan ke VPC Anda. Atau, pilih Buat Gateway Internet untuk membuat gateway internet. Pilih gateway internet, lalu pilih Lampirkan ke VPC dan ikuti arahan untuk melampirkannya ke VPC Anda.
6. Di panel navigasi, pilih Subnet, lalu pilih subnet Anda.
7. Di tab Tabel Rute, pastikan ada rute dengan 0.0.0.0/0 sebagai tujuan dan gateway internet untuk VPC sebagai target.
  
  Jika Anda terhubung ke instans menggunakan IPv6 alamatnya, verifikasi bahwa ada rute untuk semua IPv6 lalu lintas (::/0) yang mengarah ke gateway internet. Jika tidak, lakukan tindakan berikut:
  1. Pilih ID tabel rute (rtb-xxxxxxxx) untuk menavigasi ke tabel rute.
  2. Di tab Rute, pilih Edit rute. Pilih Tambahkan rute, gunakan 0.0.0.0/0 sebagai tujuan, dan gateway internet sebagai target.
    
    Untuk IPv6, pilih Tambahkan rute, gunakan ::/0 sebagai tujuan dan gateway internet sebagai target.
  3. Pilih Simpan rute.
  Juga, jika Anda mencoba untuk terhubung ke IPv6 endpoint, pastikan bahwa rentang IPv6 alamat klien diotorisasi untuk terhubung ke instans DB.
Untuk informasi selengkapnya, lihat Menggunakan instans DB di VPC.

Untuk masalah koneksi khusus mesin, lihat topik berikut:

Menguji koneksi ke instans DB

Anda dapat menguji koneksi ke instans DB menggunakan alat Linux atau Microsoft Windows umum.

Dari terminal Linux atau Unix, Anda dapat menguji koneksi dengan memasukkan hal berikut. Ganti DB-instance-endpoint dengan titik akhir dan port dengan port instans DB Anda.


nc -zv DB-instance-endpoint port

Misalnya, hal berikut menunjukkan contoh perintah dan nilai kembali.


nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Pengguna Windows dapat menggunakan Telnet untuk menguji koneksi ke instans DB. Tindakan Telnet tidak didukung selain untuk menguji koneksi. Jika koneksi berhasil, tindakan tidak akan mengembalikan pesan. Jika koneksi gagal, Anda akan menerima pesan kesalahan seperti berikut.


C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed

Jika tindakan Telnet berhasil, artinya grup keamanan Anda dikonfigurasi dengan benar.

catatan

Amazon RDS tidak menerima lalu lintas Internet Control Message Protocol (ICMP), termasuk ping.

Memecahkan masalah autentikasi koneksi

Dalam beberapa kasus, Anda dapat terhubung ke instans DB tetapi mendapatkan kesalahan autentikasi. Dalam kasus ini, Anda mungkin ingin mengatur ulang kata sandi pengguna utama untuk instans DB. Anda dapat melakukan tindakan ini dengan mengubah instans RDS.

Untuk informasi selengkapnya tentang cara mengubah instans DB, lihat Memodifikasi instans Amazon RDS DB.

Masalah keamanan Amazon RDS

Untuk menghindari masalah keamanan, jangan pernah menggunakan alamat email pengguna Akun AWS root dan kata sandi Anda untuk akun pengguna. Praktik terbaik adalah menggunakan pengguna root Anda untuk membuat pengguna dan menetapkannya ke akun pengguna DB. Anda juga dapat menggunakan pengguna root Anda untuk membuat akun pengguna lain, jika perlu.

Untuk informasi tentang membuat pengguna, lihat Membuat pengguna IAM di Akun AWS. Untuk informasi tentang membuat pengguna AWS IAM Identity Center, lihat Mengelola identitas di Pusat Identitas IAM.

Pesan kesalahan “gagal mengambil atribut akun, fungsi konsol tertentu mungkin terganggu.”

Kesalahan ini dapat muncul karena beberapa alasan. Penyebabnya mungkin karena akun Anda kehilangan izin, atau akun Anda belum disiapkan dengan benar. Untuk akun baru, Anda mungkin belum menunggu akun hingga siap digunakan. Untuk akun lama, Anda mungkin tidak memiliki izin dalam kebijakan akses untuk melakukan tindakan tertentu, seperti membuat instans DB. Untuk memecahkan masalah ini, administrator perlu memberikan peran yang diperlukan ke akun Anda. Untuk informasi selengkapnya, lihat dokumentasi IAM.

Memecahkan masalah status jaringan yang tidak kompatibel

Status jaringan yang tidak kompatibel berarti basis datanya mungkin masih dapat diakses di tingkat basis data, tetapi Anda tidak dapat mengubah atau melakukan boot ulang pada basis data tersebut.

Penyebab

Status jaringan instans DB Anda yang tidak kompatibel dapat disebabkan oleh salah satu tindakan berikut:

Mengubah kelas instans DB.
Mengubah instans DB untuk menggunakan deployment klaster DB Multi-AZ.
Mengganti host karena acara pemeliharaan.
Meluncurkan instans DB pengganti.
Memulihkan dari pencadangan snapshot.
Memulai instans DB yang telah dihentikan.

Penyelesaian

Gunakan start-db-instance perintah

Untuk memperbaiki basis data yang berada dalam status jaringan yang tidak kompatibel, ikuti petunjuk ini:

Buka https://console.aws.amazon.com/rds/dan pilih Database dari panel navigasi.
Pilih instans DB yang berada dalam status jaringan yang tidak kompatibel dan catat pengidentifikasi instans DB, ID VPC, dan IDs subnet dari tab Konektivitas & Keamanan.
Gunakan AWS CLI untuk menjalankan start-db-instance perintah. Tentukan nilai --db-instance-identifier.

catatan
Menjalankan perintah ini ketika basis data Anda dalam mode yang tidak kompatibel dapat menyebabkan beberapa waktu henti.
Perintah start-db-instance tidak menyelesaikan masalah ini untuk instans DB RDS for SQL Server.

Status basis data Anda berubah menjadi Tersedia jika perintah berhasil dijalankan.

Jika basis data Anda dimulai ulang, instans DB mungkin menjalankan operasi terakhir yang dijalankan pada instans tersebut sebelum dipindahkan ke status jaringan yang tidak kompatibel. Tindakan ini mungkin memindahkan kembali instans ke status jaringan yang tidak kompatibel.

Jika perintah start-db-instance tidak berhasil atau instans berpindah kembali ke status jaringan yang tidak kompatibel, buka halaman Basis Data di konsol RDS dan pilih basis datanya. Arahkan ke bagian Log & peristiwa. Bagian Peristiwa terbaru menampilkan langkah-langkah penyelesaian lebih lanjut untuk diikuti. Pesan-pesan tersebut diklasifikasikan sebagai berikut:

PEMERIKSAAN SUMBER DAYA INTERNAL: Mungkin ada masalah dengan sumber daya internal Anda.
PEMERIKSAAN DNS: Periksa penyelesaian DNS dan nama host untuk VPC di konsol VPC.
Pemeriksaan ENI: antarmuka jaringan elastis (ENI) untuk basis data Anda mungkin tidak ada.
PEMERIKSAAN GATEWAY: Gateway internet untuk basis data Anda yang tersedia untuk umum tidak dilampirkan ke VPC.
PEMERIKSAAN IP: Tidak ada alamat IP gratis di subnet Anda.
PEMERIKSAAN GRUP KEAMANAN: Tidak ada grup keamanan yang dikaitkan dengan basis data Anda atau grup keamanan tidak valid.
PEMERIKSAAN SUBNET: Tidak ada subnet yang valid di grup subnet DB Anda atau ada masalah dengan subnet Anda.
PEMERIKSAAN VPC: VPC yang dikaitkan dengan basis data Anda tidak valid.

Lakukan point-in-time pemulihan

Memiliki cadangan (snapshot atau logis) merupakan praktik terbaik, jika basis data Anda memasuki status jaringan yang tidak kompatibel. Lihat Pengantar cadangan. Jika Anda mengaktifkan cadangan otomatis, maka hentikan sementara penulisan apa pun ke database dan lakukan pemulihan. point-in-time

catatan

Setelah suatu instans memasuki status jaringan yang tidak kompatibel, instans DB mungkin tidak dapat diakses untuk melakukan pencadangan logis.

Jika Anda tidak mengaktifkan pencadangan otomatis, buat instans DB baru. Kemudian, migrasikan data menggunakan AWS Database Migration Service (AWS DMS), atau dengan menggunakan alat pencadangan dan pemulihan.

Jika ini tidak menyelesaikan masalah, hubungi Dukungan untuk bantuan lebih lanjut.

Mengatur ulang kata sandi pemilik instans DB

Jika Anda terkunci dari instans DB, Anda dapat masuk sebagai pengguna utama. Kemudian, Anda dapat mengatur ulang kredensial untuk pengguna administratif atau peran lainnya. Jika Anda tidak dapat masuk sebagai pengguna utama, pemilik AWS akun dapat mengatur ulang kata sandi pengguna utama. Untuk detail tentang akun administratif atau peran yang mungkin perlu Anda atur ulang, lihat Hak akses akun pengguna master.

Anda dapat mengubah kata sandi instans DB dengan menggunakan konsol Amazon RDS, AWS CLI perintah modify-db-instance, atau dengan menggunakan operasi Modify DBInstance API. Untuk informasi selengkapnya tentang cara mengubah instans DB, lihat Memodifikasi instans Amazon RDS DB.

Penghentian atau boot ulang instans DB Amazon RDS

Penghentian instans DB dapat terjadi ketika instans DB di-boot ulang. Penghentian ini juga dapat terjadi saat instans DB diubah menjadi status yang mencegah akses ke instans tersebut, dan saat basis data di-boot ulang. Boot ulang dapat terjadi saat Anda melakukan boot ulang manual pada instans DB Anda. Boot ulang juga dapat terjadi saat Anda mengubah pengaturan instans DB yang memerlukan boot ulang sebelum dapat diberlakukan.

Boot ulang instans DB terjadi saat Anda mengubah pengaturan yang memerlukan boot ulang, atau ketika Anda secara manual menyebabkan boot ulang. Boot ulang dapat segera terjadi jika Anda mengubah pengaturan dan meminta perubahan segera diberlakukan. Atau, boot ulang dapat terjadi selama jendela pemeliharaan instans DB.

Boot ulang instans DB segera terjadi ketika salah satu hal berikut terjadi:

Anda mengubah periode retensi pencadangan untuk instans DB dari 0 ke nilai selain nol atau dari nilai selain nol ke 0. Anda mengatur Terapkan Segera ke true.
Anda mengubah kelas instans DB, dan Terapkan Segera diatur menjadi true.
Anda mengubah jenis penyimpanan dari Magnetis (Standar) ke Tujuan Umum (SSD) atau IOPS yang Tersedia (SSD), atau dari IOPS yang Tersedia (SSD) atau Tujuan Umum (SSD) ke Magnetis (Standar).

Boot ulang instans DB terjadi selama jendela pemeliharaan saat salah satu dari hal berikut terjadi:

Anda mengubah periode retensi pencadangan untuk instans DB dari 0 ke nilai selain nol atau dari nilai selain nol ke 0, dan Terapkan Segera diatur ke false.
Anda mengubah kelas instans DB, dan Terapkan Segera diatur menjadi false.

Ketika Anda mengubah parameter statis dalam grup parameter DB, perubahan tersebut tidak diberlakukan hingga instans DB yang dikaitkan dengan grup parameter di-boot ulang. Perubahan ini memerlukan boot ulang manual. Instans DB tidak di-boot ulang secara otomatis selama jendela pemeliharaan.

Untuk melihat tabel yang menunjukkan tindakan instans DB dan dampak dari pengaturan nilai Terapkan Segera, lihat Memodifikasi instans Amazon RDS DB.

Perubahan parameter DB Amazon RDS tidak diberlakukan

Dalam beberapa kasus, Anda mungkin mengubah parameter dalam grup parameter DB, tetapi tidak melihat perubahan akan diberlakukan. Jika demikian, Anda mungkin perlu melakukan boot ulang instans DB yang dikaitkan dengan grup parameter DB. Saat Anda mengubah parameter dinamis, perubahan akan langsung diberlakukan. Ketika Anda mengubah parameter statis, perubahan tersebut tidak diberlakukan hingga Anda melakukan boot ulang instans DB yang dikaitkan dengan grup parameter.

Anda dapat melakukan boot ulang pada instans DB menggunakan konsol RDS. Atau, Anda dapat secara eksplisit memanggil operasi API RebootDBInstance. Anda dapat mem-boot ulang tanpa failover jika instans DB ada dalam deployment Multi-AZ. Persyaratan untuk melakukan boot ulang pada instans DB terkait setelah perubahan parameter statis membantu memitigasi risiko kesalahan konfigurasi parameter yang memengaruhi panggilan API. Contohnya adalah memanggil ModifyDBInstance untuk mengubah kelas instans DB. Untuk informasi selengkapnya, lihat Memodifikasi parameter dalam grup parameter DB di Amazon RDS Aurora.

Instans DB Amazon RDS kehabisan ruang penyimpanan

Jika instans DB Anda kehabisan ruang penyimpanan, instans tersebut mungkin tidak lagi tersedia. Kami sangat menyarankan agar Anda terus memantau FreeStorageSpace metrik yang diterbitkan CloudWatch untuk memastikan bahwa instans DB Anda memiliki ruang penyimpanan gratis yang cukup.

Jika instans basis data Anda kehabisan ruang penyimpanan, statusnya berubah menjadi storage-full. Sebagai contoh, panggilan ke operasi API DescribeDBInstances untuk instans DB yang telah menghabiskan output penyimpanannya berikut.


aws rds describe-db-instances --db-instance-identifier mydbinstance

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Untuk memulihkan dari skenario ini, tambahkan lebih banyak ruang penyimpanan ke instans Anda menggunakan operasi ModifyDBInstance API atau AWS CLI perintah berikut.

Untuk Linux, macOS, atau Unix:


aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --allocated-storage 60 \
    --apply-immediately

Untuk Windows:


aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --allocated-storage 60 ^
    --apply-immediately


DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Kini, saat Anda menggambarkan instans DB, Anda melihat bahwa instans DB Anda memiliki status modifying, yang menunjukkan bahwa penyimpanan sedang diskalakan.


aws rds describe-db-instances --db-instance-identifier mydbinstance


DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
modifying  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com
3306  us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Setelah penskalaan penyimpanan selesai, status instans DB Anda berubah menjadi available.


aws rds describe-db-instances --db-instance-identifier mydbinstance


DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  60  sa
available  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Anda dapat menerima notifikasi ketika ruang penyimpanan Anda habis menggunakan operasi DescribeEvents. Misalnya, dalam skenario ini, jika Anda membuat panggilan DescribeEvents setelah operasi ini, Anda akan melihat output berikut.


aws rds describe-events --source-type db-instance --source-identifier mydbinstance


2009-12-22T23:44:14.374Z  mydbinstance  Allocated storage has been exhausted db-instance
2009-12-23T00:14:02.737Z  mydbinstance  Applying modification to allocated storage db-instance
2009-12-23T00:31:54.764Z  mydbinstance  Finished applying modification to allocated storage

Instans DB Amazon RDS tidak cukup tersedia

Kesalahan InsufficientDBInstanceCapacity dapat muncul saat Anda mencoba membuat, memulai, atau mengubah instans DB. Kesalahan ini juga dapat muncul saat Anda mencoba memulihkan instans DB dari snapshot DB. Saat kesalahan ini muncul, satu penyebab umumnya adalah kelas instans DB tertentu tidak tersedia di Zona Ketersediaan yang diminta. Anda dapat mencoba salah satu hal berikut untuk memecahkan masalahnya:

Coba kembali permintaan dengan kelas instans DB yang berbeda.
Coba kembali permintaan dengan Zona Ketersediaan yang berbeda.
Coba kembali permintaan tanpa menentukan Zona Ketersediaan eksplisit.

Untuk informasi tentang pemecahan masalah kapasitas instans untuk Amazon EC2, lihat Kapasitas instans tidak mencukupi di EC2 Panduan Pengguna Amazon.

Untuk informasi tentang cara mengubah instans DB, lihat Memodifikasi instans Amazon RDS DB.

Masalah memori yang dapat dikosongkan di Amazon RDS

Memori yang dikosongkan adalah total Random Access Memory (RAM) pada instans DB yang dapat dibuat tersedia untuk mesin basis data. Ini adalah jumlah dari memori sistem operasi (OS) yang kosong serta memori cache halaman dan buffer yang tersedia. Mesin basis data menggunakan sebagian besar memori pada host, tetapi proses OS juga menggunakan sebagian RAM. Memori yang saat ini dialokasikan ke mesin basis data atau digunakan oleh proses OS tidak termasuk dalam memori yang dapat dikosongkan. Ketika mesin basis data kehabisan memori, instans DB dapat menggunakan ruang sementara yang biasanya digunakan untuk buffering dan caching. Seperti disebutkan sebelumnya, ruang sementara ini termasuk dalam memori yang dapat dikosongkan.

Anda menggunakan FreeableMemory metrik di Amazon CloudWatch untuk memantau memori yang dapat dibebaskan. Untuk informasi selengkapnya, lihat Alat pemantauan untuk Amazon RDS Amazon.

Jika instans DB Anda secara konsisten kehabisan memori yang dapat dikosongkan atau menggunakan ruang swap, pertimbangkan untuk meningkatkan ke kelas instans DB yang lebih besar. Untuk informasi selengkapnya, lihat DB.

Anda juga dapat mengubah pengaturan memori. Misalnya, pada RDS for MySQL, Anda dapat menyesuaikan ukuran parameter innodb_buffer_pool_size. Parameter ini diatur secara default ke 75 persen memori fisik. Untuk tips pemecahan masalah MySQL lainnya, lihat Bagaimana cara memecahkan masalah memori yang dapat dikosongkan rendah di basis data Amazon RDS for MySQL?

Masalah MySQL dan MariaDB MySQL

Anda dapat mendiagnosis dan memperbaiki masalah dengan instans DB MySQL dan MariaDB.

Topik

Koneksi maksimum MySQL dan MariaDB
Mendiagnosis dan menyelesaikan status parameter yang tidak kompatibel untuk batas memori
Mendiagnosis dan mengatasi jeda di antara replika baca
Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB
Membuat pemicu dengan log biner aktif memerlukan hak istimewa SUPER
Mendiagnosis dan menyelesaikan kegagalan pemulihan point-in-time
Kesalahan replikasi terhenti
Pembuatan replika baca gagal atau replikasi rusak dengan kesalahan fatal 1236
Replikasi replika baca gagal menginisialisasi struktur metadata

Koneksi maksimum MySQL dan MariaDB

Jumlah koneksi maksimum yang diperbolehkan untuk instans DB RDS for MySQL atau RDS for MariaDB didasarkan pada jumlah memori yang tersedia untuk kelas instans DB. Kelas instans DB dengan memori lebih besar akan menghasilkan tersedianya koneksi yang lebih besar. Untuk informasi selengkapnya tentang kelas instans DB, lihat DB.

Batas koneksi untuk instans DB diatur secara default ke kelas instans maksimum DB. Anda dapat membatasi jumlah koneksi bersamaan dengan nilai berapa pun hingga jumlah maksimum koneksi yang diperbolehkan. Gunakan parameter max_connections dalam grup parameter untuk instans DB. Untuk informasi lebih lanjut, lihat Jumlah maksimum koneksi basis data dan Grup parameter untuk RDS.

Anda dapat mengambil jumlah maksimum koneksi yang diperbolehkan untuk instans DB MySQL atau MariaDB dengan menjalankan kueri berikut.


SELECT @@max_connections;

Anda dapat mengambil jumlah maksimum koneksi yang aktif untuk instans DB MySQL atau MariaDB dengan menjalankan kueri berikut.


SHOW STATUS WHERE `variable_name` = 'Threads_connected';

Mendiagnosis dan menyelesaikan status parameter yang tidak kompatibel untuk batas memori

Instans DB MariaDB atau MySQL dapat ditempatkan dalam status incompatible-parameters untuk suatu batas memori saat kondisi berikut terpenuhi:

Instans DB dimulai ulang setidaknya tiga kali dalam satu jam atau setidaknya lima kali dalam satu hari jika status instans DB Tersedia.
Upaya untuk memulai ulang instans DB gagal karena tindakan pemeliharaan atau proses pemantauan tidak dapat memulai ulang instans DB.
Penggunaan memori potensial instans DB melebihi 1,2 kali memori yang dialokasikan ke kelas instans DB.

Ketika instans DB dimulai ulang untuk ketiga kalinya dalam satu jam atau untuk kali kelima dalam satu hari, instans tersebut melakukan pemeriksaan penggunaan memori. Pemeriksaan ini membuat perhitungan penggunaan memori potensial instans DB. Nilai yang ditunjukkan oleh perhitungan tersebut adalah jumlah dari nilai berikut:

Nilai 1 – Jumlah parameter berikut:
- innodb_additional_mem_pool_size
- innodb_buffer_pool_size
  
  Anda dapat memodifikasi nilai untukinnodb_buffer_pool_size. Namun, nilainya tidak akan selalu cocok dengan apa yang Anda masukkan. Ketidakcocokan ini terjadi karena beberapa alasan. Pertama, jika instance DB adalah instance micro DB, maka kita mengganti nilai default dan mengaturnya ke 256 MB. Untuk informasi selengkapnya, lihat Mengesampingkan innodb_buffer_pool_size.
  
  Kedua, kami memastikan bahwa 500 MB memori dicadangkan pada instans DB untuk manajer host, mesin, sistem operasi, dan kernel.
  
  Terakhir, kami mengoptimalkan innodb_buffer_pool_size dengan membaginya menjadi beberapa unit. Manajer tuan rumah membulatkan ke kelipatan terdekat dari unit-unit tersebut. Satuan dihitung dengan mengalikan innodb_buffer_pool_chunk_size dengan. innodb_buffer_pool_instances Untuk informasi selengkapnya, lihat Mengonfigurasi Ukuran Kolam Buffer InnoDB dalam dokumentasi MySQL.
  
  Default untuk innodb_buffer_pool_instances adalah 8, kecuali innodb_buffer_pool_size kurang dari 1 GB. Jika innodb_buffer_pool_size kurang dari 1 GB, maka default untuk innodb_buffer_pool_instances adalah 1. innodb_buffer_pool_chunk_sizeDefaultnya adalah 128 MB.
- innodb_log_buffer_size
- key_buffer_size
- query_cache_size (Hanya MySQL versi 5.7)
- tmp_table_size
Nilai 2 – Parameter max_connections dikalikan dengan jumlah parameter berikut:
- binlog_cache_size
- join_buffer_size
- read_buffer_size
- read_rnd_buffer_size
- sort_buffer_size
- thread_stack
Nilai 3 – Jika parameter performance_schema diaktifkan, kalikan parameter max_connections dengan 429498.

Jika parameter performance_schema dinonaktifkan, nilai ini adalah nol.

Jadi, nilai yang ditunjukkan oleh perhitungan adalah sebagai berikut:

Value 1 + Value 2 + Value 3

Ketika nilai ini melebihi 1,2 kali memori yang dialokasikan ke kelas instans DB yang digunakan oleh instans DB, instans DB ditempatkan dalam status incompatible-parameters. Untuk informasi tentang memori yang dialokasikan ke kelas instans DB, lihat Spesifikasi perangkat keras kelas instans DB .

Penghitungan tersebut mengalikan nilai parameter max_connections dengan jumlah beberapa parameter. Jika parameter max_connections diatur ke nilai yang besar, parameter ini dapat menyebabkan pemeriksaan menunjukkan nilai yang sangat tinggi untuk penggunaan memori potensial dari instans DB. Dalam kasus ini, pertimbangkan untuk menurunkan nilai parameter max_connections.

Untuk mengatasi masalah, selesaikan langkah-langkah berikut:

Sesuaikan parameter memori dalam grup parameter DB yang dikaitkan dengan instans DB. Lakukan sedemikian rupa sehingga penggunaan memori potensial lebih rendah dari 1,2 kali memori yang dialokasikan ke kelas instans DB.

Untuk informasi tentang mengatur parameter, lihat Memodifikasi parameter dalam grup parameter DB di Amazon RDS Aurora.
Mulai ulang instans DB.

Untuk informasi tentang mengatur parameter, lihat Memulai instans Amazon RDS DB yang sebelumnya dihentikan.

Mendiagnosis dan mengatasi jeda di antara replika baca

Setelah Anda membuat replika baca MySQL atau MariaDB dan replikanya tersedia, Amazon RDS pertama-tama mereplikasi perubahan yang dibuat ke instans DB sumber sejak operasi replika baca dimulai. Selama fase ini, waktu jeda replikasi untuk replika baca lebih besar dari 0. Anda dapat memantau jeda waktu ini di Amazon CloudWatch dengan melihat ReplicaLagmetrik Amazon RDS.

Metrik ReplicaLag melaporkan nilai kolom Seconds_Behind_Master dari perintah SHOW REPLICA STATUS MariaDB atau MySQL. Untuk informasi selengkapnya, lihat SHOW REPLICA STATUS Statement di dokumentasi MySQL.

Saat metrik ReplicaLag mencapai 0, replika telah menyamai instans DB sumber. Jika metrik ReplicaLag menunjukkan -1, replikasi mungkin tidak aktif. Untuk memecahkan masalah kesalahan replikasi, lihat Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB. Nilai ReplicaLag sebesar -1 juga dapat berarti bahwa nilai Seconds_Behind_Master tidak dapat ditentukan atau NULL.

catatan

Versi sebelumnya dari MariaDB menggunakan SHOW SLAVE STATUS, bukan SHOW REPLICA STATUS. Jika Anda menggunakan versi MariaDB yang lebih rendah dari 10.5, maka gunakan. SHOW SLAVE STATUS

Metrik ReplicaLag menunjukkan -1 saat penghentian jaringan atau saat patch diterapkan selama jendela pemeliharaan. Dalam kasus ini, tunggu konektivitas jaringan hingga dipulihkan atau tunggu jendela pemeliharaan berakhir sebelum Anda memeriksa metrik ReplicaLag lagi.

Teknologi replikasi baca MySQL dan MariaDB bersifat asinkron. Oleh karena itu, Anda dapat sesekali mengharapkan peningkatan bagi metrik BinLogDiskUsage pada instans DB sumber dan bagi metrik ReplicaLag pada replika baca. Misalnya, pertimbangkan situasi saat volume operasi tulis tinggi ke instans DB sumber terjadi secara paralel. Pada saat yang sama, operasi tulis ke replika baca akan diserialkan menggunakan thread I/O tunggal. Situasi tersebut dapat menyebabkan jeda antara instans sumber dan replika baca.

Untuk informasi selengkapnya tentang replika baca dan MySQL, lihat Replication implementation details dalam dokumentasi MySQL. Untuk informasi selengkapnya tentang replika baca dan MariaDB, lihat Replication overview di dokumentasi MariaDB.

Anda dapat mengurangi lag antara pembaruan ke instans DB sumber dan pembaruan berikutnya ke replika baca dengan melakukan hal berikut:

Atur kelas instans DB dari replika baca agar memiliki ukuran penyimpanan yang sebanding dengan ukuran dari instans DB sumber.
Pastikan kompatibilitas pengaturan parameter di grup parameter DB yang digunakan oleh instans DB sumber dan replika baca. Untuk informasi selengkapnya dan contoh, lihat diskusi tentang parameter max_allowed_packet di bagian berikutnya.
Nonaktifkan cache kueri. Untuk tabel yang sering diubah, menggunakan cache kueri dapat meningkatkan lag replika karena cache terkunci dan sering disegarkan. Dalam kasus ini, Anda mungkin akan melihat lebih sedikit lag replika jika menonaktifkan cache kueri. Anda dapat menonaktifkan cache kueri dengan mengatur query_cache_type parameter ke 0 dalam grup parameter DB untuk instans DB. Untuk informasi selengkapnya tentang cache kueri, lihat Konfigurasi cache kueri.
Hangatkan kumpulan buffer pada replika baca untuk InnoDB for MySQL atau MariaDB. Misalnya, anggaplah Anda memiliki sejumlah kecil tabel yang sering diperbarui dan Anda menggunakan skema tabel InnoDB atau XtraDB. Dalam kasus ini, dump tabel tersebut pada replika baca. Dengan melakukan hal ini, Anda akan menyebabkan mesin basis data memindai barisan tabel tersebut dari disk, lalu menyimpannya di dalam kumpulan buffer. Pendekatan ini dapat mengurangi jeda replika. Berikut ini menunjukkan contoh.

Untuk Linux, macOS, atau Unix:
```
PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null 
```
Untuk Windows:
```
PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null 
```

Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB

Amazon RDS memantau status replikasi replika baca Anda. RDS memperbarui bidang Status Replikasi instans replika baca menjadi Error jika replikasi berhenti karena alasan apa pun. Anda dapat meninjau detail kesalahan terkait yang dilontarkan oleh mesin MySQL atau MariaDB dengan melihat kolom Kesalahan Replikasi. Peristiwa yang menunjukkan status replika baca juga dihasilkan, termasuk RDS-EVENT-0045, RDS-EVENT-0046, dan RDS-EVENT-0057. Untuk informasi selengkapnya tentang peristiwa dan berlangganan peristiwa, lihat Bekerja dengan pemberitahuan RDS acara Amazon. Jika pesan kesalahan MySQL muncul, periksa kesalahannya di MySQL error message documentation. Jika pesan kesalahan MariaDB muncul, periksa kesalahannya di MySQL error message documentation.

Situasi umum yang dapat menyebabkan kesalahan replikasi mencakup hal-hal berikut:

Nilai parameter max_allowed_packet untuk replika baca lebih kecil dari parameter max_allowed_packet untuk instans DB sumber.

Parameter max_allowed_packet adalah parameter kustom yang dapat Anda atur di grup parameter DB. Parameter max_allowed_packet digunakan untuk menentukan ukuran maksimum bahasa manipulasi data (DML) yang dapat dijalankan di basis data. Dalam beberapa kasus, nilai max_allowed_packet untuk instans DB sumber mungkin lebih besar dari nilai max_allowed_packet untuk replika baca. Jika demikian, proses replikasi dapat menimbulkan kesalahan dan menghentikan replikasi. Kesalahan yang paling umum adalah packet bigger than 'max_allowed_packet' bytes. Anda dapat memperbaiki kesalahan ini dengan mengatur agar replika sumber dan baca menggunakan grup parameter DB yang sama dengan nilai parameter max_allowed_packet.
Menulis ke tabel di replika baca. Jika Anda membuat indeks pada replika baca, parameter read_only harus diatur ke 0 untuk membuat indeks. Jika Anda menulis ke tabel di replika baca, tindakan ini dapat memecah replikasi.
Gunakan mesin penyimpanan nontransaksional seperti MyISAM. Replika baca membutuhkan mesin penyimpanan transaksional. Replikasi hanya didukung untuk mesin penyimpanan berikut: InnoDB for MySQL atau MariaDB.

Anda dapat mengonversi tabel MyISAM ke InnoDB dengan perintah berikut:

alter table <schema>.<table_name> engine=innodb;
Gunakan kueri nondeterministik yang tidak aman seperti SYSDATE(). Untuk informasi selengkapnya, lihat Determination of safe and unsafe statements in binary logging di dokumentasi MySQL.

Langkah-langkah berikut dapat membantu mengatasi kesalahan replikasi Anda:

Jika Anda mengalami kesalahan logis dan dapat melewatkan kesalahan tersebut dengan aman, ikuti langkah-langkah yang dijelaskan dalam Melewatkan kesalahan replikasi saat ini untuk My RDS SQL. Instans DB MySQL atau MariaDB Anda harus menjalankan versi yang mencakup prosedur mysql_rds_skip_repl_error. Untuk informasi selengkapnya, lihat mysql.rds_skip_repl_error.
Jika Anda mengalami masalah posisi log biner (binlog), Anda dapat mengubah posisi replay replika dengan perintah or.
Anda mungkin mengalami masalah kinerja sementara karena beban DMLnya tinggi. Jika demikian, Anda dapat mengatur parameter innodb_flush_log_at_trx_commit ke 2 di grup parameter DB pada replika baca. Dengan melakukan hal ini, Anda dapat membantu replika baca mengejar, meskipun tindakan ini akan mengurangi atomisitas, konsistensi, isolasi, dan daya tahan (ACID) untuk sementara.
Anda dapat menghapus replika baca dan membuat instans menggunakan pengidentifikasi instans DB yang sama. Jika Anda melakukannya, titik akhir tetap sama dengan replika baca lama Anda.

Jika kesalahan replikasi diperbaiki, Status Replikasi berubah menjadi mereplikasi. Untuk informasi selengkapnya, lihat Memecahkan masalah replika SQL baca saya.

Membuat pemicu dengan log biner aktif memerlukan hak istimewa SUPER

Saat mencoba membuat pemicu di instans DB RDS for MySQL atau RDS for MariaDB, Anda mungkin menerima kesalahan berikut.


"You do not have the SUPER privilege and binary logging is enabled"

Untuk menggunakan pemicu saat pencatatan log biner diaktifkan memerlukan hak istimewa SUPER, yang dibatasi untuk instans DB RDS for MySQL dan RDS for MariaDB. Anda dapat membuat pemicu saat log biner diaktifkan tanpa hak istimewa SUPER dengan mengatur parameter log_bin_trust_function_creators ke true. Untuk mengatur log_bin_trust_function_creators menjadi true, buat grup parameter DB baru atau ubah grup parameter DB yang sudah ada.

Anda dapat membuat grup parameter DB baru sehingga Anda dapat membuat pemicu di instans DB RDS for MySQL atau RDS for MariaDB dengan log biner yang aktif. Untuk melakukannya, gunakan perintah CLI berikut. Untuk mengubah grup parameter yang ada, mulailah dengan langkah 2.

Membuat grup parameter baru untuk mengizinkan pemicu dengan log biner yang aktif menggunakan CLI

Buat grup parameter baru.

Untuk Linux, macOS, atau Unix:


aws rds create-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --db-parameter-group-family mysql8.0 \
    --description "parameter group allowing triggers"

Untuk Windows:


aws rds create-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --db-parameter-group-family mysql8.0 ^
    --description "parameter group allowing triggers"

Ubah grup parameter DB untuk mengizinkan pemicu.

Untuk Linux, macOS, atau Unix:


aws rds modify-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

Untuk Windows:


aws rds modify-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

Ubah instans DB Anda untuk menggunakan grup parameter DB yang baru.

Untuk Linux, macOS, atau Unix:


aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --db-parameter-group-name allow-triggers \
    --apply-immediately

Untuk Windows:


aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --db-parameter-group-name allow-triggers ^
    --apply-immediately

Agar perubahan diberlakukan, lakukan boot ulang pada instans DB secara manual.
```
aws rds reboot-db-instance --db-instance-identifier mydbinstance
```

Mendiagnosis dan menyelesaikan kegagalan pemulihan point-in-time

Memulihkan instans DB yang mencakup tabel sementara

Saat mencoba point-in-time memulihkan (PITR) instance MySQL atau MariaDB DB Anda, Anda mungkin mengalami kesalahan berikut.


Database instance could not be restored because there has been incompatible database activity for restore
functionality. Common examples of incompatible activity include using temporary tables, in-memory tables,
or using MyISAM tables. In this case, use of Temporary table was detected.

PITR mengandalkan snapshot cadangan dan log biner (binlog) dari MySQL atau MariaDB untuk memulihkan instans DB Anda ke waktu tertentu. Informasi tabel sementara mungkin tidak dapat diandalkan di binlog dan dapat menyebabkan kegagalan PITR. Jika Anda menggunakan tabel sementara di instance MySQL atau MariaDB DB Anda, Anda dapat mengurangi kemungkinan kegagalan PITR dengan melakukan pencadangan yang lebih sering. Kegagalan PITR paling mungkin terjadi dalam waktu antara pembuatan tabel sementara dan snapshot cadangan berikutnya.

Memulihkan instans DB yang menyertakan tabel dalam memori

Anda mungkin mengalami masalah saat memulihkan basis data yang memiliki tabel dalam memori. Tabel dalam-memori dibersihkan selama proses mulai ulang. Sebagai hasilnya, tabel dalam memori Anda mungkin kosong setelah boot ulang. Kami merekomendasikan agar Anda merancang solusi untuk menangani tabel kosong jika proses mulai ulang terjadi saat menggunakan tabel dalam memori. Jika Anda menggunakan tabel dalam memori dengan instans DB yang direplikasi, Anda mungkin perlu membuat replika baca setelah memulai ulang. Hal ini mungkin diperlukan jika replika baca melakukan boot ulang dan tidak dapat memulihkan data dari tabel dalam memori yang kosong.

Untuk informasi selengkapnya tentang pencadangan dan PITR, lihat Pengantar cadangan dan Memulihkan instans DB ke waktu tertentu untuk Amazon RDS.

Kesalahan replikasi terhenti

Ketika memanggil perintah mysql.rds_skip_repl_error, Anda mungkin menerima pesan kesalahan yang menyatakan bahwa replikasi mati atau dinonaktifkan.

Pesan kesalahan ini muncul karena replikasi dihentikan dan tidak dapat dimulai ulang.

Jika Anda perlu melewati sejumlah besar kesalahan, lag replikasi dapat meningkat hingga melampaui periode retensi default untuk file log biner. Dalam hal ini, Anda mungkin mengalami kesalahan fatal karena file log biner dibersihkan sebelum diputar ulang pada replika. Penghapusan ini menyebabkan replikasi berhenti, dan Anda tidak dapat lagi memanggil perintah mysql.rds_skip_repl_error untuk melewati kesalahan replikasi.

Anda dapat memitigasi masalah ini dengan meningkatkan jumlah jam penyimpanan file log biner pada sumber replikasi Anda. Setelah meningkatkan waktu retensi binlog, Anda dapat memulai ulang replikasi dan memanggil perintah mysql.rds_skip_repl_error sesuai kebutuhan.

Untuk mengatur waktu retensi binlog, gunakan prosedur mysql.rds_set_configuration. Tentukan parameter konfigurasi 'jam retensi binlog' sekaligus jumlah jam untuk menyimpan file binlog di klaster DB, hingga 720 (30 hari). Contoh berikut menetapkan periode penyimpanan file binlog menjadi 48 jam.


CALL mysql.rds_set_configuration('binlog retention hours', 48);

Pembuatan replika baca gagal atau replikasi rusak dengan kesalahan fatal 1236

Setelah mengubah nilai parameter default untuk instans DB MySQL atau MariaDB, Anda mungkin mengalami salah satu masalah berikut:

Anda tidak dapat membuat replika baca untuk instans DB.
Replikasi gagal dengan fatal error 1236.

Beberapa nilai parameter default untuk instans DB MySQL dan MariaDB membantu memastikan bahwa basis data tersebut sesuai dengan ACID dan replika baca aman dari crash. Hal ini dilakukan dengan memastikan setiap commit disinkronkan sepenuhnya dengan menulis transaksi ke log biner sebelum di-commit. Mengubah parameter ini dari nilai default untuk meningkatkan performa dapat menyebabkan replikasi gagal ketika transaksi belum ditulis ke log biner.

Untuk mengatasi masalah ini, atur nilai parameter berikut:

sync_binlog = 1
innodb_support_xa = 1
innodb_flush_log_at_trx_commit = 1

Replikasi replika baca gagal menginisialisasi struktur metadata

Ketika Anda mencoba untuk memulai replikasi, Anda menerima pesan galat berikut:


Read Replica Replication Error - SQLError: 13124, reason: Replica failed to initialize applier metadata structure from the repository

Kesalahan ini terjadi ketika ada masalah dengan struktur metadata replika. Untuk memperbaiki struktur metadata, Anda harus membuat replika baru.

Untuk mencegah hal ini terjadi di masa depan, lakukan salah satu tindakan berikut:

Jika memungkinkan, nonaktifkan multi-threading pada replika Anda. Dimulai dengan MySQL 8.0.27, multi-threading diaktifkan secara default.
Jika Anda perlu menggunakan multi-threading pada replika Anda, maka kami sarankan Anda menggunakan replikasi berbasis GTID. Untuk informasi selengkapnya, lihat Menggunakan replikasi GTID berbasis.

Tidak dapat mengatur periode retensi cadangan menjadi 0

Ada beberapa alasan mengapa Anda mungkin perlu mengatur periode retensi cadangan menjadi 0. Misalnya, Anda dapat langsung menonaktifkan pencadangan otomatis dengan mengatur periode retensi menjadi 0.

Dalam beberapa kasus, Anda mungkin menetapkan nilai ke 0 dan menerima pesan yang mengatakan bahwa jangka waktu penyimpanan harus antara 1 dan 35. Dalam kasus ini, periksa untuk memastikan bahwa Anda belum menyiapkan replika baca untuk instans. Replika baca memerlukan cadangan untuk mengelola log replika baca sehingga Anda tidak dapat mengatur periode penyimpanan sebesar 0.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Kuota dan batasan

Referensi API Amazon RDS

Di halaman ini

Pilih preferensi cookie Anda

Pemecahan Masalah untuk Amazon RDS

Topik

Tidak dapat terhubung ke instans DB Amazon RDS

catatan

catatan

Mengonfigurasi gateway internet untuk subnet

Menguji koneksi ke instans DB

catatan

Memecahkan masalah autentikasi koneksi

Masalah keamanan Amazon RDS

Pesan kesalahan “gagal mengambil atribut akun, fungsi konsol tertentu mungkin terganggu.”

Memecahkan masalah status jaringan yang tidak kompatibel

Penyebab

Penyelesaian

Gunakan start-db-instance perintah

catatan

Lakukan point-in-time pemulihan

catatan

Mengatur ulang kata sandi pemilik instans DB

Penghentian atau boot ulang instans DB Amazon RDS

Perubahan parameter DB Amazon RDS tidak diberlakukan

Instans DB Amazon RDS kehabisan ruang penyimpanan

Instans DB Amazon RDS tidak cukup tersedia

Masalah memori yang dapat dikosongkan di Amazon RDS

Masalah MySQL dan MariaDB MySQL

Topik

Koneksi maksimum MySQL dan MariaDB

Mendiagnosis dan menyelesaikan status parameter yang tidak kompatibel untuk batas memori

Mendiagnosis dan mengatasi jeda di antara replika baca

catatan

Mendiagnosis dan menyelesaikan kegagalan replikasi baca MySQL atau MariaDB

Membuat pemicu dengan log biner aktif memerlukan hak istimewa SUPER

Membuat grup parameter baru untuk mengizinkan pemicu dengan log biner yang aktif menggunakan CLI

Mendiagnosis dan menyelesaikan kegagalan pemulihan point-in-time

Kesalahan replikasi terhenti

Pembuatan replika baca gagal atau replikasi rusak dengan kesalahan fatal 1236

Replikasi replika baca gagal menginisialisasi struktur metadata

Tidak dapat mengatur periode retensi cadangan menjadi 0

Di halaman ini

Related resources

Apakah halaman ini membantu Anda?

Related resources

Topik berikutnya:

Topik sebelumnya:

Perlu bantuan?