Data Management：Pembersihan Data Historis

Prasyarat

• Database harus berbasis MySQL.

• Instans database harus menggunakan mode kontrol Stable Change atau Security Collaboration. Untuk informasi selengkapnya tentang Mode Kontrol, lihat Control Mode.

Prosedur

1. Masuk ke DMS console V5.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. Pada halaman pengajuan tiket Data Change, konfigurasikan parameter tiket lalu klik Submit.

   Tabel berikut menjelaskan beberapa parameter tersebut.

   Parameter	Deskripsi
   Database	Pilih database yang memiliki izin perubahan. Anda tidak dapat mengajukan tiket hanya dengan izin read-only atau izin tingkat tabel. Untuk informasi selengkapnya, lihat View My Permissions.
   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 melakukan pemindaian seluruh tabel selama pembersihan data dan menghapus data dalam Batch berdasarkan primary key atau unique key non-null. Jadwalkan eksekusi pada jam sepi dengan frekuensi rendah untuk meminimalkan dampak terhadap performa database. Catatan Waktu eksekusi aktual tugas terjadwal 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	Anda dapat menentukan durasi eksekusi. Tugas akan secara otomatis berhenti setelah berjalan selama durasi yang ditentukan untuk menghindari dampak terhadap layanan selama jam sibuk. Execute Task Without End Time. Specify End Time (Hours): Tetapkan durasi eksekusi untuk mencegah bottleneck pada pipeline sinkronisasi downstream (seperti DTS atau AnalyticDB) yang berdampak pada performa DMS. Setelah menentukan durasi, Anda dapat mengaktifkan Periodically Optimize Table (Defragmentasi), yang secara default dinonaktifkan. Fitur ini menjalankan OPTIMIZE TABLE setelah jumlah siklus pembersihan tertentu. Interval default adalah 60 siklus. Misalnya, dengan interval 60, sistem akan menjalankan OPTIMIZE TABLE setiap 60 kali pembersihan. Catatan Fitur OPTIMIZE TABLE hanya didukung untuk database RDS for MySQL dan PolarDB for MySQL. Durasi operasi OPTIMIZE TABLE dibatasi oleh durasi eksekusi yang ditentukan dalam konfigurasi kebijakan. Operasi OPTIMIZE TABLE akan berhenti ketika durasi eksekusi tugas berakhir.
   Change Stakeholder	Stakeholder yang ditentukan dapat melihat dan berkolaborasi dalam tiket tersebut. Pengguna lain tidak dapat mengaksesnya, kecuali administrator dan DBA.

4. Setelah mengajukan tiket, Anda dapat mengaktifkan pemeriksaan replication lag, menetapkan ambang batas, dan memodifikasi SQL.

   • (Opsional) Untuk mencegah replication lag berlebihan yang dapat memengaruhi alih bencana instans primary/standby, aktifkan pemeriksaan replication lag dan tetapkan ambang batasnya.

     Pada bagian Basic Information, klik chunk option untuk menetapkan ambang batas replication lag yang wajar dalam satuan detik. Jika replication lag melebihi ambang batas, eksekusi SQL akan dihentikan.

     Catatan

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

   • (Opsional) Modifikasi SQL.

     Setelah mengajukan tiket, sistem secara otomatis melakukan Pemeriksaan Awal SQL. Jika Pemeriksaan Awal gagal, Anda dapat memodifikasi SQL berdasarkan alasan kegagalan tersebut dan mencoba lagi.

   Catatan

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

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

6. Setelah tiket disetujui, sistem secara otomatis menghasilkan tugas terjadwal dan mengirim email kepada Pemilik tiket. Di bagian Basic Information, Anda dapat mengklik View Scheduled Tasks untuk melihat informasi penjadwalan. Anda juga dapat melakukan operasi berikut.

   • Pause Schedule

     Catatan

     Jika Anda perlu menonaktifkan jadwal secara permanen, buka halaman detail tiket untuk Historical Data Cleanup, 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

     Pengguna yang mengajukan tiket secara default menjadi Pemilik. Hanya Pemilik tiket yang dapat menjeda atau melanjutkan jadwal. Notifikasi email untuk setiap eksekusi terjadwal juga dikirim eksklusif kepada Pemilik.

7. Setelah tugas terjadwal dibuat, sistem mengeksekusi skrip SQL yang dihasilkan sesuai kebijakan penjadwalan yang dikonfigurasi. Anda dapat melihat semua informasi penjadwalan dan detail setiap eksekusi di dalam tiket.

   Catatan

   Pada setiap waktu terjadwal, sistem memeriksa apakah tugas pembersihan untuk tiket tersebut sedang berjalan. Jika tugas sedang berlangsung, tugas baru tidak akan dibuat. Oleh karena itu, Anda harus mengonfigurasi frekuensi eksekusi secara tepat.

FAQ

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

  A: Tergantung. Operasi OPTIMIZE TABLE tidak akan berdampak pada bisnis jika Anda telah mengaktifkan Lock-free Schema Change untuk instans target. Jika Lock-free Schema Change belum diaktifkan, lakukan operasi OPTIMIZE TABLE pada jam sepi untuk meminimalkan dampak terhadap bisnis. Untuk mengaktifkan Lock-free Schema Change, lihat Enable the lock-free schema change feature.

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

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