Kelola ruang penyimpanan - PolarDB

Setiap spesifikasi kluster PolarDB for MySQL memiliki kapasitas penyimpanan maksimum. Seiring bertambahnya data, log, dan file sementara, ruang penyimpanan dapat menjadi penuh, menyebabkan kluster terkunci dalam mode read-only dan mengganggu operasi bisnis normal. Untuk membantu Anda mengelola sumber daya penyimpanan secara efektif serta memastikan stabilitas kluster, topik ini memberikan gambaran rinci tentang penggunaan ruang penyimpanan beserta metode spesifik untuk melihat penggunaan, membersihkan file, dan mereklaim ruang.

Komposisi ruang penyimpanan

Memahami komponen ruang penyimpanan PolarDB for MySQL membantu Anda mengelolanya secara efisien, mengidentifikasi masalah dengan akurat, serta mengambil langkah-langkah optimasi yang sesuai.

File data: Menyimpan data bisnis seperti tabel data dan indeks.
File log: Termasuk log biner, redo log, dan undo log. File log ini dapat tumbuh dengan cepat selama transaksi besar atau operasi penulisan konkurensi tinggi.
Catatan
Secara default, pencatatan biner dinonaktifkan untuk kluster PolarDB for MySQL. Sebagai gantinya, digunakan log fisik (Redo Log) yang lebih efisien. Jika pencatatan biner tidak diaktifkan, informasi ini dapat diabaikan.
File sementara: Dihasilkan selama operasi seperti pengurutan (ORDER BY), pengelompokan (GROUP BY), atau kueri gabungan. Selain itu, transaksi besar yang belum dikomit juga menghasilkan file cache log biner sementara.
File sistem: Menyimpan komponen inti yang diperlukan untuk operasi database, seperti kamus data, informasi transaksi, dan buffer penulisan ganda. File-file ini mendasari manajemen mandiri engine InnoDB dan penting untuk memastikan konsistensi data serta pemulihan kluster. File ini tidak dapat dimanipulasi secara langsung.

Lihat penggunaan ruang penyimpanan

Anda dapat memeriksa penggunaan penyimpanan kluster melalui dua cara:

Buka PolarDB console. Pada halaman Basic Information kluster target, lihat kapasitas penyimpanan saat ini di area Distributed Storage.
Buka PolarDB console. Pada tab Storage Analysis halaman Diagnostics and Optimization > > Quick Diagnostics kluster target, lihat penggunaan ruang penyimpanan pada titik waktu tertentu.

Bersihkan file data dan rebut ruang tabel

Seiring waktu, PolarDB for MySQL dapat mengonsumsi ruang penyimpanan berlebih karena fragmentasi data. Saat menggunakan perintah DELETE untuk menghapus data, sistem hanya menandai posisi rekaman atau halaman data sebagai dapat digunakan kembali tanpa mengurangi ukuran file tabel fisik, sehingga menyebabkan akumulasi ruang yang terfragmentasi.

Catatan

Antarmuka konsol mungkin memerlukan waktu untuk diperbarui setelah Anda membersihkan file data. Tunggu hingga perubahan tersebut efektif.

Bersihkan file

Untuk tabel yang tidak lagi diperlukan, gunakan perintah TRUNCATE TABLE atau DROP TABLE untuk segera melepaskan semua ruang yang digunakan.

Catatan

Sebelum melakukan operasi ini, pastikan data telah dicadangkan untuk mencegah kehilangan data.

Mengambil kembali ruang tabel

Untuk tabel dengan banyak fragmentasi yang perlu dipertahankan, jalankan perintah OPTIMIZE TABLE selama jam-jam sepi. Operasi ini membangun ulang tabel, menghilangkan fragmentasi, dan merebut kembali ruang bebas. Anda juga dapat menggunakan alat DMS, yang mendukung throttling untuk meminimalkan dampak pada beban kerja meskipun kecepatan eksekusi lebih lambat.

Catatan

Jika tingkat fragmentasi tabel rendah, menjalankan perintah OPTIMIZE TABLE tidak akan secara signifikan mengurangi ukuran tablespace. Anda dapat melihat tingkat fragmentasi di bidang DATA_FREE dari tampilan information_schema.tables.
Saat menjalankan perintah OPTIMIZE TABLE, data tabel disalin ke tabel sementara baru, meningkatkan penggunaan ruang penyimpanan kluster secara sementara.
Untuk tabel tanpa indeks teks penuh, pernyataan OPTIMIZE TABLE dieksekusi menggunakan DDL Online, yang mendukung pembacaan dan penulisan bersamaan.
Menjalankan operasi OPTIMIZE TABLE pada tabel besar menyebabkan lonjakan I/O dan penggunaan kolam buffer, yang dapat menyebabkan tabel terkunci dan konflik sumber daya. Jalankan operasi ini selama jam-jam sepi untuk menghindari ketidaktersediaan kluster dan titik putus pemantauan.

Perbandingan metode

Pilih metode reklamasi berdasarkan skenario bisnis Anda.

Metode reklamasi tablespace	Pembacaan dan penulisan bersamaan	Kecepatan eksekusi	Rate Limiting	Skenario
Rebut tablespace menggunakan perintah `OPTIMIZE TABLE`	Ya	Cepat	Tidak	Jika beban kerja bisnis ringan dan efisiensi eksekusi tinggi diperlukan, `OPTIMIZE TABLE` dapat dengan cepat merebut kembali tablespace dan mengurangi overhead ruang kluster.
Rebut tablespace menggunakan DMS	Ya	Lambat	Ya	Jika beban kerja kluster sensitif dan efisiensi eksekusi tidak, alat DMS dapat merebut kembali tablespace dengan dampak lebih rendah pada bisnis Anda. Ini mengurangi dampak operasi reklamasi ruang pada kinerja kluster.

Prosedur

Rebut tablespace menggunakan perintah OPTIMIZE TABLE

Anda dapat merebut tablespace dengan menjalankan perintah berikut:

OPTIMIZE TABLE [Database1].[Table1],[Database2].[Table2]

Catatan

[Database1] dan [Database2] adalah nama database. [Table1] dan [Table2] adalah nama tabel.
Saat menjalankan perintah OPTIMIZE TABLE di engine InnoDB, pesan Tabel tidak mendukung optimasi, melakukan recreate + analyze sebagai gantinya dikembalikan. Ini adalah respons normal. Pastikan bahwa ok dikembalikan. Untuk informasi lebih lanjut tentang pernyataan OPTIMIZE TABLE, lihat Pernyataan OPTIMIZE TABLE.

Mengambil kembali ruang tabel menggunakan DMS

Masuk ke database: Buka PolarDB console, klik tombol Log on to Database di pojok kanan atas halaman Basic Information kluster target, lalu masuk ke kluster PolarDB for MySQL di platform Data Management (DMS).
Rebut tablespace: Di panel kiri, pilih ID kluster target, klik dua kali database tujuan, klik kanan nama tabel apa saja, lalu pilih Batch Operations On Tables. Pada halaman Operasi Batch pada Tabel, pilih tabel yang ingin Anda bebaskan ruangnya dan klik Table Maintenance > Optimize Table.

Bersihkan file log

Kluster PolarDB for MySQL dapat dengan cepat menghasilkan log biner, redo log, atau undo log dari pemrosesan transaksi besar, menyebabkan sejumlah besar ruang penyimpanan terpakai atau bahkan penuh. Dalam situasi ini, pertimbangkan terlebih dahulu untuk memperluas kapasitas penyimpanan, lalu selidiki penyebab cepatnya pembuatan file log.

Catatan

Antarmuka konsol mungkin memerlukan waktu untuk diperbarui setelah Anda membersihkan log biner, undo log, atau redo log. Harap tunggu hingga perubahan tersebut tercermin.

Log biner

Secara default, pencatatan biner dinonaktifkan untuk kluster PolarDB for MySQL. Sebagai gantinya, digunakan log fisik (Redo Log) yang lebih efisien. Jika pencatatan biner tidak diaktifkan, lihat solusi pembersihan untuk redo log dan undo log.

Kebijakan retensi data

File log biner memiliki dua kebijakan retensi berikut:

Setelah mengaktifkan pencatatan biner, file disimpan selama 3 hari secara default. File yang lebih tua dari 3 hari dihapus secara otomatis.
Catatan
- Untuk kluster PolarDB for MySQL yang dibeli sebelum 23 November 2023, file log biner disimpan selama dua minggu (14 hari) secara default.
- Untuk kluster PolarDB for MySQL yang dibeli sebelum 17 Januari 2024, file log biner disimpan selama satu minggu (7 hari) secara default.
Setelah menonaktifkan pencatatan biner, file log biner yang ada disimpan tanpa batas waktu dan tidak dihapus secara otomatis.
Catatan
Untuk menghapus file log biner, atur parameter periode retensi log biner (loose_expire_logs_hours atau binlog_expire_logs_seconds) ke nilai kecil saat pencatatan biner diaktifkan. Setelah file yang melebihi periode retensi dihapus secara otomatis, Anda dapat menonaktifkan pencatatan biner.

Ubah periode retensi

Penting

Mengubah periode retensi file log biner tidak menyebabkan koneksi sementara atau memerlukan restart kluster.
Jika mengubah periode retensi menyebabkan banyak file log biner dibersihkan (misalnya, 10 TB), pengecualian penulisan database jangka pendek mungkin terjadi selama proses pembersihan. Oleh karena itu, jika total ukuran file log biner besar, lakukan operasi ini selama jam-jam sepi. Perpendek periode retensi log biner dalam beberapa langkah untuk membersihkan sebagian data log biner setiap kali.
File log biner yang dibersihkan tidak dapat dipulihkan setelah dihapus.

Anda dapat mengubah periode retensi file log biner dengan cara berikut:

MySQL 5.6: Atur periode retensi log biner dengan mengubah nilai parameter loose_expire_logs_hours. Nilainya dalam jam. Rentang nilainya adalah 0 hingga 2376. Nilai defaultnya adalah 72. Nilai 0 menunjukkan bahwa file log biner tidak dihapus secara otomatis.
MySQL 5.7 atau MySQL 8.0: Atur periode retensi log biner dengan mengubah nilai parameter binlog_expire_logs_seconds. Nilainya dalam detik. Rentang nilainya adalah 0 hingga 4294967295. Nilai defaultnya adalah 259200. Nilai 0 menunjukkan bahwa file log biner tidak dihapus secara otomatis.

Bersihkan file historis

Setelah mengubah parameter periode retensi log biner (loose_expire_logs_hours atau binlog_expire_logs_seconds), file log biner historis di kluster tidak segera dibersihkan. Dalam kasus ini, Anda dapat menggunakan salah satu dari tiga metode berikut untuk membersihkan file historis:

Tunggu pembersihan otomatis: Saat file log biner terakhir mencapai ukuran maksimumnya (parameter max_binlog_size), sistem beralih ke file log biner baru. File log biner historis kemudian secara otomatis dibersihkan.
Pembersihan manual: Gunakan akun istimewa untuk menjalankan perintah flush binary logs. Ini segera memicu pergantian file log biner dan membersihkan file log biner yang kedaluwarsa.
Mulai ulang kluster: Setelah kluster dimulai ulang, sistem secara otomatis membersihkan file log biner historis.

Undo log

Dalam kluster PolarDB for MySQL, undo log berfungsi sebagai versi historis untuk kontrol konkurensi multiversi (MVCC). Jika transaksi yang belum dikomit pada node read-only atau node baca/tulis memegang tampilan baca lama, proses pembersihan undo log akan diblokir, menyebabkan ruang terus bertambah.

Identifikasi dan hentikan transaksi yang belum dikomit

Masuk ke database: Buka PolarDB console, klik tombol Log on to Database di pojok kanan atas halaman Basic Information kluster target untuk masuk ke kluster PolarDB for MySQL di platform Data Management (DMS).
Temukan transaksi yang belum dikomit: Jalankan perintah berikut untuk memeriksa transaksi yang belum dikomit dalam waktu lama.
```
SELECT * FROM INFORMATION_SCHEMA.innodb_trx;
```
Perhatikan dengan cermat transaksi di mana trx_started (waktu mulai transaksi) sangat lama, atau trx_state (status transaksi) telah RUNNING untuk waktu yang lama. Catat trx_mysql_thread_id (ID thread) mereka.
Hentikan transaksi: Setelah Anda yakin bahwa itu tidak akan memengaruhi bisnis Anda, jalankan perintah KILL untuk menghentikan transaksi target.
```
kill [Thread ID];
```

Lihat kemajuan pembersihan latar belakang

Setelah utas yang sesuai dengan transaksi dibersihkan, Anda perlu memeriksa kemajuan Undo history. Jika Anda menemukan bahwa panjang Undo history masih terus bertambah dengan cepat, Anda perlu menyetel kinerja pembersihan latar belakang.

Catatan

Saat tekanan tulis tinggi, kebijakan PolarDB adalah memprioritaskan kinerja tulis saat ini. Ini dapat menyebabkan keterlambatan dalam pembersihan undo log.

Monitor kemajuan pembersihan: Jalankan perintah berikut untuk mengamati panjang Undo history.
```
SELECT COUNT FROM INFORMATION_SCHEMA.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
Jika nilai ini lebih besar dari 1.000.000, atau jika terus meningkat selama beberapa menit sementara tekanan saat ini tinggi, itu menunjukkan bahwa kecepatan pembersihan tidak dapat mengimbangi kecepatan tulis.
Atur ulang parameter pembersihan: Tingkatkan efisiensi pembersihan.
1. Tingkatkan nilai parameter innodb_purge_batch_size untuk meningkatkan ukuran batch untuk setiap pembersihan.
2. Tingkatkan nilai parameter innodb_purge_threads untuk meningkatkan jumlah utas pembersihan. Kami sarankan Anda mengatur nilai ini ke jumlah core CPU dalam spesifikasi kluster.
  Catatan
  Operasi ini memulai ulang kluster. Anda harus melakukan operasi ini selama jam-jam sepi.

Rebut ruang yang ditempati

Setelah panjang Undo history berkurang dan stabil, jika Anda ingin membersihkan ruang yang ditempati oleh undo log, Anda dapat mengaktifkan fitur pemotongan undo log.

Aktifkan fitur: Atur parameter innodb_undo_log_truncate ke ON.
Mekanisme pemicu: Ketika ukuran file undo tunggal melebihi innodb_max_undo_log_size, pemotongan undo log dipicu.
Pembatasan versi: Beberapa versi minor yang lebih lama memiliki bug terkait pemotongan undo log. Sistem telah menonaktifkan izin untuk memodifikasi parameter ini untuk versi-versi tersebut. Jika Anda mengalami situasi ini, Anda perlu memperbarui versi minor kluster ke versi terbaru.
Nonaktifkan segera: Fitur ini memperkenalkan overhead tambahan selama pergantian kluster atau restart. Setelah ruang direbut, segera atur kembali parameter ini ke OFF, terutama sebelum Anda melakukan operasi pemeliharaan seperti pembaruan versi minor. Aktifkan fitur ini hanya saat diperlukan.

Redo log

Kluster PolarDB for MySQL menggunakan redo log alih-alih log biner untuk mencapai sinkronisasi data antara node utama dan node read-only.

Tidak termasuk cadangan log, redo log lokal menempati 2 GB hingga 11 GB ruang penyimpanan. Ini mencakup delapan redo log di kolam buffer (8 GB), redo log yang sedang ditulis (1 GB), redo log yang dibuat sebelumnya (1 GB), dan redo log terakhir (1 GB).
Termasuk cadangan log, redo log lokal disimpan selama sekitar satu jam setelah cadangan selesai. Jika kecepatan tulis cepat (misalnya, lebih dari 35 MB/detik), ini dapat menyebabkan akumulasi sementara redo log lokal.

Aturan pembersihan

Redo log tidak mendukung pembersihan manual. Biasanya mereka dibersihkan secara otomatis setelah cadangan log selesai.

Catatan

Anda dapat menyesuaikan kebijakan cadangan log kluster di Konsol PolarDB. Periode retensi default adalah 7 hari.

Bersihkan file sementara

Sebuah PolarDB for MySQL kluster dapat menghasilkan banyak file sementara dari kueri kompleks atau transaksi besar. Hal ini dapat menyebabkan sejumlah besar ruang penyimpanan terisi atau bahkan penuh. Dalam kasus ini, pesan kesalahan mungkin muncul, seperti: error: 1114 Tabel '/home/mysql/log/tmp/#sqlxxx_xxx_xxx' penuh.

Anda dapat menangani ini dengan dua cara berikut:

Hentikan sesi

Hentikan sesi yang memiliki status Copy to tmp table atau Sending data.

Masuk ke database: Anda dapat pergi ke PolarDB console dan klik tombol Log on to Database di pojok kanan atas halaman Basic Information kluster target untuk masuk ke kluster PolarDB for MySQL di platform Data Management (DMS).
Lihat status sesi: Jalankan perintah berikut untuk melihat status sesi dalam database.
```
SHOW PROCESSLIST;
```
Temukan sesi target: Di DMS, klik kolom State di hasil kueri untuk mengurutkan data di kolom tersebut. Temukan sesi dengan status Copy to tmp table atau Sending data, dan catat ID sesinya.
Hentikan sesi: Jalankan perintah berikut untuk menghentikan sesi target.
```
kill [Session ID];
```
Penting
Sebelum Anda menghentikan sesi, pastikan bahwa itu tidak akan memengaruhi bisnis yang sedang berjalan.

Jika Anda masih tidak dapat melepaskan ruang penyimpanan setelah melakukan langkah-langkah di atas, Anda dapat memulai ulang setiap node dalam kluster untuk melepaskan ruang penyimpanan yang ditempati oleh file sementara.

Menyesuaikan parameter

Pergi ke PolarDB console. Pada halaman Settings and Management > > Parameters kluster target, ubah parameter tmp_table_size dan max_heap_table_size untuk meningkatkan ukuran ruang tabel sementara.

FAQ

Mengapa ukuran ruang penyimpanan tidak berubah setelah saya menggunakan DELETE perintah untuk menghapus data?

Operasi DELETE hanya menandai posisi Catatan atau halaman data sebagai dapat digunakan kembali. Ini tidak mengurangi ukuran file fisik. Hal ini menyebabkan fragmentasi ruang. Anda harus menjalankan perintah OPTIMIZE TABLE pada tabel selama jam sepi untuk mengklaim kembali ruang yang terfragmentasi ini.