{"id":2791,"date":"2024-01-08T11:26:23","date_gmt":"2024-01-08T05:56:23","guid":{"rendered":"https:\/\/bentocase.tanshcreative.com\/?p=2791"},"modified":"2026-08-28T10:02:59","modified_gmt":"2026-08-28T10:02:59","slug":"jangan-pernah-jalankan-create-index-di-production-saat-jam-sibuk","status":"publish","type":"post","link":"https:\/\/agussyarif.my.id\/index.php\/2024\/01\/08\/jangan-pernah-jalankan-create-index-di-production-saat-jam-sibuk\/","title":{"rendered":"Jangan Pernah Jalankan CREATE INDEX di Production Saat Jam Sibuk! (Kecuali Tahu Rahasia Ini)"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Lebih dari dua tahun saya berkecimpung mengelola database<\/i> skala enterprise<\/i> dan PostgreSQL, jika ditanya apa salah satu penyebab downtime<\/i> konyol yang paling sering saya temui, jawabannya selalu sama: Mengeksekusi manipulasi Index di tabel raksasa (VLDB) pada jam operasional<\/b><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Niatnya baik: Aplikasi mulai melambat, lalu Backend Engineer<\/i> atau DBA<\/i> memutuskan untuk membuat indeks baru agar query<\/i> kembali ngebut. Mereka mengetik CREATE INDEX idx_baru ON tabel_transaksi(kolom_a);<\/code>, menekan Enter<\/i>, dan tiba-tiba… BAM!<\/b> Seluruh aplikasi berhenti merespons. Timeout<\/i> di mana-mana. Layanan pelanggan berteriak.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Apa yang sebenarnya terjadi di balik layar PostgreSQL (Internal Engine)? Mari kita bedah apa yang dilakukan Lock Manager<\/i>, dan bagaimana cara profesional menangani ini dengan status Zero Downtime<\/b>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Jebakan Batman: Standard Indexing Operations<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\u201cDi dalam memori PostgreSQL, terdapat komponen krusial bernama Lock Manager. Komponen ini bertugas mengevaluasi Conflict Matrix untuk memastikan konsistensi data.\u201d<\/blockquote>

Agus Syarif<\/p>Senior Database Engineer<\/span><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"Postgres\t\t\t\t\t\t\t\t\t\t\t
Gambar 2: Postgres Index Operation<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
  1. Tragedi CREATE INDEX<\/code> & REINDEX<\/code> (SHARE Lock)<\/b> Saat kita menjalankan perintah standar CREATE INDEX<\/code> atau REINDEX<\/code>, PostgreSQL akan mengambil SHARE Lock<\/b> pada tabel tersebut.
    • Apa yang lolos?<\/b> Aplikasi Reporting<\/i> yang melakukan SELECT<\/code> masih bisa membaca data.<\/li>
    • Apa yang tersumbat?<\/b> Aplikasi Transactional<\/i> yang melakukan UPDATE<\/code>, INSERT<\/code>, atau DELETE<\/code> akan diblokir total! Jika tabel tersebut berukuran ratusan Gigabyte dan proses indeks memakan waktu 30 menit, artinya aplikasi kita tidak bisa menerima transaksi baru selama setengah jam.<\/li><\/ul><\/li>
    • Bencana DROP INDEX<\/code> (ACCESS EXCLUSIVE Lock)<\/b> Banyak yang berpikir, “Ah, menghapus indeks kan cepat, hapus saja.”<\/i> Ini adalah jebakan paling mematikan. Perintah standar DROP INDEX<\/code> akan meminta ACCESS EXCLUSIVE Lock<\/b>.
      • Dampaknya?<\/b> Total Traffic Jam!<\/i> Lock ini memblokir SEMUANYA<\/b>. Baik aplikasi transaksional (UPDATE<\/code>\/INSERT<\/code>) maupun aplikasi pelaporan (SELECT<\/code>) akan dipaksa mengantre sampai indeks selesai dihapus.<\/li><\/ul><\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t
        Solusi : Kekuatan Sakti CONCURRENTLY<\/code><\/h5>

        Lalu, bagaimana cara Tech Giants<\/i> dan perusahaan Enterprise<\/i> melakukan pemeliharaan indeks tanpa mematikan layanan? Jawabannya ada pada satu kata ajaib: CONCURRENTLY<\/code><\/b>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t\t\t\t\t\t

        Dengan menambahkan keyword<\/i> ini (CREATE INDEX CONCURRENTLY<\/code> atau DROP INDEX CONCURRENTLY<\/code>), kita mengubah cara PostgreSQL meminta izin pada Lock Manager<\/i>. Alih-alih meminta lock yang agresif, PostgreSQL hanya akan meminta SHARE UPDATE EXCLUSIVE Lock<\/b>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t\t\t\t\t\t

        Mengapa ini sangat aman? Karena lock jenis ini sangat ramah. Ia mengizinkan ACCESS SHARE<\/code> (untuk SELECT<\/code>) dan ROW EXCLUSIVE<\/code> (untuk UPDATE<\/code>\/INSERT<\/code>) berjalan berdampingan tanpa saling memblokir. Aplikasi kita tetap hidup, transaksi tetap masuk, laporan tetap berjalan, sementara PostgreSQL diam-diam membangun indeks di latar belakang.<\/p>

        \u00a0<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t\t\t\t\t\t
        Berikut adalah Best Practices<\/i> yang wajib diterapkan pada Very Large Databases<\/i> (VLDB)<\/h5>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t
          \r\n
        • \r\n \r\n \t<\/i>\r\n <\/span>\r\n Haramkan Standard Indexing di Production: Jangan pernah menjalankan CREATE INDEX atau REINDEX biasa di tabel yang aktif menerima operasi tulis (Writes).<\/span>\r\n <\/li>\r\n
        • \r\n \r\n \t<\/i>\r\n <\/span>\r\n Gunakan CONCURRENTLY: Selalu biasakan menulis CREATE INDEX CONCURRENTLY atau REINDEX INDEX CONCURRENTLY. Proses ini memang memakan waktu lebih lama (karena PostgreSQL harus melakukan scanning tabel beberapa kali), tetapi ini adalah harga yang sangat murah untuk menjamin Zero Downtime. Biar lambat asal selamat!<\/span>\r\n <\/li>\r\n
        • \r\n \r\n \t<\/i>\r\n <\/span>\r\n Hati-hati dengan DROP INDEX: Menghapus indeks yang tidak terpakai itu bagus, tetapi ingat bahwa DROP INDEX biasa mengunci semuanya. Selalu gunakan DROP INDEX CONCURRENTLY di lingkungan live.<\/span>\r\n <\/li>\r\n
        • \r\n \r\n \t<\/i>\r\n <\/span>\r\n Waspada Index INVALID: Pembangunan indeks secara concurrent bisa saja gagal (misalnya karena deadlock ringan atau unique constraint violation). Jika gagal, PostgreSQL akan meninggalkan indeks berstatus 'INVALID'. Indeks ini tidak akan digunakan oleh query planner, tetapi tetap membebani proses INSERT\/UPDATE. Kita harus segera melakukan DROP INDEX CONCURRENTLY pada indeks yang invalid tersebut sebelum mencoba membuatnya lagi.<\/span>\r\n <\/li>\r\n <\/ul>\r\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
          \n\t\t\t\t\t\t\t\t\t
          Kesimpulan<\/h5>

          Mengelola database bukan hanya soal membuat query<\/i> berjalan cepat, tapi juga tentang memahami bagaimana internal engine<\/i> bekerja (khususnya mekanisme antrean Locking<\/i>). Memahami matriks konflik pada PostgreSQL adalah garis batas yang membedakan antara Engineer amatir dan Profesional Sejati.<\/p>

          Punya pengalaman horor terkait locking<\/i> atau indexing<\/i> di PostgreSQL? Mari berdiskusi di kolom komentar! \ud83d\udc47<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

          \n\t\t\t\t\t
          \n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

          Lebih dari dua tahun saya berkecimpung mengelola database skala enterprise dan PostgreSQL, jika ditanya apa salah satu penyebab downtime konyol yang paling sering saya temui, jawabannya selalu sama: Mengeksekusi manipulasi Index di tabel raksasa (VLDB) pada jam operasional Niatnya baik: Aplikasi mulai melambat, lalu Backend Engineer atau DBA memutuskan untuk membuat indeks baru agar query […]<\/p>\n","protected":false},"author":1,"featured_media":4321,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[45],"tags":[52,50,46,49,51,43,48,53,54,47],"class_list":["post-2791","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-index","tag-agussyarif","tag-backenddeveloper","tag-databaseadministration","tag-dba","tag-highavailability","tag-postgresql","tag-softwareengineering","tag-sql","tag-systemarchitecture","tag-techtips"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/posts\/2791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/comments?post=2791"}],"version-history":[{"count":30,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/posts\/2791\/revisions"}],"predecessor-version":[{"id":4392,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/posts\/2791\/revisions\/4392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/media\/4321"}],"wp:attachment":[{"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/media?parent=2791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/categories?post=2791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agussyarif.my.id\/index.php\/wp-json\/wp\/v2\/tags?post=2791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}