Praktik terbaik dan risiko konfigurasi oplog MongoDB - ApsaraDB for MongoDB

Parameter oplog yang dikonfigurasi secara 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 memainkan 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 satu kali maupun beberapa kali.
Entri oplog diurutkan berdasarkan waktu. Setiap entri memiliki bidang stempel waktu (ts) unik yang menggabungkan Stempel waktu UNIX dan penghitung inkremental, 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 tidak tersedia, 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 berukuran 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 Space Usage pada 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 berukuran 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 (tanpa retensi minimum; pembersihan dikendalikan 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 pada 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 memainkan 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 mengubah penggunaan disk secara signifikan.

Pertimbangkan untuk mengurangi ukuran oplog untuk:

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

Pertahankan oplog window minimal 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 konfigurasikan notifikasi

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 yang berat dikombinasikan dengan write concern {w:1}.
Cacat kernel yang menghambat replikasi primary-secondary pada node secondary.
Alasan lain yang tidak tercantum.

Untuk memeriksa keterlambatan replikasi:

Lihat metrik Primary/Secondary Replication Latency pada 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 notifikasi CloudMonitor untuk metrik Replication Latency menggunakan fitur Alarm Rules. Tetapkan ambang batas minimal 10 detik. Setel aturan notifikasi berbasis ambang batas.

Risiko

Dua penyebab utama yang 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 pada 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 pada 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 menggunakan 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