Praktik terbaik dan risiko konfigurasi oplog MongoDB - ApsaraDB for MongoDB

Konfigurasi parameter oplog yang tidak tepat untuk instans ApsaraDB for MongoDB dapat menyebabkan masalah seperti replikasi primary-secondary yang tidak normal dan mencegah pemulihan berdasarkan titik waktu (point-in-time restore). Pelajari cara mengonfigurasi parameter oplog dan pahami risiko yang terkait.

Ikhtisar

Pada instans set replika ApsaraDB for MongoDB, replikasi data dilakukan melalui oplog (operations log), yaitu sebuah capped collection bernama local.oplog.rs yang mencatat semua operasi yang memodifikasi dokumen. Karakteristik utamanya:

Operasi tulis pada node primary menghasilkan entri oplog. Node secondary mereplikasi dan memutar ulang entri tersebut secara asinkron agar tetap sinkron.
Operasi yang tidak memodifikasi dokumen atau yang gagal tidak menghasilkan entri oplog.
Entri oplog identik di seluruh anggota set replika. Penerapan suatu entri tidak mengubah entri itu sendiri.
Setiap operasi oplog bersifat idempoten — hasilnya sama baik diterapkan sekali maupun beberapa kali.
Entri oplog diurutkan berdasarkan waktu. Setiap entri memiliki bidang stempel waktu (ts) unik yang menggabungkan Stempel waktu UNIX dan penghitung incrementing, sehingga menjamin pengurutan yang ketat.
oplog window adalah rentang waktu antara entri oplog tertua dan terbaru. Node secondary hanya dapat melakukan sinkronisasi jika entri awal yang dibutuhkannya berada dalam oplog window sumber replikasi.
Node yang direstart atau baru ditambahkan juga bergantung pada entri oplog untuk bergabung ke dalam set replika. Jika entri yang dibutuhkan hilang, node tersebut masuk ke status RECOVERING yang tidak normal dengan error too stale to catch up.

Ukuran oplog

Pada ApsaraDB for MongoDB, ukuran oplog default adalah 10% dari total disk space. Misalnya, disk 500 GB menghasilkan oplog sebesar 50 GB. Oplog akan diskalakan secara otomatis saat Anda menambah kapasitas disk space.

Untuk menyesuaikan ukuran oplog, ubah parameter replication.oplogSizeMB di Konsol. Perubahan berlaku langsung tanpa perlu restart. Setel parameter database.

Untuk memeriksa ukuran tabel oplog:

Periksa metrik Disk Usage di halaman pemantauan Konsol. Pemantauan Node (sebelumnya Pemantauan Dasar).

Sambungkan menggunakan mongo shell atau mongosh dan jalankan perintah berikut.

rs.printReplicationInfo()

Contoh output:

configured oplog size:   192MB
log length start to end: 65422secs (18.17hrs)
oplog first event time:  Mon Jun 23 2014 17:47:18 GMT-0400 (EDT)
oplog last event time:   Tue Jun 24 2014 11:57:40 GMT-0400 (EDT)
now:                     Thu Jun 26 2014 14:24:39 GMT-0400 (EDT)

Output ini menunjukkan oplog sebesar 192 MB dengan oplog window selama 18 jam.

Periode retensi minimum oplog

MongoDB 4.4 memperkenalkan parameter storage.oplogMinRetentionHours untuk mengontrol periode retensi minimum oplog dan memastikan oplog window yang mencukupi.

Nilai default-nya adalah 0 (tidak ada retensi minimum; pembersihan dikontrol oleh ukuran oplog). Saat diatur, pembersihan oplog hanya terjadi jika kedua kondisi berikut terpenuhi:

Penggunaan oplog melebihi oplogSizeMB yang dikonfigurasi.
Stempel waktu entri lebih lama daripada periode retensi minimum oplog.

Sebelum oplog mencapai oplogSizeMB (misalnya, pada instans baru), oplog window aktual dapat melebihi periode retensi minimum yang dikonfigurasi, dan ukurannya hanya dibatasi oleh oplogSizeMB. Setelah mencapai oplogSizeMB, periode retensi mengatur pembersihan. Laju penulisan tinggi dapat menyebabkan oplog tumbuh jauh melebihi oplogSizeMB.

Untuk menyesuaikan periode retensi, ubah storage.oplogMinRetentionHours di Konsol. Perubahan berlaku langsung tanpa perlu restart. Setel parameter database.

Untuk melihat periode retensi, periksa metrik Oplog retention duration di halaman pemantauan Konsol. Pemantauan Node (sebelumnya Pemantauan Dasar).

Cadangan log ApsaraDB for MongoDB

Cadangan log untuk instans ApsaraDB for MongoDB menggunakan oplog. Proses khusus secara terus-menerus mengambil entri oplog terbaru dan mengalirkannya ke Object Storage Service (OSS) sebagai file cadangan log. Selama pemulihan berdasarkan titik waktu, file-file ini memutar ulang oplog.

Dalam beberapa kasus, holes dapat muncul dalam cadangan log, sehingga mencegah pemulihan berdasarkan titik waktu. Risiko.

Catatan

Hole cadangan log yang dijelaskan di sini berbeda dari oplog hole MongoDB.

Praktik terbaik

Konfigurasikan ukuran atau periode retensi oplog

Ukuran oplog default sudah cukup untuk sebagian besar workload. Pertimbangkan untuk menambahkannya dalam skenario berikut:

Pembaruan batch yang sering
Setiap pembaruan batch menghasilkan banyak operasi individual, sehingga menghasilkan banyak entri oplog.
Penyisipan dan penghapusan yang sering
Penggunaan disk tetap stabil, tetapi oplog mengumpulkan entri untuk operasi insert maupun delete.
Banyak pembaruan in-place pada dokumen yang sama
Pembaruan yang tidak menambah ukuran dokumen menghasilkan banyak entri oplog tanpa perubahan signifikan pada penggunaan disk.

Pertimbangkan untuk mengurangi ukuran oplog untuk:

Workload yang dominan membaca dan minim menulis.
Menyimpan data dingin.

Pertahankan oplog window minimal selama 24 jam atau lebih. Untuk skenario initial sync, oplog window harus mencakup waktu yang dibutuhkan untuk menyalin seluruh data, yang bergantung pada volume data, jumlah koleksi, dan spesifikasi instans. Dalam kasus seperti itu, oplog window yang lebih panjang mungkin diperlukan.

Pantau keterlambatan node secondary dan atur peringatan

Jika keterlambatan replikasi melebihi oplog window, node secondary akan masuk ke status error yang tidak dapat dipulihkan. Pantau keterlambatan replikasi dan segera submit a ticket jika keterlambatan terus meningkat.

Penyebab umum:

Latensi jaringan, kehilangan paket, atau gangguan koneksi.
Throughput disk node secondary menjadi bottleneck.
Workload tulis berat dikombinasikan dengan write concern {w:1}.
Cacat kernel yang menghambat replikasi primary-secondary di node secondary.
Alasan lain yang tidak tercantum.

Untuk memeriksa keterlambatan replikasi:

Lihat metrik Primary/Secondary Replication Latency di halaman pemantauan Konsol. Pemantauan Node (sebelumnya Pemantauan Dasar).

Sambungkan menggunakan mongo shell atau mongosh dan jalankan:

rs.printSecondaryReplicationInfo()

Contoh output:

source: m1.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
source: m2.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary

Kedua node secondary menunjukkan keterlambatan replikasi nol.

Buat peringatan Cloud Monitor untuk metrik Replication Latency menggunakan fitur Alarm Rules. Atur ambang batas ke 10 detik atau lebih. Setel aturan peringatan berbasis ambang batas.

Risiko

Dua penyebab utama menciptakan hole pada cadangan log:

Versi MongoDB sebelum 3.4

MongoDB 3.4 memperkenalkan penulisan no-op periodik untuk mendukung parameter preferensi baca maxStalenessSeconds (SERVER-23892). Penulisan no-op ini memajukan oplog selama periode idle, sehingga memungkinkan pengukuran keterlambatan yang akurat untuk node secondary.

Pada versi sebelum 3.4, oplog berhenti maju selama periode idle. Proses cadangan log tidak dapat mengambil data baru, sehingga menciptakan hole cadangan yang mencegah pemulihan berdasarkan titik waktu.

Laju penulisan tinggi dan oplog window pendek

Data dari instans ApsaraDB for MongoDB menunjukkan bahwa ketika laju pembuatan oplog mencapai sekitar 125 GB/jam hingga 165 GB/jam, proses cadangan log sangat berisiko tertinggal, sehingga menciptakan hole cadangan.

Perkirakan laju pembuatan dengan membagi ukuran oplog dengan oplog window. Misalnya, oplog 20 GB dengan window 0,06 jam menghasilkan sekitar 333,3 GB/jam.

Skenario umum:

Sinkronisasi data dengan DTS, mongoShake, atau alat serupa.
Batch besar operasi INSERT atau UPDATE dalam periode singkat.
Penyemaian data (impor massal cepat).
Pengujian stres.

Untuk mencegah hole cadangan akibat laju penulisan tinggi:

Terapkan Pembatasan laju pada alat sinkronisasi dengan menyesuaikan konkurensi atau ukuran batch.
Gunakan write concern {w:"majority"} alih-alih {w:1}.

Untuk workload dengan laju pembuatan oplog yang secara inheren tinggi:

Gunakan kluster sharded atau tambahkan shard untuk mendistribusikan laju pembuatan oplog.
Tingkatkan ukuran oplog atau periode retensi minimum untuk memberi proses cadangan lebih banyak buffer agar dapat mengejar selama periode trafik rendah.

ApsaraDB for MongoDB:Praktik terbaik dan risiko oplog