Masalah penggunaan disk yang tinggi

Halaman ini menjelaskan masalah penggunaan disk tinggi yang diketahui dan menawarkan bantuan pemecahan masalah.

Masalah penggunaan disk tinggi yang diketahui meliputi:

• Penggunaan file Temporary_files yang tinggi di MySQL 8.0 dan yang lebih baru.
• Penggunaan file Others yang tinggi di MySQL 8.0 dan yang lebih lama.

Penggunaan file sementara dikategorikan dalam file tmp_data di versi sebelum MySQL 8.0.

Metrik perincian penyimpanan MySQL

Metrik utama yang digunakan untuk memantau penggunaan disk secara mendetail adalah cloudsql.googleapis.com/database/disk/bytes_used_by_data_type. Metrik ini memberikan perincian penggunaan disk instance per jenis data sebagai berikut:

Jenis data	Definisi
Binlog	Penyimpanan yang digunakan oleh log biner MySQL, yang penting untuk pemulihan point-in-time dan replikasi.
Cloudsql_mysql_audit_log	Penyimpanan yang digunakan oleh log audit Cloud SQL MySQL.
Data	Mencakup tablespace InnoDB utama (file .ibd) dan tablespace sistem (ibdata1).
General_log	Penyimpanan yang digunakan oleh log kueri umum.
General_tablespace	Penyimpanan yang digunakan oleh tablespace sistem InnoDB, yang terdiri dari file ibdata*.
Last_sys_tablespace	Penyimpanan yang digunakan oleh tablespace terbaru.
Others	Mencakup file sistem internal.
Redo_log	Penyimpanan yang digunakan oleh log pengulangan InnoDB yang digunakan untuk pemulihan dari error.
Relaylog	Penyimpanan yang digunakan oleh log relay pada instance replika selama replikasi.
Slow_log	Penyimpanan yang digunakan oleh log kueri lambat jika diaktifkan dan disimpan di disk.
Temporary files	Penyimpanan yang dilacak secara eksplisit untuk file sementara yang dibuat oleh MySQL.
Temporary_space	Penyimpanan yang digunakan oleh file sementara sistem operasi di direktori /tmp.
Tmp_data	Data sementara yang dibuat oleh MySQL selama operasi seperti pengurutan dan penggabungan.
Undo_log	Penyimpanan yang digunakan oleh log urungkan.

Menemukan file dalam kategori Temporary_files dan Others

Kueri yang berjalan lama (seperti operasi JOIN, ORDER BY, atau GROUP BY yang kompleks) membuat file sementara berukuran besar di direktori MySQL.

Untuk instance MySQL yang menggunakan versi pemeliharaan yang dirilis mulai April 2026, file sementara ini dilaporkan secara eksplisit dalam kategori Temporary_files.

Pada versi sebelumnya, file sementara dilaporkan dalam kategori Others.

Catatan: Pelaporan Temporary_files terperinci untuk MySQL 8.0 pertama kali diperkenalkan di versi r20260320.00_00. Anda dapat memeriksa versi pemeliharaan di konsol Google Cloud , di halaman Ringkasan instance Cloud SQL, di bagian Pemeliharaan.

Memecahkan masalah penggunaan disk yang tinggi

Untuk memecahkan masalah penggunaan disk tinggi yang disebabkan oleh file sementara berukuran besar, ikuti langkah-langkah berikut:

1. Identifikasi kueri aktif yang berjalan lama.
2. Mitigasi langsung.
3. Menggunakan query insights.
4. Lakukan analisis retrospektif.
5. Mengoptimalkan kueri.
6. Siapkan pemantauan dan pemberitahuan.

Mengidentifikasi kueri aktif yang berjalan lama

Masalah penggunaan disk yang tinggi paling sering disebabkan oleh kueri yang berjalan lama (seperti operasi JOIN, ORDER BY, atau GROUP BY yang kompleks) yang membuat file sementara berukuran besar di direktori MySQL. File sementara ini dikategorikan dalam kategori Temporary_files atau Others.

Instance MySQL dengan versi pemeliharaan baru (versi r20260320.00_00 dan yang lebih baru) memiliki tabel INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES yang menampilkan file sementara yang dibuat oleh kueri yang berjalan lama dan tidak ditautkan (yaitu, file ada, tetapi tidak ditautkan ke proses MySQL) oleh MySQL.

Catatan: Tabel sementara eksplisit, yaitu tabel yang dibuat secara manual menggunakan perintah CREATE TEMPORARY TABLE, dikelola dalam tablespace sementara InnoDB dan tidak dicatat dalam tabel INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

Gunakan kueri berikut untuk mendapatkan kueri yang berjalan lama dan aktif:

SELECT
otf.fd, otf.size, p.id, p.info, p.user
FROM
 INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES otf
LEFT JOIN
performance_schema.processlist p
ON
otf.SESSION_ID = p.ID;

Contoh output:

+----+------------+------+----------------------------------+------+
| fd | size       | id   | info                             | user |
+----+------------+------+----------------------------------+------+
| 39 | 1670750208 |    8 | select * from t1 order by rand() | root |
| 40 | 1670750208 |    8 | select * from t1 order by rand() | root |
+----+------------+------+----------------------------------+------+
2 rows in set (0.00 sec)

Untuk instance dengan versi pemeliharaan r20260320.00_00 dan yang lebih lama, gunakan kueri berikut untuk mendapatkan kueri yang berjalan lama dan aktif:

SHOW FULL PROCESSLIST;

Pada output, cari operasi yang biasanya menggunakan file sementara disk:

• Operasi JOIN yang besar, terutama tanpa indeks yang tepat.
• Operasi ORDER BY atau GROUP BY yang kompleks pada kumpulan hasil yang besar.
• Operasi ALTER TABLE besar.

Mitigasi langsung

Jika kueri yang sedang berjalan diidentifikasi sebagai sumber penggunaan disk dari penyelidikan, Anda dapat menghentikannya untuk melepaskan ruang file sementara terkait.

Untuk menghentikan kueri, jalankan perintah berikut:

KILL PROCESS_ID;

Ganti PROCESS_ID dengan ID proses kueri:

• Untuk versi pemeliharaan r20260320 atau yang lebih baru, Anda dapat mengambil nilai PROCESS_ID melalui kolom SESSION_ID dalam tabel INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

• Untuk versi sebelumnya (versi r20260117 atau yang lebih lama) , Anda dapat mengambil nilai PROCESS_ID dari output operasi SHOW FULL PROCESSLIST.

Setelah penghentian kueri yang menyebabkan peningkatan konsumsi disk melalui file sementara, mungkin diperlukan waktu hingga sekitar 5 menit agar perubahan ini terdaftar dalam metrik penggunaan disk.

Menggunakan query insights

Sebaiknya gunakan insight kueri untuk mengidentifikasi dan menyempurnakan kueri yang berperforma lambat.

Untuk mengetahui informasi selengkapnya, lihat Menggunakan insight kueri untuk meningkatkan performa kueri.

Melakukan analisis retrospektif

Setelah lonjakan penggunaan mereda, Anda dapat menganalisis data historis untuk mengidentifikasi penyebabnya menggunakan cara berikut:

• Insight kueri. Periksa kueri yang mungkin telah membuat file sementara berukuran besar. Periksa kueri yang tercantum menurut ringkasan kueri (termasuk metrik seperti waktu eksekusi rata-rata, jumlah kueri, dan rata-rata baris yang dipindai dan ditampilkan).

• Slow_log. Aktifkan Slow_log dan tetapkan long_query_time ke nilai minimum yang sesuai. Log ini mencatat kueri yang berjalan lama untuk analisis dan pengoptimalan.

• General_log. Periksa General_log (jika diaktifkan) untuk kueri yang dicatat selama periode insiden yang memiliki operasi JOIN atau SORT yang mungkin menghasilkan file sementara berukuran besar. Atau, Anda dapat mengaktifkan General_log dan merekam kueri dalam peristiwa berikutnya.

  Catatan: Mengaktifkan log ini dapat memengaruhi performa dan penyimpanan dengan cepat karena verbositasnya.

• Metrik Cloud Monitoring. Tinjau metrik berikut:

  • cloudsql.googleapis.com/database/mysql/tmp_disk_tables_created_count: melacak jumlah tabel sementara yang dibuat di disk yang sering kali menjadi penyebab file besar yang tidak tertaut.
  • cloudsql.googleapis.com/database/mysql/handler_operations_count: melacak peningkatan jumlah operasi pada waktu tersebut.
  • cloudsql.googleapis.com/database/mysql/innodb/active_trx_total_time: melacak transaksi yang aktif dalam jangka waktu yang lebih lama.

  Peningkatan metrik ini yang bertepatan dengan lonjakan penggunaan disk sangat menunjukkan bahwa kueri yang menghasilkan tabel sementara berukuran besar adalah penyebab utamanya.

• Histori transaksi. Tinjau metrik berikut:

  • cloudsql.googleapis.com/database/mysql/innodb/history_list_length metric: panjang daftar histori yang tinggi dapat disebabkan oleh transaksi yang berjalan lama yang memblokir penghapusan log pembatalan, yang juga dapat menyebabkan masalah penggunaan disk.
  • cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time: transaksi yang berjalan lama selama periode penggunaan disk yang tinggi.

Mengoptimalkan kueri

Setelah analisis log menunjukkan kueri tertentu yang menyebabkan lonjakan metrik, Anda dapat mengoptimalkan atau menulis ulang kueri tersebut untuk meminimalkan pembuatan file sementara yang besar.

Untuk mengoptimalkan kueri, Anda dapat melakukan hal berikut:

• Tambahkan indeks yang sesuai.
• Memfaktorkan ulang operasi penggabungan atau pengurutan yang kompleks.

Untuk mengetahui informasi selengkapnya, lihat Penyesuaian kueri.

Menyiapkan pemantauan dan pemberitahuan

Untuk mencegah insiden di masa mendatang yang disebabkan oleh penggunaan disk yang tidak terkontrol, terutama karena file sementara yang dihasilkan dari kueri yang berjalan lama, terapkan pemantauan dan pemberitahuan proaktif menggunakan Monitoring.

Anda dapat membuat pemberitahuan untuk metrik yang menunjukkan konsumsi resource yang tinggi atau pola kueri yang diketahui menghasilkan file sementara berukuran besar.

Nama metrik	Deskripsi	Nilai minimum pemberitahuan yang direkomendasikan
cloudsql.googleapis.com/database/disk/utilization	Persentase ruang disk yang dialokasikan dan digunakan. Metrik ini memantau penggunaan kapasitas disk secara keseluruhan.	> 80% (Dipertahankan selama 5 menit)
cloudsql.googleapis.com/database/disk/bytes_used	Total byte ruang disk yang digunakan oleh instance database. Metrik ini melacak pertumbuhan konsumsi disk absolut.	Pantau terhadap metrik database/disk/quota.

Untuk mempelajari cara menyiapkan pemberitahuan dan pemantauan untuk metrik Cloud SQL, lihat Ringkasan pemberitahuan dan Memantau instance Cloud SQL.