Konfigurasikan parameter terkait oplog - ApsaraDB for MongoDB

Jika Anda mengonfigurasi parameter terkait oplog dengan tidak benar untuk sebuah instance ApsaraDB for MongoDB, sinkronisasi abnormal akan terjadi antara instance utama dan sekunder, serta data dalam instance set replika tidak dapat dipulihkan ke titik waktu sebelumnya. Topik ini menjelaskan cara mengonfigurasi parameter terkait oplog dan risiko dari pengaturan oplog yang tidak tepat.

Ikhtisar Oplog

Replikasi utama/sekunder dalam instance set replika ApsaraDB for MongoDB diimplementasikan oleh entri log operasi(oplog) di dalam instance. Oplog bernama local.oplog.rs di instance adalah koleksi berbatas khusus yang menyimpan operasi modifikasi yang dilakukan pada semua dokumen di database. Oplog menyediakan fitur dasar berikut:

Dalam instance set replika, operasi penulisan hanya diselesaikan pada node utama instance dan entri oplog yang sesuai dihasilkan pada node tersebut. Node sekunder lainnya dalam instance secara asinkron mereplikasi entri oplog dan memainkan ulang entri tersebut pada diri mereka sendiri untuk menjaga konsistensi replikasi utama/sekunder.
Jika suatu operasi tidak mengubah dokumen apa pun atau gagal, tidak ada entri oplog yang sesuai yang dihasilkan.
Sebuah entri oplog identik di semua node dalam instance set replika. Entri dalam oplog instance tetap tidak berubah sebelum dan sesudah pemutaran ulang.
Setiap operasi dalam oplog bersifat idempoten. Entri oplog tetap tidak berubah terlepas dari apakah entri tersebut dimainkan ulang sekali atau beberapa kali.
Entri oplog dikaitkan dengan periode waktu tertentu. Setiap operasi dalam oplog dalam instance set replika memiliki bidang timestamp unik (ts). Bidang ini terdiri dari timestamp UNIX dan penghitung. Dengan cara ini, Anda dapat menentukan urutan antara dua entri oplog.
Sebuah jendela oplog menunjukkan perbedaan waktu antara entri oplog paling lama dan entri oplog terbaru dalam oplog. Replikasi utama/sekunder bergantung pada jendela oplog. Node sekunder dapat mensinkronkan data sesuai harapan hanya ketika node mengidentifikasi entri oplog yang diinginkan dalam jendela oplog sumber sinkronisasi.
Setelah node sekunder dari instance set replika di-restart atau node ditambahkan ke instance, node juga bergantung pada entri oplog dalam oplog instance untuk memeriksa apakah node dapat menjadi anggota normal dari instance. Jika node tidak mengidentifikasi entri oplog yang diinginkan dalam jendela oplog sumber sinkronisasi, status node menjadi RECOVERING karena kesalahan terlalu usang untuk mengejar.

Ukuran Oplog

Ukuran default oplog dalam sebuah instance ApsaraDB for MongoDB set replika atau kluster sharded adalah 10% dari penyimpanan disk instance. Sebagai contoh, jika instance set replika atau kluster sharded Anda memiliki penyimpanan disk 500 GB, ukuran oplog instance adalah 50 GB. Ukuran oplog disesuaikan secara otomatis saat disk diperluas.

Untuk menyesuaikan ukuran oplog, Anda dapat memodifikasi nilai parameter replication.oplogSizeMB di konsol ApsaraDB for MongoDB. Modifikasi tersebut langsung berlaku tanpa perlu me-restart instance Anda. Untuk informasi lebih lanjut tentang cara memodifikasi parameter konfigurasi, lihat Konfigurasikan Parameter Database untuk Instance ApsaraDB for MongoDB.

Anda dapat menggunakan salah satu metode berikut untuk melihat ukuran oplog aktual:

Lihat nilai metrik Disk Usage pada halaman Data Pemantauan instance di konsol ApsaraDB for MongoDB. Untuk informasi lebih lanjut, lihat Pemantauan Dasar.

Gunakan mongo shell atau mongosh untuk terhubung ke instance dan kemudian jalankan perintah berikut:

rs.printReplicationInfo()

Hasil berikut dikembalikan:

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)

Hasil ini menunjukkan bahwa ukuran oplog adalah sekitar 192 MB dan jendela oplog adalah sekitar 18 jam.

Periode retensi minimum entri oplog

Pada MongoDB 4.4 dan versi lebih baru, opsi file konfigurasi storage.oplogMinRetentionHours didukung. Opsi ini digunakan untuk menentukan periode retensi minimum entri oplog, yang memastikan jendela oplog yang cukup.

Nilai default opsi ini adalah 0, yang menunjukkan bahwa periode retensi minimum entri oplog tidak ditentukan. Dalam kasus ini, entri oplog hanya dihapus setelah ukuran oplog yang ditentukan tercapai. Jika opsi ini dikonfigurasi, entri oplog hanya dihapus ketika persyaratan berikut terpenuhi:

Ukuran oplog melebihi nilai yang ditentukan oleh parameter replication.oplogSizeMB.
Timestamp oplog lebih awal dari periode retensi minimum entri oplog.

Ketika ukuran oplog tidak mencapai nilai yang ditentukan oleh parameter replication.oplogSizeMB, seperti ketika sejumlah besar data tidak ditulis ke instance yang diinisialisasi, jendela oplog aktual instance mungkin jauh lebih besar daripada periode retensi minimum entri oplog yang ditentukan. Dalam kasus ini, ukuran oplog hanya dibatasi oleh parameter replication.oplogSizeMB. Setelah ukuran oplog mencapai nilai yang ditentukan oleh parameter replication.oplogSizeMB, ukuran oplog dibatasi oleh periode retensi minimum entri oplog. Ketika sejumlah besar entri oplog dihasilkan dalam waktu singkat, total ukuran oplog mungkin jauh lebih besar daripada nilai yang ditentukan oleh parameter replication.oplogSizeMB.

Untuk menyesuaikan periode retensi minimum entri oplog, Anda dapat memodifikasi nilai parameter storage.oplogMinRetentionHours di konsol ApsaraDB for MongoDB. Modifikasi tersebut langsung berlaku tanpa perlu me-restart instance Anda. Untuk informasi lebih lanjut tentang cara memodifikasi parameter konfigurasi, lihat Konfigurasikan Parameter Database untuk Instance ApsaraDB for MongoDB.

Untuk melihat periode retensi entri oplog dalam instance, Anda dapat melihat nilai metrik Retention Period of Oplogs pada halaman Data Pemantauan instance di konsol ApsaraDB for MongoDB. Untuk informasi lebih lanjut, lihat Pemantauan Dasar.

Operasi pencadangan log untuk instance ApsaraDB for MongoDB

Operasi pencadangan log untuk semua instance ApsaraDB for MongoDB dilakukan berdasarkan entri oplog. Dalam pencadangan log instance, proses layanan kontrol yang relevan terus menarik entri oplog terbaru dari instance dan mengunggah entri tersebut ke Object Storage Service (OSS) dalam mode streaming untuk menghasilkan serangkaian file pencadangan log. Ketika data instance dipulihkan ke titik waktu sebelumnya, file pencadangan log digunakan untuk memainkan ulang entri oplog yang ditarik.

Dalam kasus khusus, catatan yang hilang mungkin dihasilkan dalam file pencadangan log, yang menyebabkan pemulihan titik waktu gagal. Untuk informasi lebih lanjut, lihat Deskripsi Risiko.

Catatan

Catatan yang hilang dalam file pencadangan log tidak memiliki definisi yang sama dengan oplog hole yang disebutkan dalam dokumentasi ApsaraDB for MongoDB.

Praktik Terbaik

Tentukan ukuran atau periode retensi oplog yang tepat

Dalam kebanyakan kasus, ukuran oplog adalah nilai default. Namun, kami menyarankan Anda untuk meningkatkan ukuran oplog dalam skenario berikut:

Pembaruan Batch ke Dokumen dengan Frekuensi Tinggi
Setiap operasi pembaruan batch menghasilkan beberapa operasi pembaruan untuk dokumen tunggal, yang menghasilkan sejumlah besar entri oplog.
Operasi Penyisipan dan Penghapusan Berulang
Jika dokumen yang disisipkan disimpan selama periode waktu tertentu dan kemudian dihapus, ruang disk database tempat dokumen tersebut termasuk tidak meningkat secara signifikan. Namun, sejumlah besar entri oplog yang relevan dihasilkan dalam database.
Sejumlah Besar Pembaruan In-place pada Dokumen
Jika sebagian besar operasi untuk dokumen dalam bisnis Anda adalah pembaruan yang tidak meningkatkan ukuran dokumen, pembaruan tersebut menghasilkan sejumlah besar entri oplog. Namun, volume data disk tidak berubah secara signifikan.

Dalam skenario berikut, Anda dapat mengurangi ukuran oplog untuk memanfaatkan ruang disk sepenuhnya:

Skenario di mana operasi baca dilakukan lebih sering daripada operasi tulis.
Skenario di mana data dingin disimpan.

Tidak peduli apakah Anda menentukan ukuran oplog atau periode retensi untuk instance ApsaraDB for MongoDB, kami menyarankan Anda untuk menetapkan jendela oplog instance lebih dari 24 jam. Dalam skenario yang memerlukan inisialisasi sinkronisasi tambahan (sinkronisasi awal), jendela oplog perlu mencakup waktu yang diperlukan untuk node menyelesaikan sinkronisasi data penuh. Dalam kebanyakan kasus, waktu ini terkait dengan faktor-faktor seperti volume data keseluruhan instance, jumlah total database dan koleksi, dan tipe instance. Jendela oplog mungkin mencakup periode waktu yang lebih lama.

Fokus pada latensi replikasi node sekunder dan konfigurasikan aturan peringatan untuk latensi tersebut

Jika latensi replikasi terjadi pada node sekunder dan terus meningkat hingga latensi melebihi jendela oplog yang ditentukan, node memasuki keadaan abnormal dan tidak dapat dipulihkan. Oleh karena itu, Anda harus fokus pada latensi replikasi node sekunder dalam instance ApsaraDB for MongoDB. Jika latensi replikasi terus meningkat, submit a ticket.

Alasan berikut menyebabkan latensi replikasi pada node sekunder:

Latensi jaringan, kehilangan paket, atau gangguan.
Throughput disk node sekunder yang mencapai bottleneck.
Write concern diatur ke {w:1} dan beban kerja tulis yang besar.
Replikasi utama/sekunder node sekunder diblokir karena cacat kernel tertentu.
Alasan lain yang tidak terdaftar.

Anda dapat menggunakan salah satu metode berikut untuk melihat latensi replikasi node sekunder:

Lihat nilai metrik Primary/Secondary Replication Latency pada halaman Data Pemantauan instance di konsol ApsaraDB for MongoDB. Untuk informasi lebih lanjut, lihat Pemantauan Dasar.

Gunakan mongo shell atau mongosh untuk terhubung ke instance dan kemudian jalankan perintah berikut:

rs.printSecondaryReplicationInfo()

Hasil berikut dikembalikan:

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

Hasil ini menunjukkan bahwa tidak ada latensi replikasi yang ada di dua node sekunder.

Anda dapat menggunakan modul Alert Rules di konsol ApsaraDB for MongoDB untuk membuat aturan peringatan terkait Replication Latency. Kami menyarankan Anda untuk menetapkan ambang batas peringatan lebih dari 10 detik. Untuk informasi lebih lanjut, lihat Konfigurasikan Aturan Peringatan Berbasis Ambang Batas untuk Instance ApsaraDB for MongoDB.

Risiko

Alasan berikut dapat menyebabkan catatan yang hilang dalam file pencadangan log:

Instance Anda menjalankan versi utama lebih awal dari MongoDB 3.4

Periodic noop diperkenalkan di MongoDB 3.4 untuk beradaptasi dengan parameter maxStalenessSeconds dari readPreference. Untuk informasi lebih lanjut, lihat SERVER-23892. Periodic noop dirancang untuk memastikan bahwa entri oplog terus diperbarui meskipun tidak ada data yang ditulis. Dengan cara ini, Anda dapat menentukan kemunduran node utama dan sekunder dalam instance set replika.

Jika instance Anda menjalankan versi utama lebih awal dari MongoDB 3.4 dan tidak ada data yang ditulis ke instance untuk waktu yang lama, entri oplog tidak lagi diperbarui. Oleh karena itu, file pencadangan log instance tidak dapat mengambil data oplog baru, yang menyebabkan catatan yang hilang dalam file tersebut. Dalam kasus ini, data instance tidak dapat dipulihkan ke titik waktu sebelumnya.

Sejumlah besar data ditulis ke instance Anda dalam waktu singkat dan jendela oplog instance memiliki durasi pendek

Data pencadangan log yang dihasilkan dalam ApsaraDB for MongoDB untuk periode waktu yang lama menunjukkan bahwa ketika kecepatan pembuatan oplog instance mencapai sekitar 125 GB/jam hingga 165 GB/jam, file pencadangan log mungkin gagal mengumpulkan entri oplog yang dihasilkan secara tepat waktu, yang menyebabkan catatan yang hilang dalam file tersebut.

Anda dapat memperkirakan kecepatan pembuatan oplog berdasarkan ukuran oplog dan jendela oplog. Sebagai contoh, jika ukuran oplog instance adalah 20 GB dan jendela oplog instance adalah 0,06 jam, kecepatan pembuatan oplog adalah sekitar 333,3 GB/jam.

Beban kerja tinggi dihasilkan dalam skenario berikut:

Data Transmission Service (DTS), mongoShake, atau alat sinkronisasi data lainnya sedang menyinkronkan data.
Sejumlah besar operasi INSERT atau UPDATE dilakukan secara batch dalam waktu singkat.
Sejumlah besar data ditulis ke database.
Uji stres dilakukan.

Untuk mencegah catatan yang hilang dalam file pencadangan log karena sejumlah besar data yang ditulis dalam waktu lama, kami menyarankan Anda menggunakan langkah-langkah optimasi berikut:

Ketika Anda menggunakan alat sinkronisasi, Anda harus membatasi kecepatan penulisan data. Sebagai contoh, Anda harus membatasi konkurensi dan ukuran batch.
Anda harus menetapkan write concern ke {w:"majority"} bukan {w:1}.

Jika kecepatan pembuatan oplog selalu tinggi dalam beban kerja Anda, kami menyarankan Anda menggunakan langkah-langkah optimasi berikut:

Gunakan instance kluster sharded atau tambahkan jumlah shard untuk mengurangi kecepatan pembuatan oplog pada shard tunggal.
Tingkatkan ukuran oplog atau periode retensi minimum entri oplog berdasarkan skenario bisnis Anda untuk menyediakan buffer periode yang lebih lama untuk file pencadangan log. Dengan cara ini, file pencadangan log dapat mengumpulkan entri oplog yang hilang secara tepat waktu.

ApsaraDB for MongoDB：Praktik terbaik dan risiko pengaturan oplog