Perintah MySQL FLUSH: Referensi Lengkap untuk Administrator Database

Pernyataan `FLUSH` MySQL memaksa server untuk memuat ulang cache internal, menutup dan membuka kembali file log, mereset penghitung status, dan menyinkronkan status dalam memori dengan struktur di disk — semuanya tanpa memerlukan restart server. Hal ini menjadikannya salah satu keluarga perintah yang paling kritis secara operasional yang tersedia bagi administrator database.

Memahami setiap varian, cakupan tepatnya, dan efek sampingnya bukanlah pengetahuan opsional untuk lingkungan produksi. Menyalahgunakan `FLUSH TABLES WITH READ LOCK` pada sistem OLTP yang sibuk, misalnya, dapat menyebabkan stall penulisan di seluruh aplikasi yang berlangsung selama beberapa menit. Referensi ini mencakup setiap varian `FLUSH` yang signifikan, termasuk perbedaan perilaku di MySQL 5.7 dan 8.x, implikasi khusus InnoDB, bahaya replikasi, dan persyaratan hak akses.

Mengapa Perintah FLUSH Penting dalam Produksi

Server MySQL mempertahankan berbagai struktur dalam memori untuk mempercepat operasi: cache koneksi host, cache tabel grant, deskriptor tabel terbuka, cache hasil kueri, dan buffer pool mesin penyimpanan. Cache ini bersifat otoritatif selama runtime. Ketika administrator membuat perubahan di luar jalur — mengedit tabel grant secara langsung dengan `INSERT`/`UPDATE`, merotasi file log di tingkat OS, atau memindahkan file `.ibd` — tampilan dalam memori server menjadi usang. Perintah `FLUSH` merekonsiliasi perbedaan tersebut.

Kategori operasional utama di mana `FLUSH` sangat diperlukan:

• Propagasi hak akses tanpa me-restart `mysqld`
• Backup online yang konsisten menggunakan snapshot berbasis kunci
• Rotasi log yang terintegrasi dengan `logrotate` atau skrip kustom
• Reset baseline performa sebelum benchmarking
• Invalidasi cache host setelah perubahan topologi jaringan
• Penegakan durabilitas mesin penyimpanan sebelum jendela pemeliharaan

Hak Akses yang Diperlukan

Sebagian besar varian `FLUSH` memerlukan hak akses `RELOAD`. `FLUSH TABLES WITH READ LOCK` juga memerlukan `LOCK TABLES`. Di MySQL 8.0+, hak akses dinamis yang lebih terperinci (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`) diperkenalkan, memungkinkan kontrol akses yang lebih granular tanpa memberikan hak akses `RELOAD` yang luas. Selalu terapkan prinsip hak akses minimal saat menetapkan ini ke akun aplikasi atau pemantauan.

Referensi Lengkap: Perintah MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Perintah ini memuat ulang tabel grant dalam memori dari database sistem `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). Server membaca tabel-tabel ini saat startup dan menyimpannya dalam cache. DML langsung apa pun (`INSERT`, `UPDATE`, `DELETE`) terhadap tabel-tabel tersebut melewati mekanisme `GRANT`/`REVOKE` yang normal, membuat cache menjadi usang hingga `FLUSH PRIVILEGES` dieksekusi.

Kapan digunakan:

• Setelah mengedit tabel grant secara manual dengan SQL mentah daripada pernyataan `GRANT`/`REVOKE`
• Setelah mengimpor mysqldump yang menyertakan insert langsung ke `mysql.user`
• Setelah memulihkan backup parsial dari skema `mysql`

Nuansa kritis: Saat Anda menggunakan pernyataan `GRANT`, `REVOKE`, `CREATE USER`, atau `DROP USER`, MySQL secara otomatis memuat ulang tabel grant. `FLUSH PRIVILEGES` hanya diperlukan ketika Anda melewati pernyataan-pernyataan tersebut sepenuhnya. Menjalankannya secara tidak perlu tidak berbahaya tetapi menambahkan kunci singkat pada cache tabel grant.

Catatan replikasi: `FLUSH PRIVILEGES` ditulis ke binary log dan direplikasi ke replika secara default. Ini umumnya merupakan perilaku yang diinginkan saat mengelola pengguna di seluruh topologi replikasi.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Perintah ini menutup semua deskriptor file tabel yang sedang terbuka dan menghapusnya dari cache definisi tabel (TDC). Pada akses berikutnya, MySQL membuka kembali file tabel dari disk. Ini sangat penting setelah manipulasi file di luar jalur.

Kapan digunakan:

• Setelah menyalin atau mengganti file `.frm`, `.ibd`, atau `.MYD`/`.MYI` di tingkat OS
• Untuk melepaskan memori cache tabel pada server dengan nilai `table_open_cache` yang sangat besar
• Sebagai prasyarat sebelum menggunakan `IMPORT TABLESPACE` dalam operasi tablespace transportable InnoDB

Pertimbangan performa: Pada server dengan ribuan tabel terbuka, `FLUSH TABLES` memperoleh kunci global secara singkat. Pada sistem dengan konkurensi tinggi, ini dapat menyebabkan lonjakan latensi yang terlihat. Lebih baik gunakan bentuk spesifik tabel (`FLUSH TABLES tbl1, tbl2`) untuk meminimalkan dampak.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Ini adalah salah satu varian `FLUSH` yang paling kuat dan berpotensi mengganggu. Ini menutup semua tabel terbuka, memflush cache kueri, dan memperoleh kunci baca global yang mencegah operasi penulisan apa pun di semua database. Kunci tetap berlaku hingga `UNLOCK TABLES` dikeluarkan atau sesi berakhir.

Kapan digunakan:

• Sebelum mengambil backup fisik dengan alat seperti `mysqldump –single-transaction` (untuk database khusus InnoDB, ini tidak diperlukan — lihat di bawah)
• Sebelum menggunakan `mysqlpump` atau `xtrabackup` di lingkungan non-InnoDB
• Untuk membuat snapshot konsisten point-in-time di seluruh mesin penyimpanan campuran (InnoDB + MyISAM)

Jebakan kritis — database khusus InnoDB: Untuk database yang menggunakan tabel InnoDB secara eksklusif, `FTWRL` hampir tidak pernah diperlukan. `mysqldump –single-transaction` membuka transaksi repeatable-read yang menyediakan snapshot konsisten tanpa memblokir penulisan. Menggunakan `FTWRL` dalam skenario ini menyebabkan stall penulisan yang tidak perlu.

Bahaya replikasi: Jika `FTWRL` dieksekusi pada replika, ini memblokir thread SQL applier, menyebabkan lag replikasi terakumulasi selama durasi kunci. Selalu pantau `Seconds_Behind_Master` setelah melepaskan kunci.

Interaksi metadata lock: Di MySQL 5.7+, `FTWRL` menunggu semua transaksi aktif selesai sebelum memperoleh kunci global. Pada server yang sibuk dengan transaksi yang berjalan lama, penantian ini bisa tidak terbatas. Gunakan `SHOW PROCESSLIST` untuk mengidentifikasi transaksi yang memblokir sebelum mengeksekusi `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL mempertahankan cache host yang mencatat riwayat upaya koneksi, termasuk jumlah autentikasi yang gagal. Ketika sebuah host mengakumulasi lebih dari `max_connect_errors` koneksi gagal berturut-turut, MySQL memblokir semua koneksi berikutnya dari host tersebut hingga entri cache dihapus.

Kapan digunakan:

• Ketika host klien yang sah diblokir karena melebihi `max_connect_errors`
• Setelah menyelesaikan masalah jaringan yang menyebabkan kegagalan koneksi TCP berulang
• Setelah mengubah catatan DNS yang memengaruhi cara server me-resolve nama host klien

Alternatif MySQL 8.0: Di MySQL 8.0+, Anda juga dapat memotong tabel cache host secara langsung:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Ini mencapai hasil yang sama dan lebih transparan dalam skrip otomatis.

Konfigurasi proaktif: Daripada mengandalkan `FLUSH HOSTS` secara reaktif, atur `max_connect_errors` ke nilai yang lebih tinggi (misalnya, `10000`) atau atur `host_cache_size = 0` untuk menonaktifkan cache host sepenuhnya pada jaringan internal tepercaya.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Mereset sebagian besar variabel status sesi dan global ke nol. Ini mencakup penghitung seperti `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected`, dan ratusan lainnya yang diekspos melalui `SHOW STATUS` atau `performance_schema`.

Kapan digunakan:

• Segera sebelum benchmark terkontrol untuk menetapkan baseline pengukuran yang bersih
• Setelah perubahan konfigurasi (misalnya, menyesuaikan `innodb_buffer_pool_size`) untuk mengisolasi efek pada metrik I/O
• Saat membuat skrip pengujian regresi performa yang membandingkan delta penghitung sebelum/sesudah

Batasan penting: `FLUSH STATUS` tidak mereset semua penghitung. Variabel seperti `Uptime`, `Uptime_since_flush_status`, dan metrik internal InnoDB tertentu tidak terpengaruh. Untuk pemantauan komprehensif, gunakan tabel `performance_schema` secara langsung, yang menawarkan granularitas per-thread dan per-event yang tidak dapat disediakan oleh `FLUSH STATUS`.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` menutup dan membuka kembali semua file log server. MySQL 5.7.2+ memperkenalkan kemampuan untuk memflush jenis log tertentu secara individual, yang jauh lebih disukai dalam produksi.

Kapan digunakan:

• Sebagai bagian dari skrip post-rotate `logrotate` untuk memberi sinyal MySQL agar membuka file log baru setelah yang lama telah dirotasi
• Untuk memaksa file binary log baru (setara dengan `FLUSH BINARY LOGS`), yang menaikkan nomor urut binary log
• Sebelum mengarsipkan log lama untuk memastikan semua penulisan yang tertunda di-flush ke disk

Spesifik binary log: `FLUSH BINARY LOGS` membuat file binary log baru dan menulis `Rotate_event` ke file lama. Ini adalah cara yang benar untuk mensegmentasi binary log untuk pengarsipan point-in-time recovery (PITR). File binary log saat ini dan posisinya dapat dikonfirmasi dengan `SHOW MASTER STATUS` (MySQL 5.7) atau `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Contoh integrasi logrotate:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Peringatan deprecation: Cache kueri MySQL sudah deprecated di MySQL 5.7.20 dan dihapus sepenuhnya di MySQL 8.0. Jika Anda menjalankan MySQL 8.0 atau lebih baru, perintah ini tidak ada.

Untuk lingkungan MySQL 5.6/5.7 di mana cache kueri masih aktif:

• `FLUSH QUERY CACHE` melakukan defragmentasi memori cache kueri tanpa menghapus hasil yang di-cache
• `RESET QUERY CACHE` menghapus semua hasil kueri yang di-cache sepenuhnya

Kapan digunakan (hanya MySQL 5.6/5.7):

• Setelah modifikasi data batch besar yang membatalkan sebagian besar hasil yang di-cache
• Ketika `Qcache_free_blocks` tinggi relatif terhadap `Qcache_total_blocks`, menunjukkan fragmentasi
• Sebelum menonaktifkan cache kueri (`SET GLOBAL query_cache_size = 0`) untuk melepaskan memori dengan bersih

Alternatif modern: Di MySQL 8.0+, gunakan pemanasan buffer pool InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) dan `performance_schema` untuk analisis tingkat kueri sebagai gantinya.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Mereset penghitung sumber daya per-pengguna yang dilacak oleh pembatasan laju bawaan MySQL. Penghitung ini memberlakukan batas yang ditentukan dalam pernyataan `CREATE USER` atau `GRANT`:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Kapan digunakan:

• Ketika pengguna telah menghabiskan kuota kueri per jam mereka dan memerlukan akses yang dipulihkan segera sebelum penghitung direset secara alami pada batas jam berikutnya
• Setelah meningkatkan batas sumber daya pengguna dan ingin batas baru berlaku segera
• Selama pengembangan/pengujian untuk mereset kuota antar sesi pengujian

Catatan: Perintah ini mereset penghitung untuk semua pengguna secara bersamaan. Tidak ada granularitas per-pengguna di tingkat `FLUSH`. Jika Anda perlu mereset penghitung satu pengguna, satu-satunya opsi adalah memodifikasi akun mereka dengan `ALTER USER` dan kemudian mengeluarkan `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Memaksa semua mesin penyimpanan untuk memflush buffer penulisan yang tertunda ke file log masing-masing. Untuk InnoDB, ini berarti memflush buffer redo log (`innodb_log_buffer_size`) ke file redo log InnoDB di disk.

Kapan digunakan:

• Sebelum mengambil backup cold dari file data InnoDB untuk memastikan konsistensi redo log
• Selama pemecahan masalah mesin penyimpanan untuk menyingkirkan inkonsistensi data terkait buffer
• Sebagai bagian dari daftar periksa pra-pemeliharaan sebelum menghentikan layanan MySQL

Konteks durabilitas InnoDB: Pengaturan `innodb_flush_log_at_trx_commit` InnoDB mengontrol seberapa agresif redo log di-flush pada setiap commit transaksi. `FLUSH ENGINE LOGS` adalah override manual yang memaksa flush terlepas dari pengaturan tersebut. Ini berguna dalam skenario di mana Anda memerlukan checkpoint durabilitas yang terjamin tanpa melakukan commit transaksi.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Memuat ulang file kunci enkripsi DES yang ditentukan oleh opsi startup server `–des-key-file`. File kunci ini digunakan oleh fungsi `DES_ENCRYPT()` dan `DES_DECRYPT()`.

Peringatan deprecation: Fungsi `DES_ENCRYPT()` dan `DES_DECRYPT()` sudah deprecated di MySQL 5.7.6 dan dihapus di MySQL 8.0. Perintah ini oleh karena itu hanya relevan pada instalasi MySQL 5.6/5.7 lama.

Alternatif enkripsi modern: Gunakan enkripsi data-at-rest native MySQL (enkripsi tablespace InnoDB melalui `ALTER TABLE … ENCRYPTION='Y'`) dikombinasikan dengan plugin MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) untuk kebutuhan enkripsi produksi.

Tabel Perbandingan Perintah FLUSH

Replikasi dan FLUSH: Apa yang Direplikasi

Tidak semua perintah `FLUSH` direplikasi ke server replika. Memahami perbedaan ini sangat penting dalam topologi HA dan replikasi:

Direplikasi secara default:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (ditulis sebagai `Rotate_event` dalam binary log)
• `FLUSH USER_RESOURCES`

Tidak direplikasi (lokal sesi atau dikecualikan secara eksplisit):

• `FLUSH TABLES WITH READ LOCK` — tidak pernah ditulis ke binary log
• `FLUSH STATUS` — hanya memengaruhi penghitung server lokal
• `FLUSH HOSTS` — hanya cache host lokal
• `FLUSH ENGINE LOGS` — hanya status mesin lokal

Untuk mencegah perintah `FLUSH` tertentu direplikasi meskipun normalnya akan direplikasi, gunakan modifier `LOCAL` atau `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Ini berguna saat mengelola hak akses secara independen pada replika (misalnya, menambahkan pengguna pemantauan yang tidak boleh ada di primary).

Mengotomatiskan Operasi FLUSH dengan mysqladmin

Banyak operasi `FLUSH` dapat dipicu dari shell tanpa membuka sesi klien MySQL, yang berguna dalam cron job dan skrip pemeliharaan:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

Untuk lingkungan produksi, simpan kredensial di `~/.my.cnf` dengan `chmod 600` daripada meneruskan `-p` secara interaktif, atau gunakan mekanisme `–login-path` MySQL dengan `mysql_config_editor`.

Pertimbangan Lingkungan Hosting

Kemampuan untuk mengeksekusi perintah `FLUSH` sangat bergantung pada lingkungan hosting dan tingkat akses database yang diberikan. Pada paket VPS Hosting, Anda biasanya memiliki akses root penuh ke instans MySQL, yang berarti Anda dapat mengeksekusi varian `FLUSH` apa pun, memodifikasi `my.cnf`, dan mengelola rotasi log secara langsung. Ini adalah lingkungan minimum yang direkomendasikan untuk pekerjaan administrasi database yang serius.

Pada Shared Web Hosting, akses database biasanya dibatasi untuk pengguna tanpa hak akses tanpa hak akses `RELOAD`, membuat sebagian besar perintah `FLUSH` tidak tersedia. Jika aplikasi Anda memerlukan manajemen hak akses, kontrol rotasi log, atau snapshot yang konsisten untuk backup, lingkungan shared akan menjadi hambatan keras.

Untuk beban kerja database dengan throughput tinggi — terutama yang melibatkan operasi `FLUSH ENGINE LOGS` yang sering atau buffer pool InnoDB yang besar — Dedicated Servers menyediakan throughput I/O dan bandwidth memori yang diperlukan untuk membuat operasi ini tidak mengganggu. `FLUSH TABLES WITH READ LOCK` pada server dengan 256 GB data buffer pool membutuhkan waktu yang terukur lebih lama dibandingkan pada server dengan penyimpanan NVMe cepat dan saluran I/O khusus.

Jika Anda mengelola instans MySQL bersama panel kontrol web, VPS dengan cPanel menyediakan lingkungan terkelola di mana beberapa operasi `FLUSH` (terutama rotasi log dan reload hak akses) ditangani secara otomatis oleh lapisan manajemen database panel kontrol, mengurangi kebutuhan intervensi manual.

Untuk aplikasi berbasis database yang memerlukan ekosistem panel kontrol penuh, meninjau VPS Control Panels yang tersedia akan membantu mengidentifikasi panel mana yang paling terintegrasi dengan alur kerja administrasi MySQL Anda.

Daftar Periksa Poin Utama

Gunakan matriks keputusan ini sebelum mengeksekusi perintah `FLUSH` apa pun dalam produksi:

• Sebelum `FLUSH TABLES WITH READ LOCK`: Konfirmasi tidak ada transaksi yang berjalan lama yang aktif (`SHOW PROCESSLIST`). Verifikasi apakah database Anda hanya InnoDB — jika ya, gunakan `–single-transaction` sebagai gantinya.
• Sebelum `FLUSH PRIVILEGES`: Konfirmasi Anda menggunakan DML mentah pada tabel grant. Jika Anda menggunakan `GRANT`/`REVOKE`, perintah ini redundan.
• Sebelum `FLUSH LOGS`: Pastikan skrip rotasi log Anda telah memindahkan/mengganti nama file log lama sebelum memberi sinyal MySQL untuk membukanya kembali.
• Sebelum `FLUSH HOSTS`: Identifikasi akar penyebab kegagalan koneksi terlebih dahulu. Memflush cache host tanpa memperbaiki masalah yang mendasarinya akan mengakibatkan host diblokir lagi.
• Di MySQL 8.0+: Hapus panggilan `FLUSH QUERY CACHE` atau `FLUSH DES_KEY_FILE` dari skrip — perintah ini tidak ada dan akan menyebabkan error.
• Dalam topologi replikasi: Gunakan `FLUSH LOCAL` atau `FLUSH NO_WRITE_TO_BINLOG` ketika operasi tidak boleh merambat ke replika.
• Untuk otomatisasi: Gunakan perintah `mysqladmin flush-*` dalam skrip daripada membuka sesi klien MySQL penuh.
• Audit hak akses: Lebih baik gunakan hak akses dinamis MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES`, dll.) daripada hak akses `RELOAD` yang luas untuk akun pemantauan dan backup.

Pertanyaan yang Sering Diajukan

Apakah FLUSH PRIVILEGES perlu dijalankan setelah setiap pernyataan GRANT atau REVOKE?

Tidak. `GRANT`, `REVOKE`, `CREATE USER`, dan `DROP USER` secara otomatis memuat ulang tabel grant dalam memori. `FLUSH PRIVILEGES` hanya diperlukan setelah modifikasi DML langsung pada tabel sistem `mysql` (misalnya, `UPDATE mysql.user SET …`).

Apakah FLUSH TABLES WITH READ LOCK dapat menyebabkan downtime aplikasi?

Ya. Ini memperoleh kunci tulis global yang memblokir semua operasi `INSERT`, `UPDATE`, `DELETE`, dan DDL di setiap database pada server. Pada sistem OLTP yang sibuk, bahkan beberapa detik `FTWRL` dapat menghabiskan connection pool dan menyebabkan error aplikasi yang beruntun. Untuk database khusus InnoDB, gunakan `mysqldump –single-transaction` untuk menghindari hal ini sepenuhnya.

Apakah FLUSH STATUS sama dengan me-restart server MySQL untuk tujuan benchmarking?

Tidak. `FLUSH STATUS` mereset sebagian besar penghitung status tetapi tidak membersihkan buffer pool InnoDB, mereset status koneksi, atau memengaruhi statistik `performance_schema` yang terakumulasi. Untuk benchmark clean-slate yang sesungguhnya, restart server dikombinasikan dengan pembersihan buffer pool lebih akurat, meskipun tidak praktis dalam produksi.

Mengapa FLUSH HOSTS tidak ada sebagai perintah mandiri dalam beberapa dokumentasi MySQL 8.0?

`FLUSH HOSTS` masih berfungsi di MySQL 8.0, tetapi metode yang lebih disukai adalah `TRUNCATE TABLE performance_schema.host_cache`, yang lebih eksplisit dan dapat dieksekusi tanpa hak akses `RELOAD` jika pengguna memiliki `DELETE` pada `performance_schema`. Keduanya mencapai hasil yang sama.

Apa yang terjadi jika FLUSH ENGINE LOGS dieksekusi selama beban tulis puncak pada InnoDB?

Ini memaksa flush sinkron dari buffer log InnoDB ke disk, yang dapat menyebabkan stall penulisan singkat jika file redo log berada pada penyimpanan yang lambat. Pada server berbasis NVMe, dampaknya biasanya sub-milidetik. Pada disk berputar atau penyimpanan SAN yang sangat terbebani, ini dapat menyebabkan lonjakan latensi yang terlihat. Jadwalkan operasi ini selama jendela lalu lintas rendah jika memungkinkan.