konfigurasi parameter oplog - ApsaraDB for MongoDB

Parameter oplog yang dikonfigurasi secara tidak tepat untuk instans ApsaraDB for MongoDB dapat menyebabkan masalah pada replikasi primary-secondary dan mencegah pemulihan berdasarkan titik waktu (point-in-time restore). Topik ini menjelaskan cara mengonfigurasi parameter oplog serta risiko yang terkait.

Ikhtisar

Instans set replika ApsaraDB for MongoDB menggunakan operations log (oplog) untuk replikasi primary-secondary. Tabel oplog, local.oplog.rs, merupakan capped collection khusus yang menyimpan semua operasi yang memodifikasi dokumen dalam database. Oplog memiliki atribut dasar berikut:

Dalam sebuah replica set, operasi tulis hanya terjadi pada node primary dan menghasilkan entri oplog yang sesuai. Node secondary kemudian mereplikasi dan memutar ulang entri tersebut secara asinkron untuk mempertahankan status replikasi.
Jika suatu operasi tidak memodifikasi dokumen apa pun atau gagal karena alasan apa pun, operasi tersebut tidak menghasilkan catatan oplog.
Catatan oplog identik di seluruh node dalam sebuah replica set. Memutar ulang suatu entri tidak mengubah catatan tersebut dalam tabel oplog.
Setiap operasi dalam tabel oplog bersifat idempoten. Artinya, hasilnya tetap sama baik catatan oplog diputar ulang satu kali maupun beberapa kali.
Catatan oplog sensitif terhadap waktu. Setiap operasi dalam oplog memiliki bidang stempel waktu (ts) unik yang terdiri dari stempel waktu UNIX dan penghitung. Hal ini memungkinkan Anda menentukan urutan dua catatan oplog apa pun.
oplog window adalah selisih waktu antara catatan tertua dan terbaru dalam tabel oplog. Replikasi primary-secondary bergantung pada jendela ini. Node secondary hanya dapat melakukan sinkronisasi dengan benar jika menemukan catatan oplog yang diperlukan dalam oplog window dari sumber sinkronisasi.
Ketika node secondary melakukan restart atau node baru ditambahkan, node tersebut mengandalkan catatan oplog untuk memastikan apakah ia dapat bergabung ke dalam replica set. Jika tidak menemukan catatan oplog yang diperlukan pada sumber sinkronisasi, node tersebut memasuki status abnormal RECOVERING dan melaporkan error too stale to catch up.

Ukuran oplog

Pada ApsaraDB for MongoDB, ukuran oplog default adalah 10% dari disk space instans. Misalnya, jika instans Anda memiliki disk space 500 GB, ukuran oplog-nya adalah 50 GB. Ukuran oplog akan menyesuaikan secara otomatis saat Anda memperluas disk space.

Anda dapat menyesuaikan ukuran oplog dengan mengubah parameter replication.oplogSizeMB di Konsol. Perubahan berlaku segera setelah Anda mengirimkannya dan tidak memerlukan restart. Untuk informasi lebih lanjut tentang cara mengubah parameter konfigurasi, lihat Setel parameter database.

Anda dapat memeriksa ukuran aktual tabel oplog dengan dua cara:

Anda dapat memeriksa metrik Disk Usage pada halaman informasi pemantauan di Konsol. Untuk informasi lebih lanjut, lihat Node Monitoring (sebelumnya Basic Monitoring).
Sambungkan ke instans menggunakan tool client, seperti mongo shell atau mongosh. Kemudian, Anda dapat menjalankan perintah berikut untuk melihat ukuran tabel oplog dan oplog window.
```
rs.printReplicationInfo()
```
Berikut ini contoh output-nya:
```
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)
```
Pada contoh tersebut, ukuran oplog sekitar 192 MB, dan oplog window-nya sekitar 18 jam.

Periode retensi minimum oplog

Mulai dari MongoDB 4.4, item konfigurasi storage.oplogMinRetentionHours didukung. Item ini memungkinkan Anda mengontrol langsung periode retensi oplog untuk memastikan oplog window yang mencukupi.

Secara default, item konfigurasi ini diatur ke 0, yang berarti tidak ada periode retensi minimum oplog yang ditetapkan. Dalam kasus ini, pembersihan oplog dikontrol oleh ukuran oplog. Jika Anda mengatur item konfigurasi ini, pembersihan oplog hanya terjadi ketika kedua kondisi berikut terpenuhi:

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

Jika oplog belum mencapai oplogSizeMB yang dikonfigurasi—misalnya, saat instans baru diinisialisasi dan belum banyak data yang ditulis—oplog window aktual mungkin melebihi periode retensi minimum yang dikonfigurasi. Dalam kasus ini, ukuran tabel oplog hanya dibatasi oleh oplogSizeMB. Setelah oplogSizeMB yang dikonfigurasi tercapai, ukuran tabel oplog kemudian dibatasi oleh periode retensi minimum. Jika entri oplog dihasilkan dengan cepat, total ukuran oplog bisa jauh lebih besar daripada oplogSizeMB yang dikonfigurasi.

Anda dapat menyesuaikan periode retensi oplog dengan mengubah parameter storage.oplogMinRetentionHours di Konsol. Perubahan berlaku segera setelah Anda mengirimkannya dan tidak memerlukan restart. Untuk informasi lebih lanjut tentang cara mengubah parameter konfigurasi, lihat Setel parameter database.

Untuk melihat periode retensi oplog, Anda dapat memeriksa metrik Retention Period of Oplogs pada halaman pemantauan di Konsol. Untuk informasi lebih lanjut, lihat Node Monitoring (sebelumnya Basic Monitoring).

Cadangan log ApsaraDB for MongoDB

Cadangan log untuk semua instans ApsaraDB for MongoDB didasarkan pada oplog. Proses layanan kontrol secara terus-menerus menarik catatan oplog terbaru dari instans dan melakukan unggahan streaming ke OSS. Proses ini menghasilkan serangkaian file cadangan log. Selama pemulihan berdasarkan titik waktu, file-file cadangan log ini digunakan untuk memutar ulang oplog.

Dalam kasus khusus, holes dapat terjadi pada cadangan log, yang dapat mencegah pemulihan berdasarkan titik waktu. Untuk informasi lebih lanjut, lihat Risiko.

Catatan

Hole cadangan log yang disebutkan dalam topik ini berbeda dengan istilah oplog hole dalam MongoDB.

Praktik terbaik

Konfigurasi ukuran dan retensi oplog

Anda biasanya dapat mempertahankan ukuran oplog default. Namun, untuk workload dalam skenario berikut, Anda harus menambah ukuran oplog:

Pembaruan batch dokumen yang sering
Setiap operasi pembaruan batch menghasilkan banyak operasi pembaruan untuk dokumen individual. Hal ini menghasilkan banyak catatan oplog.
Operasi insert dan delete yang berulang
Jika dokumen dihapus beberapa waktu setelah dimasukkan, disk space database tidak meningkat secara signifikan, tetapi oplog akan berisi banyak catatan terkait.
Banyak pembaruan in-place pada dokumen yang sama
Jika sebagian besar operasi dalam skenario bisnis Anda adalah pembaruan yang tidak menambah ukuran dokumen, pembaruan tersebut akan menghasilkan banyak catatan oplog, tetapi volume data pada disk tidak berubah secara signifikan.

Jika workload Anda termasuk dalam tipe berikut, Anda juga dapat mengurangi ukuran oplog sesuai kebutuhan untuk memanfaatkan disk space secara lebih optimal:

Workload yang banyak membaca dan sedikit menulis.
Penyimpanan data dingin.

Baik Anda mengatur ukuran oplog maupun periode retensi oplog, Anda harus mempertahankan oplog window instans MongoDB Anda minimal 24 jam. Dalam beberapa skenario yang memerlukan initial sync tambahan, oplog window harus mencakup durasi yang dibutuhkan node untuk menyelesaikan sinkronisasi data. Durasi ini biasanya bergantung pada faktor-faktor seperti total volume data instans, jumlah total database dan koleksi, serta tipe instans. Dalam kasus-kasus tersebut, oplog window mungkin perlu lebih panjang.

Pantau lag replikasi dan atur peringatan

Jika terjadi latensi replikasi pada node secondary dan terus meningkat hingga melebihi oplog window yang dikonfigurasi, node tersebut akan memasuki status abnormal dan tidak dapat dipulihkan. Oleh karena itu, Anda harus memantau latensi node secondary dalam instans MongoDB Anda. Jika latensi terus meningkat, segera kirim tiket untuk meminta bantuan dari dukungan teknis Alibaba Cloud.

Ada banyak alasan keterlambatan node secondary, termasuk:

Latensi jaringan, kehilangan paket, atau gangguan.
Throughput disk node secondary telah mencapai bottleneck.
Write concern {w:1} dengan workload tulis yang berat.
Beberapa bug kernel menghambat replikasi primary-secondary pada node secondary.
Alasan lainnya.

Anda dapat memeriksa keterlambatan node secondary dengan dua cara:

Anda dapat memeriksa metrik Primary/Secondary Replication Latency pada halaman pemantauan di Konsol. Untuk informasi lebih lanjut, lihat Node Monitoring (sebelumnya Basic Monitoring).

Sambungkan ke instans menggunakan tool client, seperti mongo shell atau mongosh. Kemudian, Anda dapat menjalankan perintah berikut untuk melihat keterlambatan node secondary.

rs.printSecondaryReplicationInfo()

Berikut ini contoh output-nya:

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

Pada contoh ini, kedua node secondary tidak mengalami keterlambatan.

Di Konsol, Anda dapat menggunakan fitur Alert Rules untuk membuat peringatan CloudMonitor untuk ReplicationLag dengan ambang batas 10 detik atau lebih. Untuk informasi lebih lanjut, lihat Atur aturan peringatan berbasis ambang batas.

Risiko

Bagian berikut menjelaskan dua alasan utama mengapa holes dapat muncul dalam cadangan log.

Versi MongoDB < 3.4

Operasi no-op periodik diperkenalkan pada versi mesin utama MongoDB 3.4 untuk mendukung parameter maxStalenessSeconds untuk readPreference. Untuk informasi lebih lanjut, lihat SERVER-23892. Tujuan utama no-op ini adalah memastikan oplog terus maju meskipun tidak ada operasi tulis dari bisnis. Hal ini membantu menentukan seberapa jauh node secondary tertinggal dalam sebuah replica set.

Jika versi mesin utama database lebih awal dari 3.4, oplog tidak maju jika tidak ada operasi tulis dari bisnis dalam waktu lama. Akibatnya, cadangan log instans tidak dapat mengambil data oplog baru, yang menyebabkan hole pada cadangan log. Hal ini pada gilirannya mencegah instans dipulihkan ke titik waktu tertentu.

Kecepatan tulis tinggi dengan oplog window pendek

Berdasarkan data historis cadangan log dari instans ApsaraDB for MongoDB, jika kecepatan pembuatan oplog instans mencapai sekitar 125 GB/jam hingga 165 GB/jam, sangat mungkin proses cadangan log tidak dapat mengimbangi, sehingga menghasilkan hole pada cadangan log.

Anda dapat memperkirakan kecepatan pembuatan oplog menggunakan ukuran oplog dan oplog window yang disebutkan sebelumnya. Misalnya, jika instans memiliki ukuran oplog 20 GB dan oplog window 0,06 jam, kecepatan pembuatan oplog-nya sekitar 333,3 GB/jam.

Workload semacam ini biasanya terjadi dalam skenario berikut:

Data sedang disinkronkan menggunakan DTS, mongoShake, atau tool sinkronisasi data lainnya.
Banyak operasi INSERT atau UPDATE batch dimuat dalam periode singkat.
Seeding data (mengimpor sejumlah besar data ke database dengan cepat).
Stress testing.

Untuk mencegah hole cadangan log akibat kecepatan tulis yang terlalu tinggi, Anda dapat mempertimbangkan langkah-langkah optimasi berikut:

Saat menggunakan tool sinkronisasi, terapkan pembatasan laju yang sesuai, seperti untuk konkurensi dan ukuran batch.
Gunakan write concern {w:"majority"} alih-alih {w:1}.

Jika workload Anda secara inheren memiliki kecepatan pembuatan oplog yang tinggi, Anda dapat mempertimbangkan pendekatan optimasi berikut sebagai gantinya:

Gunakan instans kluster sharded atau tambah jumlah shard untuk mengurangi kecepatan pembuatan oplog pada satu shard.
Tingkatkan ukuran oplog atau periode retensi minimum oplog sesuai kebutuhan skenario bisnis Anda. Hal ini memberikan waktu penyangga lebih lama bagi proses cadangan log. Dengan demikian, proses cadangan log dapat mengejar entri oplog yang sebelumnya tertinggal saat workload menurun.

ApsaraDB for MongoDB：Praktik terbaik dan risiko pengaturan oplog