All Products
Search
Document Center

ApsaraDB RDS:Masalah penyimpanan RDS MySQL

Last Updated:Jul 11, 2026

Ketika instans ApsaraDB RDS for MySQL kehabisan ruang penyimpanan, sistem secara otomatis mengunci instans tersebut ke mode read-only untuk mencegah kehilangan data. Identifikasi jenis file yang mengonsumsi ruang penyimpanan dan selesaikan penyebabnya.

Tanggapan darurat

Jika instans sudah terkunci (read-only), segera perluas disk untuk memulihkan akses tulis. Lakukan semua pembersihan dan perbaikan akar masalah setelah layanan dipulihkan.

  1. Di Konsol RDS, klik ID instans.

  2. Ubah ukuran disk secara manual untuk membuka kunci instans.

Instans akan dibuka kuncinya dalam waktu sekitar 5 menit setelah proses pengubahan ukuran selesai. Anda dapat memantau progresnya di Task Center.

Penting

Mengubah ukuran disk hanya merupakan solusi sementara. Penyimpanan akan kembali penuh kecuali Anda juga menangani akar masalah di bawah ini.

Lihat penggunaan penyimpanan

Ruang penyimpanan instans RDS for MySQL mencakup data pengguna, data sistem, log, dan file temporary.

  1. Di Konsol RDS, klik ID instans.

  2. Di panel navigasi kiri, pilih Monitoring and Alerts > Standard Monitoring.

  3. Temukan tampilan MySQL Storage Space Used. Klik ikon di samping judul tampilan untuk melihat deskripsi setiap parameter.

Untuk langkah pemantauan terperinci, lihat Lihat informasi pemantauan.

Identifikasi penyebab

Periksa tampilan MySQL Storage Space Used dan cocokkan parameter dengan penggunaan tinggi ke jenis file serta solusi di bawah ini.

Jenis file Parameter dalam Pemantauan Standar Parameter Analisis Ruang Solusi
File temporary temp_file_size Temporary file data size Akumulasi file temporary
File binlog binlog_size Binlog usage Akumulasi file binary log
File undo log undolog_size undo log usage Akumulasi file sistem
File general log general_log_size General log usage Akumulasi file general log
File data pengguna user_data_size User database usage Akumulasi file data pengguna

Periksa juga fragmentasi dan pembengkakan indeks, yang tidak muncul sebagai parameter terpisah tetapi dapat mengonsumsi ruang signifikan:

Akumulasi file temporary

File temporary dibuat ketika MySQL mengeksekusi Pernyataan SQL yang melakukan pengurutan, pengelompokan, atau penggabungan tabel pada set data besar. Log biner untuk transaksi besar juga disimpan sementara hingga transaksi tersebut dikomit. Jika file-file ini menumpuk, instans akan terkunci.

Atasi penguncian segera:

  • MySQL 5.7 atau versi sebelumnya: Restart instans. Sistem akan menghapus file temporary secara otomatis saat restart.

  • MySQL 8.0: Instans menghentikan semua sesi pengguna dan memulai rollback otomatis. File temporary akan dilepas setelah rollback selesai.

Jika instans tidak membuka kunci secara otomatis, jalankan show processlist untuk mengidentifikasi sesi dengan status Copy to tmp table atau Sending data, lalu hentikan sesi tersebut dengan perintah kill.

Untuk informasi lebih lanjut, lihat Solusi akumulasi file temporary di RDS for MySQL.

Akumulasi file binary log

Transaksi besar menghasilkan banyak file binary log dalam periode singkat. Jika log menumpuk lebih cepat daripada dibersihkan, penyimpanan akan habis dan instans terkunci.

Selesaikan dengan mengunggah log yang ada:

Gunakan fitur One-click binary log upload untuk mengunggah file binary log dari instans RDS ke OSS. RDS secara otomatis menghapus file yang telah diunggah. Lihat Lihat dan hapus file binary log.

Cegah pengulangan dengan menyesuaikan kebijakan retensi:

  1. Di Konsol RDS, buka halaman Backup and Restoration.

  2. Klik tab Backup Strategy.

  3. Di samping Local Log Retention Policy, klik Edit.

  4. Sesuaikan periode retensi, penggunaan penyimpanan maksimum, dan ruang penyimpanan yang tersedia. Saat penyimpanan log lokal mencapai ambang batas, sistem secara otomatis menghapus log terlama.

Untuk informasi lebih lanjut, lihat Solusi akumulasi file binlog MySQL.

Akumulasi fragmentasi

InnoDB mengelola ruang tabel berdasarkan halaman (page). Saat Anda menghapus atau memperbarui baris menggunakan delete atau update, MySQL menandai ruang tersebut sebagai dapat digunakan kembali tetapi tidak memperkecil ukuran file disk. Jika halaman yang telah dibebaskan tidak dapat digunakan kembali, fragmentasi menumpuk dan mengonsumsi ruang penyimpanan.

Selesaikan fragmentasi dengan salah satu metode berikut:

  • Command line: Jalankan optimize table <table_name> untuk membangun ulang tabel dan memulihkan ruang yang terfragmentasi.

  • Konsol DMS: Masuk ke instans RDS di DMS. Klik kanan nama tabel dan pilih Batch operation table. Pilih tabel yang ingin didefragmentasi, lalu pilih Table Maintenance > Optimize Table.

  • Automatic Fragment Reclamation: Di konsol RDS, buka Autonomy Services > Diagnostics > Autonomy Center. Klik Autonomy Service Settings, lalu aktifkan Automatic Fragment Reclamation pada tab Optimization and Throttling. Untuk detail selengkapnya, lihat Menggunakan fitur pemulihan fragmen otomatis.

Untuk informasi lebih lanjut, lihat Solusi fragmentasi ruang MySQL.

Akumulasi file sistem

File sistem besar hampir selalu disebabkan oleh pertumbuhan undo log. Saat kueri InnoDB berdurasi panjang dijalankan secara bersamaan dengan pembaruan data besar, MySQL menghasilkan data undo berlebih yang mengisi ruang tabel sistem dan dapat menghabiskan penyimpanan.

Resolusi tergantung pada versi MySQL dan konfigurasi undo tablespace Anda.

MySQL 8.0

Sistem secara otomatis membersihkan file undo. Tidak diperlukan tindakan manual.

MySQL 5.7 dengan innodb_undo_tablespaces = 2

Instans menggunakan undo tablespace terpisah. Saat ukuran file undo melebihi innodb_max_undo_log_size dan tidak ada transaksi aktif yang memerlukan data tersebut, sistem menjalankan operasi truncate untuk melepas ruang tersebut.

MySQL 5.7 dengan innodb_undo_tablespaces = 0

Data undo disimpan di ruang tabel sistem ibdata1 dan tidak dapat dipulihkan. Gunakan salah satu metode berikut untuk menyelesaikan masalah ini:

MySQL 5.5 dan 5.6

Pembersihan file undo tidak didukung. Upgrade ke MySQL 5.7 Edisi Ketersediaan Tinggi atau MySQL 8.0. Setelah upgrade ke MySQL 5.7, aktifkan undo tablespace terpisah untuk mendukung pembersihan otomatis. MySQL 8.0 membersihkan file undo secara otomatis.

Penting

Untuk instans MySQL 5.7 atau versi sebelumnya dengan innodb_undo_tablespaces = 0, ruang yang digunakan oleh file ibdata1 asli tidak dapat dipulihkan bahkan setelah upgrade versi utama. Setelah upgrade, hanya log undo yang baru dihasilkan yang ditulis ke tablespace terpisah dan mendukung pembersihan otomatis.

Untuk informasi lebih lanjut, lihat Solusi akumulasi file sistem MySQL.

Akumulasi file general log

Saat general query log diaktifkan, RDS mencatat setiap Pernyataan SQL yang dieksekusi, termasuk SELECT, INSERT, UPDATE, dan DELETE. Di bawah traffic tinggi, ukuran file log meningkat pesat. Jika tidak dibersihkan secara berkala, file ini dapat menghabiskan penyimpanan.

Selesaikan segera:

Jalankan perintah berikut untuk menghapus semua catatan general log yang ada:

TRUNCATE TABLE mysql.general_log;

Hentikan pertumbuhan log baru:

Nonaktifkan pengumpulan general log dengan mengatur parameter runtime general_log ke OFF. Lihat Atur parameter instans.

Praktik terbaik: Nonaktifkan general log di lingkungan produksi. Aktifkan sementara hanya untuk debugging, lalu nonaktifkan dan bersihkan segera.

Untuk informasi lebih lanjut, lihat Solusi akumulasi file general log MySQL.

Akumulasi file data pengguna

File data pengguna bertambah seiring waktu dan dapat memenuhi penyimpanan jika tidak dikelola. Kolom dengan tipe blob, text, atau varchar panjang umumnya berkontribusi pada ukuran file data yang besar. Saat penyimpanan penuh, RDS mengunci instans untuk mencegah kehilangan data.

Selesaikan dengan membersihkan data yang tidak digunakan:

  • Gunakan drop atau truncate untuk menghapus tabel atau data yang tidak lagi diperlukan.

  • Untuk data objek besar, kompres data sebelum menyimpannya untuk mengurangi penggunaan ruang.

Untuk informasi lebih lanjut, lihat Solusi akumulasi file data RDS for MySQL.

Akumulasi file indeks

Indeks disimpan sebagai file disk. Strategi pengindeksan yang tidak efisien atau terlalu banyak indeks sekunder dapat menyebabkan file indeks membengkak dan menghabiskan penyimpanan.

Optimalkan strategi pengindeksan Anda:

  • Buat indeks pada bidang yang tepat: Buat indeks pada bidang yang sering dikueri, diurutkan, atau digunakan dalam penggabungan tabel. Gunakan indeks komposit alih-alih indeks kolom tunggal jika memungkinkan untuk mengurangi ukuran total file indeks.

  • Hapus indeks yang tidak digunakan: Hapus indeks yang redundan atau tidak lagi dirujuk oleh kueri apa pun.

Catatan

Menghapus indeks dapat menyebabkan blocking tingkat tabel. Lakukan operasi ini selama jam sepi, atau gunakan fitur lock-free schema evolution di DMS untuk mengurangi dampaknya.