Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Klaster dan Instans DB Amazon Neptune
Klaster DB Amazon Neptune mengelola akses ke data Anda melalui kueri. Sebuah klaster terdiri dari:
Satu Instans DB primer..
Hingga 15 instans DB replika baca..
Semua instans dalam sebuah klaster berbagi volume penyimpanan terkelola yang mendasari yang sama, yang didesain untuk keandalan dan ketersediaan yang tinggi.
Anda terhubung ke instans DB di klaster DB Anda melalui titik akhir Neptune.
Instans DB primer dalam klaster DB Neptune
Instans DB primer mengoordinasikan semua operasi tulis ke volume penyimpanan yang mendasari klaster DB. Ini juga mendukung operasi baca.
Hanya boleh ada satu instans DB primer dalam klaster DB Neptune. Jika instans primer menjadi tidak tersedia, Neptune secara otomatis melakukan failover ke salah satu instans replika baca dengan prioritas yang dapat Anda tentukan.
Instans DB replika baca dalam sebuah klaster DB Neptune
Setelah Anda membuat instans primer untuk klaster DB, Anda dapat membuat hingga 15 instans replika baca dalam klaster DB.
Instans DB replika baca Neptune berfungsi dengan baik untuk penyekalaan kapasitas baca karena didedikasikan sepenuhnya untuk operasi baca pada volume klaster Anda. Semua operasi tulis dikelola oleh instans primer. Setiap instans DB replika baca memiliki titik akhir sendiri.
Karena volume penyimpanan klaster dibagi di antara semua contoh dalam sebuah klaster, semua instans replika data mengembalikan data yang sama untuk hasil kueri dengan sangat sedikit keterlambatan replikasi. Keterlambatan ini biasanya kurang dari 100 milidetik setelah instans primer menulis pembaruan, meskipun dapat sedikit lebih lama ketika volume operasi tulis sangat besar.
Memiliki satu atau beberapa instans replika baca yang tersedia di Availability Zones yang berbeda dapat meningkatkan ketersediaan, karena replika baca berfungsi sebagai target failover untuk instans primer. Artinya, jika instans primer gagal, Neptune mempromosikan instans replika baca menjadi instans primer. Saat ini terjadi, terdapat gangguan singkat saat instans yang dipromosikan direboot, selama permintaan baca dan tulis dibuat ke instans primer gagal dengan pengecualian.
Sebaliknya, jika klaster DB Anda tidak menyertakan instans replika baca, klaster DB Anda tetap tidak tersedia ketika instans primer gagal sampai telah dibuat ulang. Membuat ulang instans primer membutuhkan waktu lebih lama daripada mempromosikan replika baca.
Untuk memastikan ketersediaan tinggi, kami sarankan Anda membuat satu atau beberapa instans replika baca yang memiliki kelas instans DB yang sama seperti instans primer dan terletak di Availability Zones yang berbeda daripada instans primer. Lihat Toleransi kesalahan untuk cluster DB Neptunus.
Dengan menggunakan konsol , Anda dapat membuat penerapan Multi-AZ cukup dengan menentukan Multi-AZ saat membuat klaster DB. Jika klaster DB berada di satu Availability Zone, Anda dapat menjadikannya klaster DB multi-AZ yang menambahkan replika Neptune di Availability Zone yang berbeda.
catatan
Anda tidak dapat membuat instans replika baca terenkripsi untuk klaster Neptune DB yang tidak terenkripsi, atau instans replika baca yang tidak dienkripsi untuk klaster Neptune DB terenkripsi.
Untuk detail tentang cara membuat instans DB replika baca Neptune, lihat Membuat instance pembaca Neptunus menggunakan konsol.
Mengukur instans DB dalam sebuah klaster Neptune DB
Ukur instance di cluster DB Neptunus Anda berdasarkan CPU kebutuhan Anda dan memori. Jumlah vCPUs pada instance menentukan jumlah thread query yang menangani query masuk. Jumlah memori pada instans menentukan ukuran cache buffer, digunakan untuk menyimpan salinan halaman data yang diambil dari volume penyimpanan yang mendasari.
Setiap instans DB Neptunus memiliki sejumlah thread kueri yang sama dengan 2 x vCPUs jumlah pada instance itu. Misalnyar5.4xlarge, dengan 16vCPUs, memiliki 32 utas kueri, dan karenanya dapat memproses 32 kueri secara bersamaan.
Kueri tambahan yang muncul saat semua utas kueri ditempati dimasukkan ke dalam antrean sisi server, dan diproses FIFO dengan cara saat utas kueri tersedia. Antrean sisi server ini dapat menyimpan sekitar 8000 permintaan tertunda. Setelah penuh, Neptune menanggapi permintaan tambahan dengan ThrottlingException. Anda dapat memantau jumlah permintaan yang tertunda dengan MainRequestQueuePendingRequests CloudWatch metrik, atau dengan menggunakan titik akhir status kueri Gremlin dengan parameter. includeWaiting
Waktu eksekusi kueri dari perspektif klien menyertakan setiap waktu yang dihabiskan dalam antrean, selain waktu yang dibutuhkan untuk benar-benar mengeksekusi kueri.
Beban tulis bersamaan berkelanjutan yang menggunakan semua utas kueri pada instance DB utama idealnya menunjukkan 90% atau lebih CPU pemanfaatan, yang menunjukkan bahwa semua utas kueri di server secara aktif terlibat dalam melakukan pekerjaan yang bermanfaat. Namun, CPU pemanfaatan aktual seringkali agak lebih rendah, bahkan di bawah beban tulis bersamaan yang berkelanjutan. Hal ini biasanya karena utas kueri menunggu operasi I/O ke volume penyimpanan yang mendasari diselesaikan. Neptune menggunakan penulisan kuorum yang membuat enam salinan data Anda di tiga Availability Zones, dan empat dari enam node penyimpanan harus mengakui penulisan untuknya agar dianggap tahan lama. Sementara utas kueri menunggu kuorum ini dari volume penyimpanan, itu macet, yang mengurangi pemanfaatan. CPU
Jika Anda memiliki beban penulisan serial di mana Anda melakukan penulisan satu demi satu dan menunggu yang pertama selesai sebelum memulai yang berikutnya, Anda dapat mengharapkan CPU pemanfaatannya menjadi lebih rendah. Jumlah yang tepat akan menjadi fungsi dari jumlah vCPUs dan kueri utas (semakin banyak utas kueri, semakin sedikit keseluruhan CPU per kueri), dengan beberapa pengurangan yang disebabkan oleh menunggu I/O.
Untuk informasi selengkapnya tentang cara terbaik untuk mengukur instans DB, lihatMemilih jenis instans untuk Amazon Neptunus. Untuk harga setiap jenis instans, silakan lihat halaman harga Neptunus.
Pemantauan performa instans DB di Neptune
Anda dapat menggunakan CloudWatch metrik di Neptunus untuk memantau kinerja instans DB Anda dan melacak latensi kueri seperti yang diamati oleh klien. Lihat Menggunakan CloudWatch untuk memantau kinerja instans DB di Neptunus.
