Data Management:DML\ Lockless\ Change

Cara kerja

Saat Anda mengajukan tiket perubahan tanpa penguncian, DMS membagi baris target menjadi batch berdasarkan rentang kunci primer dan menerapkan pernyataan SQL ke setiap batch secara berurutan. Karena setiap batch hanya memegang kunci selama jendela eksekusi singkatnya sendiri, transaksi lain dapat membaca dan menulis ke tabel di antara batch tersebut. Anda dapat mengatur kecepatan eksekusi dengan opsi rilis canary serta menetapkan waktu akhir untuk menghentikan tugas secara otomatis sebelum jam sibuk.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

• Database dengan salah satu jenis berikut:

  Database engine	Instans yang didukung
  MySQL	ApsaraDB RDS for MySQL, PolarDB for MySQL, MyBase for MySQL, PolarDB for Xscale, dan database MySQL pihak ketiga
  PostgreSQL	ApsaraDB RDS for PostgreSQL, PolarDB for PostgreSQL, MyBase for PostgreSQL, dan database PostgreSQL pihak ketiga
  MariaDB	ApsaraDB for MariaDB dan database MariaDB pihak ketiga
  OceanBase	ApsaraDB for OceanBase dalam mode MySQL
  Oracle-compatible PostgreSQL	PolarDB for PostgreSQL (Compatible with Oracle)

• Instans database yang dikelola dalam mode Stable Change atau Security Collaboration di Data Management (DMS). Untuk informasi lebih lanjut, lihat Lihat mode kontrol instans.

Batasan

• Hanya operasi pada satu tabel yang didukung.

• Hanya pernyataan UPDATE, DELETE, dan INSERT_SELECT yang didukung. Pernyataan kompleks seperti CREATE_INDEX dan operasi multi-tabel seperti DELETE dengan JOIN tidak didukung. Untuk daftar lengkap, lihat bagian Batasan pada ikhtisar.

• Pemeriksaan keterlambatan master-slave hanya tersedia untuk instans ApsaraDB RDS for MySQL.

Ajukan tiket perubahan tanpa penguncian

1. Masuk ke Konsol DMS V5.0.

2. Pada bilah navigasi atas, pilih Database Development > Data Change > Lockless Change.

   Dalam mode simple, arahkan pointer ke ikon di pojok kiri atas lalu pilih All Features > Database Development > Data Change > Lockless Change.

3. Konfigurasikan parameter dan klik Submit.

   Contoh berikut menggunakan instans yang dikelola dalam mode Security Collaboration. Untuk instans yang dikelola dalam mode Flexible Management atau Stable Change, hanya Database dan SQL Statements for Change yang wajib diisi.

   Parameter	Wajib	Deskripsi
   Database	Ya	Database tempat Anda ingin melakukan perubahan data. Pilih dari daftar drop-down Database, atau masukkan kata kunci untuk mencari. Anda harus memiliki izin perubahan data pada database yang dipilih. Untuk informasi lebih lanjut, lihat Lihat izin yang dimiliki.
   Execution Method	Ya	Siapa yang menjalankan perubahan setelah disetujui. Opsi: Ticket Submitter Executes Upon Approval, Automatically Execute Upon Approval, atau Last Approver Executes. Administrator DMS dapat mengubah metode eksekusi yang tersedia pada halaman Configuration Management di modul O&M. Untuk informasi lebih lanjut, lihat Configuration management.
   Affected Rows	Ya	Perkiraan jumlah baris yang terpengaruh. Untuk mendapatkan jumlah pasti, jalankan kueri COUNT pada tab SQLConsole sebelum mengajukan. Jika data terus ditulis secara berkelanjutan, hitung hanya baris yang sudah ada.
   SQL Statements for Change	Ya	Pernyataan DML yang akan dieksekusi: UPDATE, DELETE, atau INSERT_SELECT. Untuk melakukan perubahan skema tanpa penguncian, masukkan pernyataan DDL. Untuk informasi lebih lanjut, lihat Lakukan operasi DDL tanpa penguncian.
   SQL Statements for Rollback	Tidak	Pernyataan SQL yang dapat dieksekusi untuk mengembalikan perubahan data.
   SQL Text	Tidak	Hanya tersedia jika SQL Statements for Rollback diatur ke Text. Masukkan SQL rollback langsung di bidang ini.
   Attachment	Tidak	Tersedia hanya jika Pernyataan SQL untuk Rollback diatur ke Attachment. Unggah file TXT, ZIP, atau SQL yang berisi pernyataan SQL untuk rollback dengan ukuran maksimum 15 MB.
   Change Stakeholder	Tidak	Pengguna lain yang dapat melihat detail tiket dan berpartisipasi dalam proses persetujuan. Pengguna yang tidak tercantum di sini (kecuali administrator DMS dan administrator basis data (DBA)) tidak dapat mengakses tiket.
   Attachments	Tidak	File pendukung yang memberikan konteks tambahan untuk perubahan data.

4. Setelah mengajukan, Anda dapat mengonfigurasi pengaturan pemeriksaan awal (precheck) secara opsional:

   • Aktifkan pemeriksaan keterlambatan master-slave (hanya untuk ApsaraDB RDS for MySQL): Di bagian Basic Information pada panel detail tiket, klik chunk option. Di kotak dialog, atur ambang batas keterlambatan replikasi master-slave dalam satuan detik. Jika keterlambatan replikasi antara database primer dan sekunder melebihi ambang batas, DMS akan menangguhkan eksekusi SQL untuk melindungi alih bencana primer/sekunder.

   • Ubah pernyataan SQL jika pemeriksaan awal gagal: DMS menjalankan pemeriksaan awal secara otomatis setelah pengajuan. Jika pemeriksaan awal gagal, klik SQL Statements for Modification pada langkah Precheck untuk memperbarui pernyataan dan mengajukan ulang.

5. Klik Submit for Approval. Untuk melacak progres persetujuan, periksa langkah Approval pada panel detail tiket.

   • Mode Security Collaboration: Tiket dialihkan sesuai aturan persetujuan yang dikonfigurasi.

   • Mode Stable Change: Tiket disetujui secara otomatis.

6. Setelah tiket disetujui, klik Execute Change pada langkah Execute.

7. Konfigurasikan parameter eksekusi dan klik Confirm Execution.

   Parameter	Deskripsi
   Execution Strategy	Running immediately (default): memulai tugas segera setelah Anda mengklik Confirm Execution. Schedule: memulai tugas pada waktu tertentu. Waktu mulai aktual dapat berbeda hingga ±1 menit.
   Specify End Time	Menghentikan tugas pada waktu yang ditentukan terlepas dari apakah tugas telah selesai atau belum. Gunakan ini untuk mencegah tugas berjalan selama jam sibuk. Waktu akhir aktual dapat berbeda hingga ±1 menit.
   Primary/Secondary Node Check	Secara terus-menerus memantau sinkronisasi data antara instans primer dan sekunder untuk menjaga ketersediaan tinggi.
   Canary Release Type	Mengatur kecepatan eksekusi: No Canary Release menjalankan semua batch secara otomatis. Suspend after Executing the First SQL Statement berhenti setelah batch pertama — klik Retry untuk melanjutkan. Suspend after Executing an SQL Statement berhenti setelah setiap batch — klik Retry untuk melanjutkan ke batch berikutnya.

8. Monitor progres di langkah Execute. Klik Scheduling Logs di kolom Actions untuk melihat log penjadwalan terperinci.

   Tugas yang ditangguhkan dapat dijalankan ulang kapan saja.

Verifikasi perubahan

Setelah tugas selesai, konfirmasi bahwa perubahan telah diterapkan dengan benar:

1. Buka tab SQLConsole dan jalankan kueri pada tabel yang terpengaruh untuk memverifikasi bahwa baris yang diperbarui atau dihapus sesuai ekspektasi Anda.

2. Jika Anda perlu mengekspor hasilnya, lihat Export databases atau Export SQL result sets.

FAQ

• Apakah DML tanpa penguncian mendukung pernyataan SQL yang kompleks?

  Tidak. Fitur DML tanpa penguncian tidak mendukung pernyataan SQL kompleks seperti CREATE_INDEX atau operasi multi-tabel seperti pernyataan DELETE yang menyertakan operasi JOIN. Untuk daftar lengkap, lihat bagian Batasan pada ikhtisar.

• Q: Apakah perubahan tanpa penguncian DMS mendeteksi tabel terkunci atau blocking?

  A: Selama perubahan data tanpa penguncian, DMS membagi pernyataan SQL besar menjadi beberapa mini-batch untuk dieksekusi. Setelah setiap batch, sistem berhenti sejenak untuk menghindari pemanfaatan resource yang berkepanjangan. Selama eksekusi aktual, sistem tidak melakukan pemeriksaan awal terhadap kunci baris. MySQL tetap mengunci baris yang dimodifikasi, tetapi dampak keseluruhan minimal karena pendekatan 'mini-batch + pause'. Sistem tidak dapat menjamin operasi 100% bebas kunci. Untuk evolusi skema tanpa penguncian DMS, tabel temporary digunakan untuk mensimulasikan eksekusi pernyataan DDL guna memeriksa apakah operasi tersebut menyebabkan penguncian tabel atau blocking. Jika terdeteksi adanya penguncian tabel, validasi akan gagal dan muncul prompt.

• Q: Apakah validasi replay inkremental pada tugas perubahan tanpa penguncian DMS mendukung penyesuaian?

  A: Ya, mendukung. Penyesuaian validasi didukung. Pertama, pada halaman Operations Management > Configuration Management, cari dan aktifkan fitur 'Allow adjustment of lockless result change replay data validation ratio'.

  1. Akses tiket DDL yang sesuai melalui konsol.

  2. Pada bagian eksekusi, klik tombol Details.

  3. Temukan skrip yang sesuai, lalu klik Execution Progress.

  4. Di bagian bawah, Anda akan menemukan rasio validasi. Sesuaikan rasio validasi sesuai kebutuhan. Satuannya adalah permil (‰).

Langkah berikutnya

• Lakukan operasi DDL tanpa penguncian

• Kelola database pada tab SQLConsole

• Export databases

• Export SQL result sets

Referensi API

Operasi API berikut terkait dengan tiket perubahan tanpa penguncian:

• CreateFreeLockCorrectOrder

• ModifyDataCorrectExecSQL

• PauseDataCorrectSQLJob

• GetDataCorrectTaskDetail

• GetDataCorrectOrderDetail

• Query Data

• Database Export

• ModifyDataCorrectExecSQL - Modify the SQL script of a data change ticket

• PauseDataCorrectSQLJob - Pause the SQL task of a data change ticket

• GetDataCorrectTaskDetail - Retrieve details of a ticket task

• GetDataCorrectOrderDetail - Retrieve detailed information about a data change ticket