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 mencakup hal berikut:

• 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.

Konsumsi 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 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 redo 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 dalam versi r20260320.00_00. Anda dapat memeriksa versi pemeliharaan di Google Cloud konsol, di halaman Ringkasan instance Cloud SQL, di bagian Pemeliharaan bagian.

Memecahkan masalah penggunaan disk tinggi

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

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

Mengidentifikasi kueri yang berjalan lama dan aktif

Masalah penggunaan disk 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 diambil 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;

Dalam 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 set hasil yang besar.
• Operasi ALTER TABLE yang besar.

Mitigasi langsung

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

Untuk mengakhiri 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 dari 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 bertanggung jawab atas 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 query insights untuk mengidentifikasi dan menyempurnakan kueri yang berperforma lambat.

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

Melakukan analisis retrospektif

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

• Query insights. Periksa kueri yang mungkin telah membuat file sementara berukuran besar. Periksa kueri yang tercantum berdasarkan 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 mengambil 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 telah menghasilkan file sementara berukuran besar. Jika tidak, Anda dapat mengaktifkan General_log dan mengambil 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 menjadi penyebab file besar yang tidak ditautkan.
  • 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 untuk jangka waktu yang lebih lama.

  Peningkatan metrik ini yang bertepatan dengan lonjakan penggunaan disk menunjukkan bahwa kueri yang menghasilkan tabel sementara berukuran besar adalah akar masalahnya.

• 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 urungkan, yang juga dapat berkontribusi pada 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 ekstensif.

Untuk mengoptimalkan kueri, Anda dapat melakukan hal berikut:

• Tambahkan indeks yang sesuai.
• Refaktor gabungan kompleks atau operasi pengurutan.

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.