Data Management:Pembersihan Data Historis

Prasyarat

• Database menggunakan MySQL.

• Instans database menggunakan mode kontrol Stable Change atau Security Collaboration.

Prosedur

1. Masuk ke DMS 5.0.

2. Di bilah navigasi atas, pilih Database Development > Data Change > Historical Data Cleanup.

   Catatan

   Dalam mode simple DMS, klik ikon di pojok kiri atas, lalu pilih All Features > Database Development > Data Change > Historical Data Cleanup.

3. Di halaman pengajuan tiket Data Change, konfigurasikan parameter tiket lalu klik Submit.

   Parameter utama:

   Parameter	Deskripsi
   Database	Pilih database yang memiliki izin perubahan. Izin hanya-baca (read-only) atau tingkat tabel tidak mencukupi. Lihat Izin Saya.
   Deletion Settings	Masukkan Table Name, Time Field, Time Accuracy, Retention Period (Days), dan Filter Condition (Nullable). Sistem akan secara otomatis menghasilkan skrip pembersihan berdasarkan informasi ini. Catatan Untuk tabel logis, masukkan nama tabel logis. Periode retensi menentukan kapan data dihapus secara otomatis. Misalnya, periode retensi 7 hari akan menghapus data yang lebih tua dari 7 hari. Contoh: Jika Table Name adalah api_call_record_11, Time Field adalah gmt_create, Retention Period adalah 7, dan Filter Condition adalah status = 1 or status=2, maka pernyataan SQL berikut akan dihasilkan: DELETE FROM `api_call_record_11` WHERE `gmt_create` < SUBDATE(CURDATE(),INTERVAL 7 DAY) AND (status = 1 or status=2);
   Schedule	DMS menghapus data dalam batch berdasarkan primary key atau unique key non-null. Jadwalkan pembersihan pada jam sepi dengan frekuensi rendah untuk meminimalkan dampak terhadap performa. Catatan Eksekusi aktual dapat menyimpang hingga satu menit dari waktu yang dijadwalkan. Interval minimum untuk eksekusi terjadwal adalah satu jam. Secara default, tugas dijalankan setiap hari pukul 02:00.
   Policy Configuration	Tentukan durasi eksekusi. Tugas akan berhenti secara otomatis setelah durasi yang ditentukan untuk menghindari gangguan layanan selama jam sibuk. Execute Task Without End Time. Specify End Time (Hours): Tetapkan batas durasi untuk mencegah gangguan pada pipeline sinkronisasi downstream (seperti DTS atau AnalyticDB). Setelah menentukan durasi, Anda dapat mengaktifkan Periodically Optimize Table (defragmentasi), yang secara default dinonaktifkan. Fitur ini menjalankan OPTIMIZE TABLE setelah jumlah siklus pembersihan tertentu. Default: setiap 60 siklus. Catatan Fitur OPTIMIZE TABLE hanya didukung untuk database RDS for MySQL dan PolarDB for MySQL. Operasi OPTIMIZE TABLE dibatasi oleh durasi eksekusi dalam konfigurasi kebijakan. Operasi OPTIMIZE TABLE akan berhenti ketika durasi tersebut berakhir.
   Change Stakeholder	Stakeholder yang ditentukan dapat melihat dan berkolaborasi dalam tiket. Jika tidak, hanya administrator dan DBA yang dapat mengaksesnya.

4. Setelah mengirimkan tiket, Anda dapat mengaktifkan pemeriksaan lag replikasi, menetapkan ambang batas, atau memodifikasi SQL.

   • (Opsional) Aktifkan pemeriksaan lag replikasi untuk mencegah lag berlebihan memengaruhi failover primer/siaga.

     Di bagian Basic Information, klik chunk option untuk menetapkan ambang batas lag replikasi dalam satuan detik. Eksekusi SQL akan dihentikan jika lag melebihi ambang batas tersebut.

     Catatan

     Saat ini, fitur ini hanya didukung untuk database ApsaraDB RDS for MySQL.

   • (Opsional) Modifikasi SQL.

     Sistem menjalankan precheck SQL secara otomatis. Jika precheck gagal, modifikasi SQL berdasarkan alasan kegagalan tersebut lalu coba lagi.

   Catatan

   Sebelum dikirim untuk persetujuan, Anda dapat memodifikasi konfigurasi eksekusi batch dan penjadwalan. Setelah dikirim, pengaturan ini tidak dapat diubah.

5. Klik Submit. Dalam mode Security Collaboration, tiket dikirim untuk persetujuan sesuai aturan yang dikonfigurasi. Dalam mode Stable Change, tiket disetujui secara otomatis.

6. Setelah disetujui, sistem membuat tugas terjadwal dan mengirim email kepada pemilik tiket. Di bagian Basic Information, klik View Scheduled Tasks untuk melihat detail penjadwalan. Anda juga dapat:

   • Pause Schedule

     Catatan

     Untuk menonaktifkan jadwal secara permanen, buka halaman detail tiket, klik Close Ticket di pojok kanan atas, masukkan alasan, lalu klik Submit.

   • Resume Schedule

     Catatan

     Setelah tiket ditutup, Anda harus mengajukan tiket baru untuk melanjutkan jadwal.

   • Change Ticket Owner

     Pengaju tiket menjadi pemilik tiket secara default. Hanya pemilik yang dapat menjeda atau melanjutkan jadwal, dan notifikasi eksekusi dikirimkan hanya kepada pemilik.

7. Sistem menjalankan SQL pembersihan sesuai kebijakan penjadwalan. Lihat detail penjadwalan dan riwayat eksekusi di tiket.

   Catatan

   Jika tugas pembersihan sedang berjalan pada waktu yang dijadwalkan, tugas baru tidak akan dibuat. Konfigurasikan frekuensi eksekusi sesuai kebutuhan.

FAQ

• Q: Apakah menjalankan OPTIMIZE TABLE sebagai bagian dari tugas Pembersihan Data Historis akan memengaruhi bisnis?

  A: Tergantung. Dengan Lock-free Schema Change diaktifkan, operasi OPTIMIZE TABLE tidak memengaruhi bisnis. Tanpa fitur tersebut, jalankan OPTIMIZE TABLE pada jam sepi. Untuk mengaktifkan Lock-free Schema Change, lihat Enable and disable lock-free schema change.

• Q: Bagaimana cara menghentikan operasi OPTIMIZE TABLE yang berlangsung terlalu lama?

  A: Buka halaman Ticket Details dan jeda tugas di bagian Execute.

• Q: Haruskah saya menjeda Pembersihan Data Historis saat menjalankan OPTIMIZE TABLE di luar DMS?

  A: Ya, jeda tugas terlebih dahulu. Operasi OPTIMIZE TABLE sementara mengonsumsi ruang disk dua hingga tiga kali ukuran tabel, dan menjalankan pembersihan berbasis DELETE secara bersamaan akan meningkatkan tekanan pada disk serta berpotensi menyebabkan kegagalan tugas. Pastikan instans memiliki ruang disk kosong minimal sebesar ruang tabel yang akan dikembalikan, dan jalankan OPTIMIZE TABLE pada jam sepi. Lanjutkan Pembersihan Data Historis setelah operasi selesai.