Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengelola Basis Data Amazon Neptune Anda
Bagian ini menunjukkan cara mengelola dan memelihara cluster DB Neptunus Anda menggunakan Konsol Manajemen AWS dan. AWS CLI
Neptune beroperasi di klaster server basis data yang terhubung dalam topologi replikasi. Dengan demikian, mengelola Neptunus sering melibatkan penerapan perubahan ke beberapa server dan memastikan bahwa semua replika Neptunus mengikuti server utama.
Karena Neptune secara transparan menskalakan penyimpanan yang mendasari saat data Anda tumbuh, pengelolaan Neptune memerlukan manajemen penyimpanan disk yang relatif kecil. Demikian pula, karena Neptune secara otomatis melakukan pencadangan berkelanjutan, klaster Neptune tidak memerlukan perencanaan atau waktu henti yang ekstensif untuk melakukan pencadangan.
**Topics**
+ [Menggunakan solusi Blue/Green Neptunus untuk melakukan pembaruan biru-hijau](neptune-BG-deployments.md)
+ [Membuat pengguna IAM dengan izin untuk Neptunus](manage-console-iam-user.md)
+ [Grup parameter Amazon Neptunus](parameter-groups.md)
+ [Parameter Amazon Neptunus](parameters.md)
+ [Meluncurkan cluster DB Neptunus menggunakan Konsol Manajemen AWS](manage-console-launch-console.md)
+ [Menghentikan dan memulai cluster DB Amazon Neptunus](manage-console-stop-start.md)
+ [Kosongkan klaster DB Amazon Neptune menggunakan API reset cepat](manage-console-fast-reset.md)
+ [Menambahkan instance pembaca Neptunus ke Cluster DB](manage-console-add-replicas.md)
+ [Membuat instance pembaca Neptunus menggunakan konsol](manage-console-create-replica.md)
+ [Memodifikasi Klaster DB Neptune Menggunakan Konsol](manage-console-modify.md)
+ [Performa dan Penskalaan di Amazon Neptune](manage-console-performance-scaling.md)
+ [Penskalaan otomatis jumlah replika di cluster DB Amazon Neptunus](manage-console-autoscaling.md)
+ [Mempertahankan Cluster DB Amazon Neptunus Anda](cluster-maintenance.md)
+ [Menggunakan CloudFormation template untuk memperbarui versi mesin Cluster DB Neptunus Anda](cfn-engine-update.md)
+ [Kloning Basis Data di Neptune](manage-console-cloning.md)
+ [Mengelola Instans Amazon Neptune](manage-console-instances.md)
# Menggunakan solusi Blue/Green Neptunus untuk melakukan pembaruan biru-hijau
Peningkatan mesin Amazon Neptunus dapat memerlukan waktu henti aplikasi karena database tidak tersedia saat pembaruan sedang diinstal dan diverifikasi. Ini benar apakah mereka dimulai secara manual atau otomatis.
Neptunus menyediakan solusi penerapan Blue/Green yang dapat Anda jalankan menggunakan tumpukan dan CloudFormation sangat mengurangi waktu henti tersebut. Ini menciptakan lingkungan pementasan hijau yang disinkronkan dengan lingkungan produksi biru Anda. Anda kemudian dapat memperbarui lingkungan pementasan tersebut untuk melakukan peningkatan versi mesin kecil atau utama, perubahan model data grafik, atau pembaruan sistem operasi, dan menguji hasilnya. Akhirnya, Anda dapat mengubahnya dengan cepat untuk menjadi lingkungan produksi Anda, dengan waktu henti yang sangat sedikit.
Solusi Blue/Green Neptunus melewati dua fase, seperti yang diilustrasikan dalam diagram ini:
![\[Diagram alir tingkat tinggi dari strategi penyebaran biru-hijau\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/BG-flow.png)
**Fase 1 membuat cluster DB Hijau yang identik dengan cluster produksi Anda**
Solusinya membuat cluster DB dengan pengenal blue/green penerapan unik dan dengan topologi cluster yang sama dengan cluster produksi Anda. Artinya, ia memiliki jumlah dan ukuran instans DB yang sama, grup parameter yang sama dan semua konfigurasi yang sama dengan cluster DB produksi (biru) kecuali bahwa itu telah ditingkatkan ke versi mesin target yang Anda tentukan, yang harus lebih tinggi dari versi mesin (biru) Anda saat ini. Anda dapat menentukan versi mesin minor dan utama untuk target. Jika perlu, solusi akan melakukan upgrade menengah yang diperlukan untuk mencapai versi mesin target yang ditentukan. Cluster baru ini menjadi lingkungan pementasan hijau.
**Tahap 2 mengatur sinkronisasi data berkelanjutan**
Setelah lingkungan hijau sepenuhnya disiapkan, solusinya mengatur replikasi berkelanjutan antara cluster sumber (biru) dan cluster target (hijau) menggunakan aliran Neptunus. Ketika perbedaan replikasi di antara mereka mencapai nol, lingkungan pementasan siap untuk pengujian. Pada saat itu Anda harus menjeda penulisan ke cluster biru untuk menghindari kelambatan replikasi lebih lanjut.
Versi mesin target Anda mungkin memiliki fitur atau dependensi baru yang memengaruhi aplikasi Anda. Periksa halaman rilis mesin target dan halaman rilis mesin intervensi di bawah [Rilis mesin](engine-releases.md) untuk melihat apa yang telah berubah sejak versi mesin Anda saat ini. Yang terbaik adalah menjalankan pengujian integrasi atau memverifikasi aplikasi Anda secara manual di klaster hijau sebelum mempromosikannya ke lingkungan produksi.
Setelah Anda menguji dan memenuhi syarat perubahan di cluster hijau, cukup alihkan titik akhir database dalam aplikasi Anda dari biru ke cluster hijau.
Setelah peralihan, Blue/Green solusi Neptunus tidak menghapus lingkungan produksi biru lama. Anda masih akan memiliki akses ke sana untuk validasi dan pengujian tambahan jika diperlukan. Biaya penagihan standar berlaku untuk instance-nya sampai Anda menghapusnya. Blue/Green Solusinya juga menggunakan AWS layanan lain, biaya yang ditagih dengan harga normal. Detail tentang menghapus solusi ketika Anda selesai dengan itu tercakup di [bagian pembersihan](neptune-BG-cleanup.md).
## Prasyarat untuk menjalankan tumpukan Neptunus Blue/Green
Sebelum meluncurkan tumpukan Blue/Green Neptunus:
+ Pastikan untuk [mengaktifkan aliran Neptunus](streams-using.md) di cluster produksi (biru) Anda.
+ Semua instance di cluster biru Anda harus dalam keadaan **tersedia**. Anda dapat memeriksa status instance di konsol [Neptunus](https://console.aws.amazon.com/neptune) atau dengan menggunakan API. [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-instances.html)
+ Semua instance juga harus sinkron dengan [grup parameter cluster DB](parameter-groups.md).
+ Solusi Blue/Green Neptunus memerlukan titik akhir DynamoDB VPC di VPC tempat cluster biru Anda berada. Lihat [Menggunakan titik akhir Amazon VPC untuk mengakses](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html#vpc-endpoints-dynamodb) DynamoDB.
+ Pilih pada waktunya untuk menjalankan solusi ketika beban kerja tulis pada cluster DB produksi biru Anda akan seringan mungkin. Hindari, misalnya, menjalankan solusi ketika beban massal akan terjadi, atau ketika kemungkinan ada sejumlah besar operasi tulis karena alasan lain.
# Menggunakan CloudFormation template untuk menjalankan solusi Neptunus Blue/Green
Anda dapat menggunakan AWS CloudFormation untuk menyebarkan solusi Neptunus Blue/Green . CloudFormationTemplate membuat instans Amazon EC2 di VPC yang sama dengan database Neptunus sumber biru Anda, menginstal solusi di sana, dan menjalankannya. Anda dapat memantau kemajuannya dalam CloudWatch log, seperti yang dijelaskan dalam [Memantau kemajuan](neptune-BG-monitoring.md).
Anda dapat menggunakan tautan ini untuk meninjau template solusi, atau pilih tombol **Launch Stack** untuk meluncurkannya di CloudFormation konsol:
| | | |
| --- |--- |--- |
| [Lihat](https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [Lihat di Desainer](https://console.aws.amazon.com/cloudformation/designer/home?templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) |
Di konsol, pilih AWS wilayah tempat Anda ingin menjalankan solusi dari dropdown di kanan atas jendela.
Atur parameter tumpukan sebagai berikut:
+ **`DeploymentID`**— Pengidentifikasi yang unik untuk setiap penyebaran Neptunus Blue/Green .
Ini digunakan sebagai pengidentifikasi cluster DB hijau, dan sebagai awalan untuk penamaan sumber daya baru yang dibuat selama penerapan.
+ **`NeptuneSourceClusterId`**— Pengidentifikasi cluster DB biru yang ingin Anda tingkatkan.
+ **`NeptuneTargetClusterVersion:`**— Versi [mesin Neptunus](engine-releases.md) yang ingin Anda tingkatkan ke cluster DB biru.
Ini harus lebih tinggi dari versi mesin cluster DB biru saat ini.
+ **`DeploymentMode`**— Menunjukkan apakah ini adalah penerapan baru atau upaya untuk melanjutkan penerapan sebelumnya. Saat Anda menggunakan `DeploymentID` sama dengan penerapan sebelumnya, setel `DeploymentMode` ke`resume`.
Nilai yang valid adalah: `new` (default), dan`resume`.
+ **`GraphQueryType`**— Jenis data grafik untuk database Anda.
Nilai yang valid adalah: `propertygraph` (default), dan`rdf`.
+ **`SubnetId`**— ID subnet dari VPC yang sama tempat cluster DB biru Anda berada. (lihat [Menghubungkan ke Cluster DB Neptunus dari instans Amazon EC2 di VPC](get-started-connect-ec2-same-vpc.md) yang sama).
Berikan ID subnet publik jika Anda ingin SSH ke instans melalui [EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) Connect.
+ **`InstanceSecurityGroup`**— Grup keamanan untuk instans Amazon EC2 Anda.
Grup keamanan harus memiliki akses ke cluster DB biru Anda, dan Anda harus dapat SSH ke instance. Lihat [Buat grup keamanan menggunakan konsol VPC](get-started-vpc.md#security-vpc-security-group).
Tunggu sampai tumpukan selesai. Segera setelah selesai, solusinya dimulai. Anda kemudian dapat memantau proses penyebaran menggunakan CloudWatch log seperti yang dijelaskan di bagian berikutnya.
# Memantau kemajuan penyebaran Neptunus Blue/Green
[Anda dapat memantau kemajuan solusi Blue/Green Neptunus dengan pergi ke CloudWatch konsol dan melihat log di `/aws/neptune/(Neptune Blue/Green deployment ID)` CloudWatch grup log.](https://console.aws.amazon.com/cloudwatch/) Anda dapat menemukan tautan ke CloudWatch log di output CloudFormation tumpukan solusi:
![\[Tangkapan layar dari output tumpukan Biru/Hijau CloudFormation\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/BG-stack-output.png)
Jika Anda menyediakan subnet publik sebagai parameter tumpukan, Anda juga dapat SSH ke instans Amazon EC2 yang dibuat sebagai bagian dari tumpukan dan merujuk ke log in. `/var/log/cloud-init-output.log`
Log menunjukkan tindakan yang diambil oleh solusi Blue/Green Neptunus, seperti yang ditunjukkan pada tangkapan layar ini:
![\[Tangkapan layar dari layar log Blue/Green Neptunus\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/BG-log-screenshot.png)
Pesan log menunjukkan status sinkronisasi antara cluster biru dan hijau:
![\[Tangkapan layar pesan log solusi Blue/Green Neptunus\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/BG-log-messages.png)
Proses sinkronisasi memeriksa lag replikasi dengan menghitung perbedaan antara aliran terbaru `eventID` pada cluster biru dan pos pemeriksaan replikasi yang ada di tabel pos pemeriksaan DynamoDB yang dibuat oleh tumpukan replikasi. Neptune-to-Neptune Dengan menggunakan pesan-pesan ini, Anda dapat memantau perbedaan replikasi saat ini.
# Memotong dari cluster biru produksi ke cluster hijau yang diperbarui
Sebelum mempromosikan cluster hijau ke produksi, pastikan bahwa perbedaan komit antara cluster biru dan hijau adalah nol dan kemudian nonaktifkan semua lalu lintas tulis ke cluster biru. Melanjutkan menulis ke cluster biru sambil mengalihkan titik akhir basis data ke cluster hijau dapat mengakibatkan kerusakan data yang disebabkan oleh penulisan data sebagian ke kedua cluster. Anda mungkin belum perlu menonaktifkan lalu lintas baca.
Jika Anda telah mengaktifkan autentikasi IAM pada klaster sumber (biru), pastikan untuk memperbarui kebijakan IAM yang digunakan dalam aplikasi Anda untuk menunjuk ke klaster hijau (untuk contoh kebijakan semacam itu, lihat kebijakan [akses tidak terbatas](iam-data-access-examples.md#iam-auth-data-policy-example-general) ini).
Setelah menonaktifkan lalu lintas tulis, tunggu replikasi selesai dan kemudian aktifkan lalu lintas tulis di cluster hijau (tetapi tidak pada cluster biru). Beralih lalu lintas baca dari biru ke cluster hijau juga.
# Pembersihan setelah solusi Blue/Green Neptunus selesai
Setelah Anda mempromosikan klaster pementasan (hijau) ke produksi, bersihkan sumber daya yang dibuat oleh solusi Neptunus Blue/Green :
+ Hapus instans Amazon EC2 yang dibuat untuk menjalankan solusi.
+ Hapus CloudFormation template untuk replikasi [berbasis aliran Neptunus](streams-consumer-setup.md) yang membuat cluster hijau tetap sinkron dengan cluster biru. Yang utama memiliki nama tumpukan yang Anda berikan sebelumnya, dan satu terdiri dari ID penerapan diikuti oleh “-replikasi”: yaitu,. `(DeploymentID)-replication`
Menghapus CloudFormation template tidak menghapus cluster itu sendiri. Setelah Anda memverifikasi bahwa cluster hijau berfungsi seperti yang diharapkan, Anda dapat mengambil snapshot secara opsional sebelum menghapus cluster biru secara manual.
# Praktik terbaik solusi Blue/Green Neptunus
+ Sebelum mengalihkan cluster hijau Anda ke produksi, ada baiknya memverifikasi secara menyeluruh bahwa itu berfungsi dengan baik. Periksa konsistensi data dan konfigurasi database. Ada kemungkinan bahwa beberapa versi mesin baru memerlukan peningkatan klien juga. Periksa catatan rilis mesin sebelum Anda meningkatkan. Perlu menguji semua ini dalam pengembangan, pengujian, dan lingkungan pra-produksi sebelum memulai blue/green peningkatan produksi.
+ Yang terbaik adalah melakukan peralihan dari server biru ke hijau selama jendela pemeliharaan Anda.
+ Untuk memastikan bahwa semuanya berfungsi dengan baik setelah memutakhirkan dan menyinkronkan, ada baiknya menyimpan cluster asli Anda selama beberapa periode waktu sebelum menghapusnya. Itu bisa terbukti berguna jika masalah yang tidak terduga muncul.
+ Hindari operasi penulisan berat seperti beban massal saat menjalankan solusi Blue/Green Neptunus, karena dapat menyebabkan kelambatan replikasi yang menyebabkan waktu henti yang signifikan. Idealnya, waktu antara mematikan penulisan ke cluster biru Anda dan menyalakannya untuk cluster hijau Anda hanya beberapa saat.
# Memecahkan masalah solusi Neptunus Blue/Green
Informasi berikut menyoroti masalah yang dapat muncul selama proses penerapan Blue/Green solusi, seperti konflik dengan cluster yang ada, kebutuhan untuk mengaktifkan aliran Neptunus, operasi pemuatan massal yang sedang berlangsung, dan persyaratan kompatibilitas versi. Dengan mengatasi masalah potensial ini, Anda dapat memastikan penerapan solusi Neptunus yang lancar dan sukses. Blue/Green
**Kesalahan yang ditimbulkan oleh solusi Neptunus Blue/Green**
+ **`Cluster with id = (blue_green_deployment_id) already exists`**— Ada cluster yang ada dengan pengenal*(blue\$1green\$1deployment\$1id)*.
Berikan ID penerapan baru atau atur mode penerapan ke `resume` jika cluster dibuat dalam proses Neptunus sebelumnya. Blue/Green
+ **`Streams should be enabled on the source Cluster for Blue Green Deployment`**— Aktifkan aliran [Neptunus](streams-using-enabling.md) pada cluster biru (sumber).
+ **`No Bulkload should be in progress on source cluster: (cluster_id)`**— Solusi Blue/Green Neptunus berakhir jika mengidentifikasi beban curah yang sedang berlangsung.
Ini untuk memastikan bahwa proses sinkronisasi dapat menangkap penulisan yang sedang dibuat. Hindari atau batalkan pekerjaan pemuatan massal yang sedang berlangsung sebelum memulai solusi Blue/Green Neptunus.
+ **`Blue Green deployment requires instances to be in sync with db cluster parameter group`**— Setiap perubahan pada grup parameter cluster harus disinkronkan di seluruh cluster DB. Lihat [Grup parameter Amazon Neptunus](parameter-groups.md).
+ **`Invalid target engine version for Blue Green Deployment`**— Versi mesin target harus terdaftar sebagai aktif[Rilis mesin untuk Amazon Neptunus](engine-releases.md), dan harus lebih tinggi dari pelepasan mesin saat ini dari cluster sumber (biru).
# Membuat pengguna IAM dengan izin untuk Neptunus
Untuk mengakses konsol Neptunus untuk membuat dan mengelola cluster DB Neptunus, Anda perlu membuat pengguna IAM dengan semua izin yang diperlukan.
Langkah pertama adalah membuat kebijakan peran terkait layanan untuk Neptunus:
## Membuat kebijakan peran terkait layanan untuk Amazon Neptunus
1. Masuk ke Konsol Manajemen AWS dan buka konsol IAM di [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Pada panel navigasi di sebelah kiri, pilih **Kebijakan**.
1. Pada halaman **Kebijakan**, pilih **Buat Kebijakan**.
1. Pada halaman **Buat kebijakan**, pilih tab **JSON** dan salin dalam kebijakan peran terkait layanan berikut:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"rds.amazonaws.com"
}
}
}
]
}
```
------
1. Pilih **Berikutnya: Tag**, dan pada halaman **Tambahkan tag** pilih **Berikutnya: Tinjau**.
1. Pada halaman **Kebijakan ulasan**, beri nama kebijakan baru "NeptuneServiceLinked”.
Untuk mengetahui informasi selengkapnya tentang peran terkait layanan, lihat [Menggunakan peran terkait layanan untuk Amazon Neptunus](security-iam-service-linked-roles.md).
## Buat pengguna IAM baru dengan semua izin yang diperlukan
Selanjutnya, buat pengguna IAM baru dengan kebijakan terkelola yang sesuai yang dilampirkan yang akan memberikan izin yang Anda perlukan, bersama dengan kebijakan peran terkait layanan yang telah Anda buat (di sini bernama): `NeptuneServiceLinked`
1. Masuk ke Konsol Manajemen AWS dan buka konsol IAM di [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Di panel navigasi di sebelah kiri, pilih **Pengguna**, dan di halaman **Pengguna**, pilih **Tambahkan pengguna**.
1. Pada halaman **Tambah pengguna**, masukkan nama untuk pengguna IAM baru, pilih **Kunci akses - Akses program** untuk jenis AWS kredensi, dan pilih **Berikutnya**: Izin.
1. Pada halaman **Setel izin**, di kotak **Kebijakan filter**, ketik “Neptunus”. Sekarang pilih yang berikut ini dari kebijakan yang tercantum:
+ **NeptuneFullAccess**
+ **NeptuneConsoleFullAccess**
+ **NeptuneServiceLinked**(dengan asumsi itulah yang Anda beri nama kebijakan peran terkait layanan yang Anda buat sebelumnya).
1. Ketik berikutnya “VPC” di kotak **Kebijakan filter** sebagai pengganti “Neptunus”. Pilih **Amazon VPCFull Access** dari kebijakan yang tercantum.
1. Pilih **Berikutnya: Tag**, dan di halaman **Tambahkan tag**, pilih **Berikutnya: Tinjau**.
1. Di halaman **Tinjauan**, periksa apakah semua kebijakan berikut sekarang dilampirkan ke pengguna baru Anda:
+ **NeptuneFullAccess**
+ **NeptuneConsoleFullAccess**
+ **NeptuneServiceLinked**
+ **VPCFullAkses Amazon**
Kemudian, pilih **Buat Pengguna**.
1. Terakhir, unduh dan simpan ID kunci akses pengguna baru dan kunci akses rahasia.
Untuk beroperasi di layanan lain seperti Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3), Anda perlu menambahkan lebih banyak izin dan hubungan kepercayaan.
# Grup parameter Amazon Neptunus
Anda mengelola konfigurasi database Anda di Amazon Neptunus dengan [menggunakan parameter dalam grup](parameters.md) parameter. Grup parameter bertindak sebagai *wadah* untuk nilai konfigurasi mesin yang diterapkan ke satu atau lebih instance DB.
Ada dua jenis kelompok parameter, yaitu kelompok parameter cluster DB dan kelompok parameter DB:
+ *Grup parameter DB* berlaku di tingkat instance dan umumnya dikaitkan dengan pengaturan untuk mesin grafik Neptune, seperti parameter `neptune_query_timeout`.
+ *Grup parameter klaster DB* berlaku untuk setiap instans dalam klaster dan umumnya memiliki pengaturan yang lebih luas. Setiap klaster Neptune dikaitkan dengan grup parameter klaster DB. Setiap instans DB dalam cluster itu mewarisi nilai konfigurasi engine yang terdapat dalam grup parameter cluster DB.
Setiap nilai konfigurasi apa pun yang Anda ubah di grup parameter klaster DB akan menimpa nilai default di grup parameter DB. Jika Anda mengedit nilai yang sesuai dalam grup parameter DB, nilai-nilai tersebut mengesampingkan pengaturan di grup parameter cluster DB.
Grup parameter DB default digunakan jika Anda membuat instans DB tanpa menentukan grup parameter DB kustom. Anda tidak dapat mengubah pengaturan parameter grup parameter DB default. Sebagai gantinya, untuk mengubah pengaturan parameter default Anda harus membuat grup parameter DB baru. Tidak semua parameter mesin DB dapat diubah dalam grup parameter DB yang Anda buat.
Grup parameter dibuat dalam keluarga yang kompatibel dengan versi mesin Neptunus tertentu. Saat Anda meningkatkan ke versi mesin mayor atau minor baru, Anda mungkin perlu membuat ulang grup parameter kustom Anda menggunakan keluarga grup parameter yang sesuai untuk versi tersebut.
Penamaan keluarga grup parameter mengikuti pola`neptuneX.Y`, di mana `X.Y` cocok dengan versi mesin. Contoh:
+ `neptune1`— untuk versi mesin sebelum 1.2.0.0
+ `neptune1.2`- untuk versi mesin 1.2.x
+ `neptune1.3`- untuk versi mesin 1.3.x
+ `neptune1.4`- untuk versi mesin 1.4.x
Saat memutakhirkan cluster Neptunus Anda, periksa catatan [rilis](engine-releases.md) untuk versi mesin target Anda untuk menentukan apakah keluarga grup parameter baru diperlukan. Jika demikian, Anda harus membuat ulang semua grup parameter kustom dalam keluarga baru sebelum memutakhirkan.
Beberapa parameter Neptunus bersifat statis, dan yang lainnya dinamis. Perbedaannya adalah sebagai berikut:
**Parameter statis**
+ Parameter statis adalah parameter yang berlaku hanya setelah instance DB di-boot ulang. Dengan kata lain, ketika Anda mengubah parameter statis dan menyimpan grup parameter DB instance, Anda harus secara manual me-reboot instance DB agar perubahan parameter diterapkan. Saat ini, semua parameter tingkat instans Neptunus (dalam grup parameter DB daripada grup parameter cluster DB) bersifat statis.
+ Saat Anda mengubah parameter statis tingkat cluster dan menyimpan grup parameter cluster DB, perubahan parameter akan berlaku setelah Anda me-reboot setiap instans DB di cluster secara manual.
**Parameter dinamis**
+ Parameter dinamis adalah parameter yang berlaku segera setelah parameter diperbarui dalam grup parameternya. Dengan kata lain, tidak perlu me-reboot instance DB setelah memperbarui parameter dinamis agar perubahan parameter diterapkan.
+ Harapkan beberapa penundaan kecil untuk perubahan parameter cluster dinamis diterapkan di semua instance DB.
+ Nilai parameter dinamis yang diperbarui tidak diterapkan pada permintaan yang sedang berjalan, tetapi hanya untuk permintaan yang dikirimkan setelah perubahan terjadi.
+ Saat Anda mengubah parameter tingkat cluster dinamis, secara default perubahan parameter diterapkan ke cluster DB Anda segera, tanpa memerlukan reboot apa pun. Untuk menunda perubahan parameter sampai setelah instance DB di cluster di-boot ulang, Anda dapat menggunakan AWS CLI untuk mengatur to untuk perubahan parameter. `ApplyMethod` `pending-reboot`
Saat ini semua parameter statis kecuali untuk parameter cluster baru berikut:
+ `neptune_enable_slow_query_log`(tingkat cluster)
+ `neptune_slow_query_log_threshold`(tingkat cluster)
Berikut ini beberapa poin penting yang harus Anda ketahui tentang bekerja dengan parameter dalam grup parameter DB:
+ Pengaturan parameter yang tidak tepat dalam grup parameter DB dapat memiliki efek merugikan yang tidak diinginkan, termasuk penurunan kinerja dan ketidakstabilan sistem. Selalu berhati-hati saat memodifikasi parameter basis data dan membuat cadangan data sebelum memodifikasi grup parameter DB. Coba perubahan pengaturan grup parameter pada instans DB uji sebelum menerapkan perubahan tersebut ke instans DB produksi.
+ Saat Anda mengubah grup parameter DB yang terkait dengan instans DB, Anda harus me-reboot instance secara manual sebelum grup parameter DB baru digunakan oleh instans DB.
**catatan**
Sebelumnya[Rilis: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md), semua instance baca-replika dalam cluster DB secara otomatis di-boot ulang setiap kali instance primer (penulis) dimulai ulang.
Dari [Rilis: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md) maju, memulai ulang instance utama tidak menyebabkan instance replika apa pun dimulai ulang. Ini berarti bahwa jika Anda mengubah parameter tingkat cluster, Anda harus memulai ulang setiap instance secara terpisah untuk mengambil perubahan parameter.
## Mengedit Grup Parameter Klaster DB atau Group Parameter DB
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Pilih **Grup parameter** di panel navigasi.
1. Pilih link **Nama** untuk grup parameter DB yang ingin Anda edit.
(Opsional) Pilih **Buat grup parameter** untuk membuat grup parameter klaster baru dan membuat grup baru. Lalu pilih **Nama** grup parameter baru.
**penting**
Langkah ini adalah *wajib* Jika Anda hanya memiliki grup parameter klaster DB default karena grup parameter klaster DB tidak dapat diubah.
1. Cari parameter dan klik pada bidang **Nilai** di sebelah kolom **Nama**.
1. Masukkan nilai yang diizinkan dan pilih centang di samping bidang nilai.
1. Pilih **Simpan perubahan**.
1. Reboot setiap instans DB di cluster Neptunus jika Anda mengubah parameter cluster DB, atau satu atau lebih instance spesifik jika Anda mengubah parameter instans DB.
## Membuat grup parameter DB atau grup parameter cluster DB
Anda dapat dengan mudah menggunakan konsol Neptunus untuk membuat grup parameter baru:
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Pilih **Grup Parameter** Di panel navigasi kiri.
1. Pilih **Buat grup parameter DB**.
Halaman **Buat grup parameter DB** akan muncul.
1. ****Dalam daftar **keluarga grup Parameter, pilih keluarga** yang cocok dengan versi mesin Neptunus target Anda (misalnya, neptune1.2, neptune1.3**,** atau neptune1.4).****
1. Di daftar **Jenis**, pilih **Grup parameter DB** atau **Grup Parameter Klaster DB**.
1. Di kotak **Nama grup**, masukkan nama grup parameter DB baru.
1. Di kotak **Deskripsi**, masukkan deskripsi untuk grup parameter DB baru.
1. Pilih **Buat**.
Anda juga dapat membuat grup parameter baru menggunakan AWS CLI:
```
aws neptune create-db-parameter-group \
--db-parameter-group-name (a name for the new DB parameter group) \
--db-parameter-group-family (the family matching your engine version, such as neptune1.2, neptune1.3, or neptune1.4) \
--description (a description for the new DB parameter group)
```
# Parameter Amazon Neptunus
[Anda mengelola konfigurasi database Anda di Amazon Neptunus dengan menggunakan parameter dalam grup parameter.](parameter-groups.md) Parameter berikut tersedia untuk mengonfigurasi database Neptunus Anda:
**Parameter tingkat klaster**
+ [neptune\$1enable\$1audit\$1log](#parameters-db-cluster-parameters-neptune_enable_audit_log)
+ [neptune\$1enable\$1slow\$1query\$1log](#parameters-db-cluster-parameters-neptune_enable_slow_query_log)
+ [neptune\$1slow\$1query\$1log\$1threshold](#parameters-db-cluster-parameters-neptune_slow_query_log_threshold)
+ [neptune\$1lab\$1mode](#parameters-db-cluster-parameters-neptune_lab_mode)
+ [neptune\$1query\$1timeout](#parameters-db-cluster-parameters-neptune_query_timeout)
+ [neptune\$1stream](#parameters-db-cluster-parameters-neptune_streams)
+ [neptune\$1streams\$1expiry\$1days](#parameters-db-cluster-parameters-neptune_streams_expiry_days)
+ [neptune\$1lookup\$1cache](#parameters-db-cluster-parameters-neptune_lookup_cache)
+ [neptune\$1autoscaling\$1config](#parameters-db-cluster-parameters-neptune_autoscaling_config)
+ [neptune\$1ml\$1iam\$1role](#parameters-db-cluster-parameters-neptune_ml_iam_role)
+ [neptune\$1ml\$1titik akhir](#parameters-db-cluster-parameters-neptune_ml_endpoint)
+ [neptune\$1enable\$1inline\$1server\$1generated\$1edge\$1id](#parameters-db-cluster-parameters-neptune_inline_edge_id)
**Parameter tingkat instans**
+ [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine)
+ [neptune\$1query\$1timeout](#parameters-instance-parameters-neptune_query_timeout)
+ [neptune\$1result\$1cache](#parameters-db-instance-parameters-neptune_result_cache)
+ [UndoLogPurgeConfig](#parameters-db-instance-parameters-undo_log_purge_config)
**Parameter usang**
+ [neptune\$1enforce\$1ssl](#parameters-db-cluster-parameters-neptune_enforce_ssl)
## `neptune_enable_audit_log`(parameter tingkat cluster)
Parameter ini mengaktifkan pencatatan audit untuk Neptunus.
Nilai yang diizinkan adalah `0` (dinonaktifkan) dan `1` (diaktifkan). Nilai default-nya adalah `0`.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Anda dapat mempublikasikan log audit ke Amazon CloudWatch, seperti yang dijelaskan dalam[Menggunakan CLI untuk menerbitkan log audit Neptunus ke Log CloudWatch](cloudwatch-logs.md#cloudwatch-logs-cli).
## `neptune_enable_slow_query_log`(parameter tingkat cluster)
Gunakan parameter ini untuk mengaktifkan atau menonaktifkan fitur logging kueri [lambat](slow-query-logs.md) Neptunus.
Ini adalah parameter dinamis, yang berarti bahwa mengubah nilainya tidak memerlukan atau menyebabkan restart cluster DB Anda.
Nilai yang diizinkan adalah:
+ **`info`**— Mengaktifkan pencatatan kueri lambat dan mencatat atribut yang dipilih yang mungkin berkontribusi pada kinerja yang lambat.
+ **`debug`**— Mengaktifkan pencatatan kueri lambat dan mencatat semua atribut yang tersedia dari kueri yang dijalankan.
+ **`disabled`**— Menonaktifkan pencatatan kueri lambat.
Nilai default-nya adalah `disabled`.
Anda dapat mempublikasikan log kueri lambat ke Amazon CloudWatch, seperti yang dijelaskan dalam. [Menggunakan CLI untuk menerbitkan log kueri lambat Neptunus ke Log CloudWatch](cloudwatch-logs.md#cloudwatch-slow-query-logs-cli)
## `neptune_slow_query_log_threshold`(parameter tingkat cluster)
Parameter ini menentukan ambang waktu eksekusi, dalam milidetik, setelah itu kueri dianggap sebagai kueri lambat. Jika [pencatatan kueri lambat](slow-query-logs.md) diaktifkan, kueri yang berjalan lebih lama dari ambang batas ini akan dicatat bersama dengan beberapa atributnya.
Nilai default adalah 5000 milidetik (5 detik).
Ini adalah parameter dinamis, yang berarti bahwa mengubah nilainya tidak memerlukan atau menyebabkan restart cluster DB Anda.
## `neptune_lab_mode`(parameter tingkat cluster)
Saat diatur, parameter ini memungkinkan fitur eksperimental spesifik Neptunus. Lihat [Mode Lab Neptune](features-lab-mode.md) untuk fitur eksperimental yang tersedia saat ini.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Untuk mengaktifkan atau menonaktifkan fitur eksperimental, sertakan *(feature name)* `=enabled` atau *(feature name)* `=disabled` dalam parameter ini. Anda dapat mengaktifkan atau menonaktifkan beberapa fitur dengan memisahkannya dengan koma, seperti ini:
*(feature \$11 name)*`=enabled,` *(feature \$12 name)*`=enabled`
Fitur mode lab biasanya dinonaktifkan secara default. Pengecualian adalah `DFEQueryEngine` fitur, yang diaktifkan secara default untuk digunakan dengan petunjuk kueri (`DFEQueryEngine=viaQueryHint`) dimulai pada rilis mesin [Neptunus 1.0.5.0](engine-releases-1.0.5.0.md). Dimulai dengan [rilis mesin Neptunus](engine-releases-1.1.1.0.md) 1.1.1.0, mesin DFE tidak lagi dalam mode lab, dan sekarang dikontrol menggunakan [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) parameter instance dalam grup parameter DB instans.
## `neptune_query_timeout`(parameter tingkat cluster)
Menentukan durasi batas waktu tertentu untuk kueri grafik, dalam milidetik.
Nilai yang diizinkan berkisar dari `10` ke `2,147,483,647` (231 - 1). Nilai defaultnya adalah `120,000` (2 menit).
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Ketika beberapa pengaturan batas waktu dikonfigurasi (tingkat klaster, tingkat instance, dan per-kueri), tabel berikut menunjukkan nilai batas waktu mana yang diutamakan:
| Kluster PG | Contoh PG | Petunjuk Kueri | Hasil |
| --- | --- | --- | --- |
| Default | Default | none | Kluster |
| Khusus | Default | none | Kluster |
| Khusus | Khusus | none | Instans |
| Default | Khusus | none | Instans |
| Setiap | Setiap | terendah | Kueri |
| Default | Khusus | tidak terendah | Instans |
| Khusus | Default | tidak terendah | Kluster |
| Khusus | Khusus | tidak terendah | Instans |
**catatan**
Dimungkinkan untuk mengeluarkan biaya tak terduga jika Anda menetapkan nilai batas waktu kueri terlalu tinggi, terutama pada instance tanpa server. Tanpa pengaturan batas waktu yang wajar, Anda mungkin secara tidak sengaja mengeluarkan kueri yang terus berjalan lebih lama dari yang Anda harapkan, menimbulkan biaya yang tidak pernah Anda antisipasi. Hal ini terutama berlaku pada instance tanpa server yang dapat meningkatkan skala hingga jenis instance yang besar dan mahal saat menjalankan kueri.
Anda dapat menghindari pengeluaran tak terduga semacam ini dengan menggunakan nilai batas waktu kueri yang mengakomodasi sebagian besar kueri Anda dan hanya menyebabkan yang berjalan lama secara tak terduga habis.
## `neptune_streams`(parameter tingkat cluster)
Mengaktifkan atau menonaktifkan[Aliran Neptunus](streams.md).
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Nilai yang diizinkan adalah `0` (dinonaktifkan, yang merupakan default), dan`1` (diaktifkan).
## `neptune_streams_expiry_days`(parameter tingkat cluster)
Menentukan berapa hari berlalu sebelum server menghapus catatan aliran.
Nilai yang diizinkan adalah dari `1` ke`90`, inklusif. Nilai default-nya `7`.
Parameter ini diperkenalkan di [versi mesin 1.2.0.0](engine-releases-1.2.0.0.md).
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
## `neptune_lookup_cache`(parameter tingkat cluster)
[Menonaktifkan atau mengaktifkan kembali cache pencarian Neptunus.](feature-overview-lookup-cache.md) pada `R5d` contoh.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Nilai yang diizinkan adalah `1` (diaktifkan) dan `0` (dinonaktifkan). Nilai defaultnya adalah`0`, tetapi setiap kali sebuah `R5d` instance dibuat di cluster DB, `neptune_lookup_cache` parameter secara otomatis diatur ke `1` dan cache pencarian dibuat pada instance itu.
## `neptune_autoscaling_config`(parameter tingkat cluster)
Menetapkan parameter konfigurasi untuk instance read-replica yang dibuat dan dikelola oleh [Neptune](manage-console-autoscaling.md) auto-scaling.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Menggunakan string JSON yang Anda tetapkan sebagai nilai `neptune_autoscaling_config` parameter, Anda dapat menentukan:
+ Jenis instans yang digunakan auto-scaling Neptunus untuk semua instance read-replica baru yang dibuatnya.
+ Jendela pemeliharaan ditetapkan untuk replika baca tersebut.
+ Tag yang akan dikaitkan dengan semua replika baca baru.
String JSON memiliki struktur seperti ini:
```
"{
\"tags\": [
{ \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" },
{ \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" },
],
\"maintenanceWindow\" : \"wed:12:03-wed:12:33\",
\"dbInstanceClass\" : \"db.r5.xlarge\"
}"
```
Perhatikan bahwa tanda kutip dalam string semua harus lolos dengan karakter garis miring terbalik (). `\`
Salah satu dari tiga pengaturan konfigurasi yang tidak ditentukan dalam `neptune_autoscaling_config` parameter disalin dari konfigurasi instance penulis utama cluster DB.
## `neptune_ml_iam_role`(parameter tingkat cluster)
Menentukan peran IAM ARN yang digunakan dalam Neptunus ML. Nilai dapat berupa ARN peran IAM yang valid.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Anda dapat menentukan ARN peran IAM default untuk pembelajaran mesin pada grafik.
## `neptune_ml_endpoint`(parameter tingkat cluster)
Menentukan endpoint yang digunakan untuk Neptunus ML. Nilainya bisa berupa [nama titik akhir SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateEndpoint.html#sagemaker-CreateEndpoint-request-EndpointName) yang valid.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Anda dapat menentukan titik akhir SageMaker AI default untuk pembelajaran mesin pada grafik.
## `neptune_enable_inline_server_generated_edge_id`(parameter tingkat cluster)
Aktifkan atau nonaktifkan fitur ID Edge yang dihasilkan server sebaris Neptunus.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Nilai yang diizinkan adalah `1` (diaktifkan), dan `0` (dinonaktifkan). Nilai default-nya adalah `0`.
## `neptune_dfe_query_engine`(parameter tingkat contoh)
[Dimulai dengan [rilis mesin Neptunus](engine-releases-1.1.1.0.md) 1.1.1.0, parameter instans DB ini digunakan untuk mengontrol bagaimana mesin kueri DFE digunakan.](neptune-dfe-engine.md) Nilai yang diizinkan adalah sebagai berikut:
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
+ **`enabled`**— Menyebabkan mesin DFE digunakan sedapat mungkin, kecuali di mana petunjuk `useDFE` kueri ada dan disetel ke. `false`
+ **`viaQueryHint`**(default) - Menyebabkan mesin DFE hanya digunakan untuk kueri yang secara eksplisit menyertakan petunjuk kueri yang disetel ke`useDFE`. `true`
Jika parameter ini belum ditetapkan secara eksplisit, nilai default,`viaQueryHint`, digunakan ketika instance dimulai.
**catatan**
Semua kueri OpenCypher dijalankan oleh mesin DFE terlepas dari bagaimana parameter ini diatur.
Sebelum merilis 1.1.1.0, ini adalah parameter lab-mode daripada parameter instans DB.
## `neptune_query_timeout`(parameter tingkat contoh)
Parameter instans DB ini menentukan durasi batas waktu untuk kueri grafik, dalam milidetik, untuk satu contoh.
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Nilai yang diizinkan berkisar dari `10` ke `2,147,483,647` (231 - 1). Nilai defaultnya adalah `120,000` (2 menit).
**catatan**
Dimungkinkan untuk mengeluarkan biaya tak terduga jika Anda menetapkan nilai batas waktu kueri terlalu tinggi, terutama pada instance tanpa server. Tanpa pengaturan batas waktu yang wajar, Anda mungkin secara tidak sengaja mengeluarkan kueri yang terus berjalan lebih lama dari yang Anda harapkan, menimbulkan biaya yang tidak pernah Anda antisipasi. Hal ini terutama berlaku pada instance tanpa server yang dapat meningkatkan skala hingga jenis instance yang besar dan mahal saat menjalankan kueri.
Anda dapat menghindari pengeluaran tak terduga semacam ini dengan menggunakan nilai batas waktu kueri yang mengakomodasi sebagian besar kueri Anda dan hanya menyebabkan yang berjalan lama secara tak terduga habis.
## `neptune_result_cache`(parameter tingkat contoh)
**`neptune_result_cache`**— Parameter instans DB ini memungkinkan atau menonaktifkan[Hasil kueri cache](gremlin-results-cache.md).
Parameter ini statis, artinya perubahannya tidak berlaku pada instance apa pun sampai di-boot ulang.
Nilai yang diizinkan adalah`0`, (dinonaktifkan, yang merupakan default), dan `1` (diaktifkan).
## `UndoLogPurgeConfig`(parameter tingkat contoh)
**`UndoLogPurgeConfig`**— Gunakan parameter ini untuk mengaktifkan atau menonaktifkan UndoLog pembersihan agresif di Neptunus.
Nilai yang diizinkan adalah`default`, yang menggunakan jumlah standar utas untuk membatalkan pembersihan log, dan`aggressive`, yang menggunakan peningkatan jumlah utas untuk mempercepat pembersihan log pembatalan. Ketika `agressive` opsi dipilih, Anda dapat mengharapkan untuk mengamati nilai yang lebih besar untuk metrik. `NumUndoPagesPurged`
## `neptune_enforce_ssl`(Parameter tingkat cluster usang)
(**Usang) Dulu ada wilayah yang mengizinkan koneksi HTTP ke Neptunus, dan parameter ini digunakan untuk memaksa semua koneksi menggunakan HTTPS saat disetel** ke 1. Parameter ini tidak lagi relevan, namun, karena Neptune sekarang hanya menerima koneksi HTTPS di semua wilayah.
# Meluncurkan cluster DB Neptunus menggunakan Konsol Manajemen AWS
Cara termudah untuk meluncurkan cluster DB Neptunus baru adalah dengan menggunakan template CloudFormation yang membuat semua sumber daya yang diperlukan untuk Anda, seperti yang dijelaskan dalam. [Buat cluster Neptunus](get-started-create-cluster.md)
Jika mau, Anda juga dapat menggunakan konsol Neptunus untuk meluncurkan cluster DB baru secara manual, seperti yang dijelaskan di sini.
**catatan**
Sebelum Anda dapat mengakses konsol Neptunus untuk membuat cluster Neptunus, Anda harus memiliki pengguna dengan izin yang cukup. Jika pengguna Anda saat ini tidak memiliki izin ini maka Anda dapat membuat pengguna IAM dengan izin yang diperlukan untuk melakukannya, seperti yang dijelaskan di. [Membuat pengguna IAM dengan izin untuk Neptunus](manage-console-iam-user.md)
Setelah Anda memverifikasi bahwa pengguna Anda memiliki izin yang benar, atau Anda telah membuat pengguna dengan izin yang benar, masuk ke Konsol Manajemen AWS sebagai pengguna IAM tersebut dan ikuti langkah-langkah di bawah ini untuk membuat cluster DB baru:
**Meluncurkan klaster DB Neptune menggunakan konsol**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Arahkan ke halaman **Clusters** di bawah **Databases** dan pilih **Create database**, yang membuka halaman **Create database**.
1. Di bawah **Pengaturan**, masukkan nama untuk cluster DB baru Anda atau terima nama default yang disediakan di sana. Nama ini digunakan di alamat titik akhir instance, dan harus memenuhi batasan berikut:
+ Pengidentifikasi ini harus berisi 1 hingga 63 karakter alfanumerik atau tanda hubung.
+ Karakter pertamanya harus berupa huruf.
+ Pengidentifikasi ini tidak boleh diakhiri dengan tanda hubung atau mengandung dua tanda hubung berturut-turut.
+ Itu harus unik di semua instans DB di AWS akun Anda di AWS Wilayah tertentu.
1. Di bawah **Template**, pilih **Produksi** atau **Pengembangan dan Pengujian**.
1. Di bawah **ukuran instans DB**, pilih ukuran instans. Ini akan menentukan kapasitas pemrosesan dan memori dari instance penulisan utama cluster DB baru Anda.
Jika Anda memilih template **Produksi**, Anda hanya dapat memilih dari antara kelas yang dioptimalkan memori yang tersedia yang terdaftar, tetapi jika Anda memilih **Pengembangan dan pengujian**, Anda juga dapat memilih dari antara kelas burstable yang lebih ekonomis (lihat [Instans Burstable T3](manage-console-instances-t3.md) untuk diskusi tentang kelas burstable).
**catatan**
Neptunus tidak lagi `R4` mendukung tipe instans.
1. Di bawah **Ketersediaan dan daya tahan**, Anda dapat memilih apakah akan mengaktifkan penyebaran multi-availability-zone (Multi-AZ) atau tidak. Template produksi memungkinkan penerapan Multi-AZ secara default, sedangkan template pengembangan dan pengujian tidak. Jika penerapan multi-AZ diaktifkan, Neptunus akan menemukan instance read-replica yang Anda buat di zona ketersediaan yang berbeda () untuk meningkatkan ketersediaan. AZs
1. Di bawah **Konektivitas**, pilih virtual private cloud (VPC) yang akan meng-host cluster DB baru Anda dari salah satu pilihan yang tersedia. Di sini Anda dapat memilih **Buat VPC baru** jika Anda ingin Neptunus membuat VPC untuk Anda. Anda harus membuat instans Amazon EC2 di VPC yang sama ini untuk mengakses instans Neptunus (untuk informasi selengkapnya, lihat). [Mengamankan database Amazon Neptunus Anda dengan Amazon VPC](security-vpc.md) Perhatikan bahwa Anda tidak dapat mengubah VPC setelah cluster DB dibuat.
Jika perlu, Anda dapat mengonfigurasi konektivitas lebih lanjut untuk klaster Anda di bawah **Konfigurasi konektivitas tambahan**:
1. Di bawah **grup Subnet**, Anda dapat memilih grup subnet Neptunus DB yang akan digunakan untuk cluster DB baru. Jika VPC Anda belum memiliki grup subnet, Neptunus membuat grup subnet DB untuk Anda (lihat). [Mengamankan database Amazon Neptunus Anda dengan Amazon VPC](security-vpc.md)
1. Di bawah **grup keamanan VPC**, pilih satu atau beberapa grup keamanan VPC yang ada untuk mengamankan akses jaringan ke kluster DB baru, atau pilih **Buat baru** jika Anda ingin Neptunus membuatnya untuk Anda, lalu berikan nama untuk grup keamanan VPC baru (lihat). [Buat grup keamanan menggunakan konsol VPC](get-started-vpc.md#security-vpc-security-group)
1. Di bawah **port Database**, masukkan TCP/IP port yang akan digunakan database untuk koneksi aplikasi. Neptunus menggunakan `8182` nomor port sebagai default.
1. Di bawah **konfigurasi Notebook**, pilih **Buat buku catatan jika Anda ingin Neptunus membuat notebook** Jupyter untuk Anda di meja kerja Neptunus (lihat dan). [Menggunakan Amazon Neptunus dengan notebook grafik](graph-notebooks.md) [Menggunakan workbench Neptune untuk meng-host notebook Neptune](graph-notebooks.md#graph-notebooks-workbench) Anda kemudian dapat memilih bagaimana notebook baru harus dikonfigurasi:
1. Di bawah **jenis instans Notebook**, pilih salah satu kelas instans yang tersedia untuk notebook Anda.
1. Di bawah **nama Notebook**, masukkan nama untuk buku catatan Anda.
1. Jika mau, Anda juga dapat memasukkan deskripsi notebook di bawah **Deskripsi - opsional**.
1. Di bawah **nama peran IAM**, pilih agar Neptunus membuat peran IAM untuk buku catatan, dan masukkan nama untuk peran baru, atau pilih untuk memilih peran IAM yang ada dari antara peran yang tersedia.
1. Terakhir, pilih apakah notebook Anda terhubung ke internet secara langsung atau melalui Amazon SageMaker AI atau melalui VPC dengan gateway NAT. Lihat [Connect Instance Notebook ke Resources di VPC](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html) untuk informasi selengkapnya.
1. Di bawah **Tag**, Anda dapat mengaitkan hingga 50 tag dengan cluster DB baru Anda.
1. Di bawah **Konfigurasi tambahan**, ada lebih banyak pengaturan yang dapat Anda buat untuk cluster DB baru Anda (dalam banyak kasus, Anda dapat melewatinya dan menerima nilai default untuk saat ini):
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/manage-console-launch-console.html)
1. Pilih **Buat database** untuk meluncurkan cluster DB Neptunus baru Anda dan instans utamanya.
Pada konsol Amazon Neptune, klaster DB baru muncul dalam daftar basis data. Klaster DB memiliki status **Membuat** hingga klaster DB tersebut dibuat dan siap digunakan. Saat status berubah menjadi **Tersedia**, Anda dapat terhubung ke instans primer untuk klaster DB Anda. Bergantung pada kelas instans DB dan penyimpanan yang dialokasikan, itu dapat memerlukan beberapa menit agar instans baru tersedia.
Untuk melihat klaster yang baru dibuat, pilih tampilan **Basis data** di Neptune konsol.
**catatan**
Jika Anda menghapus semua instans DB Neptunus di cluster DB menggunakan Konsol Manajemen AWS, konsol secara otomatis menghapus cluster DB itu sendiri. Jika Anda menggunakan AWS CLI atau SDK, Anda harus menghapus cluster DB secara manual setelah Anda menghapus instance terakhirnya.
Catat nilai **endpoint Cluster**. Anda perlu ini untuk terhubung ke klaster DB Neptune Anda.
# Menghentikan dan memulai cluster DB Amazon Neptunus
Menghentikan dan memulai klaster Amazon Neptune membantu Anda mengelola biaya untuk pengembangan dan pengujian lingkungan. Anda dapat menghentikan sementara semua instans DB di klaster Anda, bukan mengatur dan merombak semua instans DB setiap kali Anda menggunakan klaster.
**Topics**
+ [Ikhtisar menghentikan dan memulai cluster DB Neptunus](#manage-console-start-stop-overview)
+ [Menghentikan cluster DB Neptunus](#manage-console-stopping)
+ [Memulai cluster DB Neptunus yang berhenti](#manage-console-start)
## Ikhtisar menghentikan dan memulai cluster DB Neptunus
Selama periode ketika Anda tidak memerlukan klaster Neptune, Anda dapat menghentikan semua instans dalam klaster itu sekaligus. Anda dapat memulai klaster lagi kapan pun diperlukan. Memulai dan menghentikan akan menyederhanakan proses penyiapan dan perombakan pada klaster yang digunakan untuk pengembangan, pengujian, atau aktivitas serupa yang tidak memerlukan ketersediaan yang berkelanjutan. Anda dapat mencapai ini Konsol Manajemen AWS dengan satu tindakan, terlepas dari berapa banyak contoh yang ada di cluster.
Saat klaster DB dihentikan, Anda hanya dikenakan biaya untuk penyimpanan klaster, snapshot manual, dan penyimpanan cadangan otomatis dalam periode penyimpanan yang ditentukan. Anda tidak dikenakan biaya untuk jam instans DB.
Setelah tujuh hari, Neptune secara otomatis memulai klaster DB Anda untuk memastikan tidak tertinggal pembaruan pemeliharaan yang diperlukan.
Untuk meminimalkan biaya klaster Neptune yang bermuatan ringan, Anda dapat menghentikan klaster tersebut alih-alih menghapus semua replika baca. Untuk cluster dengan lebih dari satu atau dua instance, sering menghapus dan membuat ulang instans DB hanya praktis menggunakan API atau AWS CLI Neptunus, dan penghapusan juga bisa sulit dilakukan dalam urutan yang benar. Misalnya, Anda harus menghapus semua replika baca sebelum menghapus instans utama untuk menghindari pengaktifan mekanisme failover.
Jangan gunakan memulai dan menghentikan jika Anda perlu menjaga klaster DB tetap berjalan tetapi Anda ingin mengurangi kapasitas. Jika klaster Anda terlalu mahal atau tidak terlalu sibuk, Anda bisa menghapus satu atau lebih instans DB atau ubah instans DB Anda untuk meggunakan kelas instans lebih kecil, tetapi Anda tidak dapat menghentikan instans DB individu.
## Menghentikan cluster DB Neptunus
Ketika Anda tidak akan menggunakannya untuk sementara waktu, Anda dapat menghentikan cluster DB Neptunus yang sedang berjalan, dan kemudian memulainya lagi saat Anda membutuhkannya. Sementara klaster Anda dihentikan, Anda dikenakan biaya untuk penyimpanan klaster, snapshot manual, dan penyimpanan cadangan otomatis dalam jendela penyimpanan yang ditentukan, tapi tidak untuk jam instans DB.
Operasi stop menghentikan semua instans replika baca kluster sebelum menghentikan instans utama, untuk menghindari pengaktifan mekanisme failover.
### Menghentikan cluster DB menggunakan Konsol Manajemen AWS
**Untuk menggunakan Konsol Manajemen AWS untuk menghentikan cluster Neptunus**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**, lalu pilih salah satu klaster. Anda dapat melakukan operasi penghentian dari halaman ini, atau membuka halaman detail untuk klaster DB yang ingin Anda hentikan.
1. Di **Tindakan**, pilih **Berhenti**.
### Menghentikan cluster DB menggunakan AWS CLI
Untuk menghentikan instance DB dengan menggunakan AWS CLI, panggil [stop-db-cluster](api-clusters.md#StopDBCluster)perintah, menggunakan `--db-cluster-identifier` parameter untuk mengidentifikasi cluster DB yang ingin Anda hentikan.
**Example**
```
aws neptune stop-db-cluster --db-cluster-identifier mydbcluster
```
### Menghentikan cluster DB menggunakan API manajemen Neptunus
[Untuk menghentikan instans DB dengan menggunakan API manajemen Neptunus, panggil DBCluster Stop API dan gunakan `DBClusterIdentifier` parameter untuk mengidentifikasi cluster DB yang ingin Anda hentikan.](api-clusters.md#StopDBCluster)
### Apa yang bisa terjadi saat cluster DB dihentikan
+ Anda **dapat** memulihkannya dari snapshot (lihat [Melakukan pemulihan dari Snapshot Klaster DB](backup-restore-restore-snapshot.md)).
+ Anda **tidak dapat** memodifikasi konfigurasi klaster DB, atau salah satu dari instans DB-nya.
+ Anda **tidak dapat** menambah atau menghapus instans DB dari klaster.
+ Anda **tidak dapat** menghapus klaster jika masih memiliki segala yang terkait dengan instans DB.
+ Secara umum, Anda harus memulai kembali klaster DB yang berhenti untuk melakukan sebagian besar tindakan administratif.
+ Neptune menerapkan pemeliharaan terjadwal pada klaster Anda yang dihentikan segera setelah dimulai lagi. Ingat setelah tujuh hari, Neptune secara otomatis memulai kembali klaster yang telah dihentikan sehingga tidak jauh tertinggal dalam status pemeliharaan.
+ Neptune tidak melakukan pencadangan otomatis kluster DB, karena data yang mendasari tidak berubah saat klaster dihentikan.
+ Neptune tidak memperpanjang periode penyimpanan cadangan untuk klaster DB saat klaster dihentikan.
## Memulai cluster DB Neptunus yang berhenti
Anda hanya dapat memulai sebuah klaster DB Neptune yang berada dalam keadaan berhenti. Saat Anda memulai klaster tersebut, semua instans DB menjadi tersedia lagi. Klaster menjaga pengaturan konfigurasinya, seperti titik akhir, grup parameter, dan grup keamanan VPC.
### Memulai cluster DB yang berhenti menggunakan Konsol Manajemen AWS
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**, lalu pilih salah satu klaster. Anda dapat melakukan operasi mulai dari halaman ini, atau navigasi ke halaman detail untuk klaster DB tersebut mulai dari sini.
1. Di **Tindakan**, pilih **Mulai**.
### Memulai cluster DB yang berhenti menggunakan AWS CLI
Untuk memulai cluster DB yang dihentikan menggunakan AWS CLI, panggil [start-db-cluster](api-clusters.md#StartDBCluster)perintah menggunakan `--db-cluster-identifier` parameter untuk menentukan cluster DB berhenti yang ingin Anda mulai. Menyediakan nama klaster yang ingin Anda pilih saat membuat klaster DB atau gunakan nama instans DB yang Anda pilih dengan `-cluster` yang ditambahkan ke bagian akhir.
**Example**
```
aws neptune start-db-cluster --db-cluster-identifier mydbcluster
```
### Memulai cluster DB yang dihentikan menggunakan API manajemen Neptunus
[Untuk memulai cluster DB Neptunus dengan menggunakan API manajemen Neptunus, panggil DBCluster Start API menggunakan parameter untuk menentukan cluster DB berhenti `DBCluster` yang ingin Anda mulai.](api-clusters.md#StartDBCluster) Menyediakan nama klaster yang Anda pilih saat membuat klaster DB atau gunakan nama instans DB yang Anda pilih, dengan `-cluster` yang ditambahkan ke bagian akhir.
# Kosongkan klaster DB Amazon Neptune menggunakan API reset cepat
API REST reset cepat Neptune memungkinkan Anda mereset grafik Neptune dengan cepat dan mudah, menghapus semua datanya.
Anda dapat melakukan ini dalam notebook Neptunus menggunakan sihir baris %db\$1reset[.](#manage-console-fast-reset-db-reset-magic)
+ Dalam kebanyakan kasus, operasi reset cepat selesai dalam beberapa menit. Durasi dapat bervariasi tergantung pada beban pada klaster saat operasi dimulai.
+ Operasi reset cepat tidak menghasilkan di I/Os tambahan.
+ Ukuran volume penyimpanan tidak menyusut setelah reset cepat. Sebaliknya, penyimpanan yang digunakan kembali sebagai data baru dimasukkan. Ini berarti bahwa ukuran volume snapshot yang diambil sebelum dan sesudah operasi reset cepat akan sama. Ukuran volume klaster yang dipulihkan menggunakan snapshot yang dibuat sebelum dan sesudah operasi reset cepat juga akan sama
+ Sebagai bagian dari operasi reset, semua instance di cluster DB dimulai ulang.
**catatan**
Dalam kondisi yang jarang terjadi, restart server ini juga dapat mengakibatkan failover cluster.
**penting**
Menggunakan reset cepat dapat merusak integrasi klaster DB Neptune Anda dengan layanan lainnya. Contoh:
Pengaturan ulang cepat menghapus semua data aliran dari basis data Anda dan benar-benar me-reset pengaliran. Ini berarti bahwa konsumen pengaliran Anda mungkin tidak lagi bekerja tanpa konfigurasi baru.
Reset cepat menghapus semua metadata tentang sumber daya SageMaker AI yang digunakan oleh Neptunus ML, termasuk pekerjaan dan titik akhir. Mereka terus ada di SageMaker AI, dan Anda dapat terus menggunakan titik akhir SageMaker AI yang ada untuk kueri inferensi Neptunus ML, tetapi manajemen Neptunus Neptunus tidak lagi bekerja dengannya. APIs
Integrasi seperti full-text-search integrasi dengan ElasticSearch juga dihapus dengan reset cepat, dan harus dibuat kembali secara manual sebelum dapat digunakan lagi.
**Untuk menghapus semua data dari klaster DB Neptune menggunakan API**
1. Pertama, Anda menghasilkan token yang kemudian dapat Anda gunakan untuk melakukan reset basis data. Langkah ini dimaksudkan untuk membantu mencegah siapa pun dari ketidaksengajaan mereset basis data.
Anda melakukan ini dengan mengirimkan permintaan `HTTP POST` ke titik akhir `/system` pada instans penulis klaster DB Anda untuk menentukan tindakan `initiateDatabaseReset`.
Perintah `curl` menggunakan tipe konten JSON akan menjadi:
```
curl -X POST \
-H 'Content-Type: application/json' \
https://your_writer_instance_endpoint:8182/system \
-d '{ "action" : "initiateDatabaseReset" }'
```
Atau, menggunakan tipe konten `x-www-form-urlencoded`:
```
curl -X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
https://your_writer_instance_endpoint:8182/system \
-d 'action=initiateDatabaseReset '
```
Permintaan `initiateDatabaseReset` mengembalikan token reset dalam respon JSON-nya, seperti ini:
```
{
"status" : "200 OK",
"payload" : {
"token" : "new_token_guid"
}
}
```
Token tetap valid selama satu jam (60 menit) setelah dikeluarkan.
Jika anda mengirim permintaan ke instans pembaca atau ke titik akhir status, Neptune akan membuang `ReadOnlyViolationException`.
Jika Anda mengirim beberapa permintaan `initiateDatabaseReset`, hanya token terbaru yang dihasilkan akan valid untuk langkah kedua, di mana Anda benar-benar melakukan reset.
Jika server dimulai ulang tepat setelah permintaan `initiateDatabaseReset`, token yang dihasilkan menjadi tidak valid, dan Anda perlu mengirim permintaan baru untuk mendapatkan token baru.
1. Selanjutnya, Anda mengirim premintaan `performDatabaseReset` dengan token yang Anda dapatkan kembali dari `initiateDatabaseReset` ke titik akhir `/system` pada instans penulis klaster DB Anda. Ini akan menghapus semua data dari klaster DB Anda.
Perintah `curl` menggunakan tipe konten JSON adalah:
```
curl -X POST \
-H 'Content-Type: application/json' \
https://your_writer_instance_endpoint:8182/system \
-d '{
"action" : "performDatabaseReset",
"token" : "token_guid"
}'
```
Atau, menggunakan tipe konten `x-www-form-urlencoded`:
```
curl -X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
https://your_writer_instance_endpoint:8182/system \
-d 'action=performDatabaseReset&token=token_guid'
```
Permintaan mengembalikan respon JSON. Jika permintaan diterima, tanggapannya adalah:
```
{
"status" : "200 OK"
}
```
Jika token yang Anda kirim tidak cocok dengan token yang dikeluarkan, responnya terlihat seperti ini:
```
{
"code" : "InvalidParameterException",
"requestId":"token_guid",
"detailedMessage" : "System command parameter 'token' : 'token_guid' does not match database reset token"
}
```
Jika permintaan diterima dan reset dimulai, server memulai ulang dan menghapus data. Anda tidak dapat mengirim permintaan lain untuk klaster DB sementara sedang direset.
## Menggunakan API reset cepat dengan IAM-auth
Jika Anda memiliki IAM-auth yang diaktifkan pada klaster DB Anda, Anda dapat menggunakan [awscurl](https://github.com/okigan/awscurl) untuk mengirim perintah reset cepat yang diotentikasi menggunakan IAM-auth:
**Menggunakan awscurl untuk mengirim permintaan cepat-reset dengan IAM-auth**
1. Mengatur variabel lingkungan `AWS_ACCESS_KEY_ID` dan `AWS_SECRET_ACCESS_KEY` dengan benar (dan juga `AWS_SECURITY_TOKEN` jika Anda menggunakan kredensial sementara).
1. Permintaan `initiateDatabaseReset` seperti ini:
```
awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \
-H 'Content-Type: application/json' --region us-west-2 \
-d '{ "action" : "initiateDatabaseReset" }'
```
1. Permintaan `performDatabaseReset` seperti ini:
```
awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \
-H 'Content-Type: application/json' --region us-west-2 \
-d '{ "action" : "performDatabaseReset" }'
```
## Menggunakan meja kerja Neptune line magic `%db_reset` untuk me-reset klaster DB
Meja kerja Neptune mendukung line magic `%db_reset` yang memungkinkan Anda melakukan reset basis data cepat di notebook Neptune.
Jika Anda memanggil magic tanpa parameter apapun, Anda melihat layar menanyakan apakah Anda ingin menghapus semua data dalam klaster Anda, dengan kotak centang meminta Anda untuk mengetahui bahwa data cluster tidak akan lagi tersedia setelah Anda menghapusnya. Pada saat itu, Anda dapat memilih untuk melanjutkan dan menghapus data, atau membatalkan operasi.
Pilihan yang lebih berbahaya adalah mengaktifkan `%db_reset` dengan opsi `--yes` atau `-y`, yang menyebabkan penghapusan akan dilakukan tanpa pemberitahuan lebih lanjut.
Anda juga dapat melakukan reset dalam dua langkah, sama seperti dengan REST API:
```
%db_reset --generate-token
```
Tanggapannya adalah:
```
{
"status" : "200 OK",
"payload" : {
"token" : "new_token_guid"
}
}
```
Lalu lakukan:
```
%db_reset --token new_token_guid
```
Tanggapannya adalah:
```
{
"status" : "200 OK"
}
```
## Kode kesalahan umum untuk operasi reset cepat
| Kode kesalahan Neptune | Status HTTP | Pesan | Contoh |
| --- | --- | --- | --- |
| `InvalidParameterException` | 400 | Parameter perintah sistem '*action*' memiliki nilai yang tidak didukung '' *XXX* | Parameter tidak valid |
| `InvalidParameterException` | 400 | Terlalu banyak nilai yang disediakan untuk: *action* | Permintaan reset cepat dengan lebih dari satu tindakan dikirim dengan header x-www-form-urlencoded 'Content-type:application/ ' |
| `InvalidParameterException` | 400 | Duplikasi bidang 'tindakan' | Permintaan reset cepat dengan lebih dari satu tindakan yang dikirim dengan header 'Content-Type: aplikasi/json' |
| `MethodNotAllowedException` | 400 | Rute buruk:/*bad\$1endpoint* | Permintaan dikirim ke titik akhir yang salah |
| `MissingParameterException` | 400 | Parameter yang dibutuhkan hilang: [action] | Permintaan reset cepat tidak berisi parameter 'tindakan' yang diperlukan |
| `ReadOnlyViolationException` | 400 | Menulis tidak diizinkan pada instans replika baca | Permintaan reset cepat dikirim ke pembaca atau titik akhir status |
| `AccessDeniedException` | 403 | Token Autentikasi Hilang | Permintaan reset cepat dikirim tanpa tanda tangan yang benar ke titik akhir DB dengan IAM-auth yang diaktifkan |
| `ServerShutdownException` | 500 | Reset basis data sedang berlangsung. Silakan coba lagi kueri setelah klaster tersedia. | Kueri Gremlin/Sparql yang ada dan akan datang gagal. |
# Menambahkan instance pembaca Neptunus ke Cluster DB
Dalam cluster DB Neptunus, ada satu instans DB utama dan hingga 15 instance pembaca Neptunus. Instans DB utama mendukung operasi baca dan tulis, dan melakukan semua modifikasi data pada volume klaster. Instance pembaca Neptunus terhubung ke volume penyimpanan yang sama dengan instans DB utama dan hanya mendukung operasi baca.
Gunakan instance pembaca untuk menurunkan beban kerja baca dari instans DB utama.
Kami menyarankan Anda mendistribusikan instans utama dan pembaca Neptunus di cluster DB Anda melalui beberapa Availability Zone untuk meningkatkan ketersediaan cluster DB Anda.
[Bagian berikut](manage-console-create-replica.md) menjelaskan cara membuat instance pembaca di cluster DB Anda.
# Membuat instance pembaca Neptunus menggunakan konsol
Setelah membuat instance utama untuk cluster DB Neptunus Anda, Anda dapat menambahkan instance pembaca Neptunus tambahan menggunakan konsol Neptunus.
**Untuk membuat instance pembaca Neptunus menggunakan Konsol Manajemen AWS**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**.
1. Pilih cluster DB tempat Anda ingin membuat instance pembaca.
1. Pilih **Tindakan**, lalu pilih **Tambah pembaca**.
1. Pada halaman **Membuat replika DB instans**, tentukan opsi untuk replika Neptune Anda. Tabel berikut menunjukkan pengaturan untuk replica baca Neptune.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/manage-console-create-replica.html)
1. Pilih **Membuat replika baca** untuk membuat instans replika Neptune.
Untuk menghapus instance pembaca Neptunus dari kluster DB, ikuti petunjuk [di Menghapus instans DB di Amazon](manage-console-instances-delete.md) Neptunus.
# Memodifikasi Klaster DB Neptune Menggunakan Konsol
Ketika Anda memodifikasi instans DB menggunakan Konsol Manajemen AWS, Anda dapat memilih untuk menerapkan perubahan segera dengan memilih **Terapkan Segera**. Jika Anda memilih untuk menerapkan perubahan langsung, perubahan baru dan perubahan apa pun di antrean modifikasi yang tertunda akan diterapkan sekaligus.
Jika Anda tidak memilih untuk menerapkan perubahan dengan serta-merta, perubahan akan dimasukkan ke dalam antrean perubahan yang tertunda. Selama jendela pemeliharaan berikutnya, perubahan yang tertunda di antrean akan diterapkan.
**penting**
Jika salah satu dari modifikasi yang tertunda memerlukan waktu henti, memilih terapkan langsung dapat menyebabkan waktu henti yang tidak terduga untuk instans DB di pertanyaan. Tidak ada waktu henti untuk instans DB lain dalam klaster DB.
**catatan**
Ketika Anda mengubah klaster DB di Neptune, pengaturan **Terapkan Langsung** hanya mempengaruhi **Pengidentifikasi klaster DB**,**Autentikasi IAM DB**. Semua modifikasi lainnya akan diterapkan dengan segera, tanpa mempertimbangkan nilai pengaturan **Terapkan langsung**.
**Untuk mengubah klaster DB menggunakan konsol**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Klaster**, lalu pilih klaster DB yang ingin Anda modifikasi.
1. Pilih **Tindakan**, dan kemudian pilih **Ubah klaster**. Halaman **Modifikasi klaster DB** akan muncul.
1. Ubah pengaturan apa pun yang Anda inginkan.
**catatan**
Di konsol, beberapa perubahan tingkat instans hanya berlaku untuk instans DB saat ini, sedangkan perubahan lainnya berlaku untuk seluruh klaster DB. Untuk mengubah pengaturan yang memodifikasi seluruh klaster DB pada tingkat instans di konsol, ikuti petunjuk di [Memodifikasi instans DB dalam Klaster DB](#manage-console-modify-instance).
1. Jika semua perubahan sesuai keinginan Anda, pilih **Lanjutkan** dan periksa ringkasan.
1. Untuk menerapkan perubahan dengan segera, pilih **Terapkan segera**.
1. Di halaman konfirmasi, tinjau perubahan Anda. Jika sudah benar, pilih **Ubah klaster** untuk menyimpan perubahan Anda.
Untuk mengedit perubahan Anda, pilih **Kembali**, atau batalkan perubahan Anda pilih**Batalkan**.
## Memodifikasi instans DB dalam Klaster DB
**Untuk memodifikasi instans DB dalam klaster DB gunakan konsol**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Instans**, lalu pilih instans DB yang ingin Anda modifikasi.
1. Pilih **Tindakan instans**, dan kemudian pilih **Modifikasi**. Halaman **Modifikasi Instans DB** akan muncul.
1. Ubah pengaturan apa pun yang Anda inginkan.
**catatan**
Beberapa pengaturan berlaku untuk keseluruhan klaster DB dan harus diubah pada tingkat klaster. Untuk mengubah pengaturan tersebut, ikuti petunjuk di [Memodifikasi Klaster DB Neptune Menggunakan Konsol](#manage-console-modify).
Dalam Konsol Manajemen AWS, beberapa perubahan tingkat instance hanya berlaku untuk instans DB saat ini, sedangkan yang lain berlaku untuk seluruh cluster DB.
1. Jika semua perubahan sesuai keinginan Anda, pilih **Lanjutkan** dan periksa ringkasan.
1. Untuk menerapkan perubahan dengan segera, pilih **Terapkan segera**.
1. Di halaman konfirmasi, tinjau perubahan Anda. Jika sudah benar, pilih **Modifikasi Instans DB** untuk menyimpan perubahan Anda.
Untuk mengedit perubahan Anda, pilih **Kembali**, atau batalkan perubahan Anda, pilih**Batalkan**.
# Performa dan Penskalaan di Amazon Neptune
Klaster dan instans DB Neptune diskalakan pada tiga tingkat yang berbeda:
+ [Penskalaan Penyimpanan](#manage-console-performance-scaling-storage)
+ [Penskalaan Instans](#manage-console-performance-scaling-instances)
+ [Penskalaan Baca](#manage-console-performance-scaling-reads)
## Penskalaan Penyimpanan di Neptune
Penyimpanan Neptune otomatis melakukan penskalaan dengan data dalam volume kluster Anda. Seiring pertumbuhan data Anda, penyimpanan volume cluster Anda bertambah, hingga 128 TiB di semua wilayah yang didukung kecuali China dan GovCloud, di mana terbatas pada 64 TiB.
Ukuran volume klaster Anda diperiksa setiap jam untuk menentukan biaya penyimpanan Anda.
Penyimpanan yang dikonsumsi oleh database Neptunus Anda ditagih dalam kenaikan per GB-bulan dan yang dikonsumsi oleh basis data Neptunus Anda, I/Os consumed are billed in per million request increments. You pay only for the storage and I/Os dan Anda tidak perlu menyediakan terlebih dahulu.
Untuk informasi harga, lihat [halaman produk Neptune](https://aws.amazon.com/neptune/pricing).
## Penskalaan Instans di Neptune
Anda dapat menskalakan klaster Neptune DB sesuai kebutuhan dengan memodifikasi kelas instans DB untuk setiap instans DB dalam klaster DB. Neptune mendukung beberapa kelas instans DB yang dioptimalkan.
## Penskalaan Baca di Neptune
Anda dapat mencapai penskalaan baca untuk klaster DB Neptune dengan membuat hingga 15 replika Neptune dalam klaster DB. Setiap replika Neptune menghasilkan data yang sama dari volume klaster dengan sedikit penundaan replika (sering kali kurang dari 100 milidetik setelah instans utama menulis pembaruan). Saat lalu lintas baca meningkat, Anda dapat membuat replika Neptune tambahan dan terhubung langsung ke mereka untuk mendistribusikan beban baca untuk klaster DB Anda. Replika Neptune tidak harus dari kelas instans DB yang sama dengan instans utama.
Untuk informasi tentang menambahkan replika Neptune ke klaster DB, lihat [Menambahkan instance pembaca](manage-console-create-replica.md).
# Penskalaan otomatis jumlah replika di cluster DB Amazon Neptunus
Anda dapat menggunakan auto-scaling Neptunus untuk secara otomatis menyesuaikan jumlah replika Neptunus dalam cluster DB untuk memenuhi persyaratan konektivitas dan beban kerja Anda. Penskalaan otomatis memungkinkan cluster DB Neptunus Anda menangani peningkatan beban kerja, dan kemudian, ketika beban kerja berkurang, auto-scaling menghapus replika yang tidak perlu sehingga Anda tidak membayar untuk kapasitas yang tidak digunakan.
Anda hanya dapat menggunakan auto-scaling dengan cluster DB Neptunus yang sudah memiliki satu instance penulis utama dan setidaknya satu instance read-replica (lihat). [Klaster dan Instans DB Amazon Neptune](feature-overview-db-clusters.md) Selain itu, semua instance read-replica di cluster harus dalam keadaan tersedia. Jika ada replika baca dalam keadaan selain tersedia, penskalaan otomatis Neptunus tidak melakukan apa pun sampai setiap replika baca di cluster tersedia.
Lihat [Buat cluster Neptunus](get-started-create-cluster.md) apakah Anda perlu membuat cluster baru.
Dengan menggunakan AWS CLI, Anda menentukan dan menerapkan [kebijakan penskalaan](#manage-console-autoscaling-define-policy) ke cluster DB. Anda juga dapat menggunakan AWS CLI untuk mengedit atau menghapus kebijakan auto-scaling Anda. Kebijakan menentukan parameter auto-scaling berikut:
+ Jumlah minimum dan maksimum replika yang ada di cluster.
+ `ScaleOutCooldown`Interval antara aktivitas penskalaan penambahan replika, dan `ScaleInCooldown` interval antara aktivitas penskalaan penghapusan replika.
+ CloudWatch Metrik dan nilai pemicu metrik untuk penskalaan naik atau turun.
Frekuensi tindakan auto-scaling Neptunus diredam dalam beberapa cara:
+ Awalnya, untuk auto-scaling untuk menambah atau menghapus pembaca, `CPUUtilization` alarm tinggi harus dilanggar setidaknya selama 3 menit atau alarm rendah harus dilanggar setidaknya selama 15 menit.
+ Setelah penambahan atau penghapusan pertama itu, frekuensi tindakan auto-scaling Neptunus berikutnya dibatasi oleh pengaturan dan dalam kebijakan penskalaan otomatis. `ScaleOutCooldown` `ScaleInCooldown`
Jika CloudWatch metrik yang Anda gunakan mencapai ambang batas tinggi yang Anda tentukan dalam kebijakan Anda, dan jika `ScaleOutCooldown` interval telah berlalu sejak tindakan auto-scaling terakhir, dan jika cluster DB Anda belum memiliki jumlah replika maksimum yang Anda tetapkan, Neptunus auto-scaling akan membuat replika baru menggunakan jenis instance yang sama dengan instance utama cluster DB.
Demikian pula, jika metrik mencapai ambang rendah yang Anda tentukan dan jika `ScaleInCooldown` interval telah berlalu sejak tindakan auto-scaling terakhir, dan jika cluster DB Anda memiliki lebih dari jumlah minimum replika yang Anda tentukan, auto-scaling Neptunus menghapus salah satu replika.
**catatan**
Neptunus auto-scaling hanya menghapus replika yang dibuatnya. Itu tidak menghapus replika yang sudah ada sebelumnya.
Dengan menggunakan parameter cluster [neptune\$1autoscaling\$1config](parameters.md#parameters-db-cluster-parameters-neptune_autoscaling_config) DB, Anda juga dapat menentukan jenis instance replika baca baru yang dibuat oleh auto-scaling Neptunus, jendela pemeliharaan untuk replika baca tersebut, dan tag yang akan dikaitkan dengan masing-masing replika baca baru. Anda memberikan pengaturan konfigurasi ini dalam string JSON sebagai nilai `neptune_autoscaling_config` parameter, seperti ini:
```
"{
\"tags\": [
{ \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" },
{ \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" },
],
\"maintenanceWindow\" : \"wed:12:03-wed:12:33\",
\"dbInstanceClass\" : \"db.r5.xlarge\"
}"
```
Perhatikan bahwa tanda kutip dalam string JSON semua harus lolos dengan karakter garis miring terbalik (). `\` Semua spasi dalam string adalah opsional, seperti biasa.
Salah satu dari tiga pengaturan konfigurasi yang tidak ditentukan dalam `neptune_autoscaling_config` parameter disalin dari konfigurasi instance penulis utama cluster DB.
Ketika [auto-scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/) menambahkan instance read-replica baru, itu akan mengawali ID instans DB dengan (misalnya,). `autoscaled-reader` `autoscaled-reader-7r7t7z3lbd-20210828` Ini juga menambahkan tag ke setiap replika baca yang dibuatnya dengan kunci `autoscaled-reader` dan nilai. `TRUE` Anda dapat melihat tag ini pada tab **Tag** pada halaman detail instans DB di Konsol Manajemen AWS.
```
"key" : "autoscaled-reader", "value" : "TRUE"
```
Tingkat promosi dari semua instance read-replica yang dibuat oleh auto-scaling adalah prioritas terendah, yang secara default. `15` Ini berarti bahwa selama failover, replika apa pun dengan prioritas yang lebih tinggi, seperti yang dibuat secara manual, akan dipromosikan terlebih dahulu. Lihat [Toleransi kesalahan untuk cluster DB Neptunus](backup-restore-overview-fault-tolerance.md).
Neptune auto-scaling diimplementasikan menggunakan Application Auto Scaling dengan kebijakan penskalaan [pelacakan target yang menggunakan metrik Neptunus sebagai](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) metrik yang telah ditentukan sebelumnya. [`CPUUtilization`](cw-metrics.md#cw-metrics-available) CloudWatch
## Menggunakan auto-scaling di cluster DB tanpa server Neptunus
Neptune Serverless merespons jauh lebih cepat daripada auto-scaling Neptunus ketika permintaan melebihi kapasitas instans, dan meningkatkan skala instance alih-alih menambahkan instance lain. Jika auto-scaling dirancang agar sesuai dengan kenaikan atau penurunan beban kerja yang relatif stabil, tanpa server unggul dalam menangani lonjakan cepat dan kegelisahan dalam permintaan.
Memahami kekuatan mereka, Anda dapat menggabungkan auto-scaling dan serverless untuk menciptakan infrastruktur fleksibel yang akan menangani perubahan beban kerja Anda secara efisien dan memenuhi permintaan sambil meminimalkan biaya.
Agar auto-scaling bekerja secara efektif bersama tanpa server, penting untuk [mengonfigurasi pengaturan klaster `maxNCU` tanpa server Anda yang cukup tinggi untuk mengakomodasi](neptune-serverless-capacity-scaling.md#neptune-serverless-capacity-range-max) lonjakan dan perubahan permintaan singkat. Jika tidak, perubahan transien tidak memicu penskalaan tanpa server, yang dapat menyebabkan auto-scaling memutar banyak instance tambahan yang tidak perlu. Jika `maxNCU` disetel cukup tinggi, penskalaan tanpa server dapat menangani perubahan tersebut lebih cepat dan lebih murah.
## Cara mengaktifkan auto-scaling untuk Amazon Neptunus
Penskalaan otomatis hanya dapat diaktifkan untuk cluster DB Neptunus menggunakan file. AWS CLI Anda tidak dapat mengaktifkan auto-scaling menggunakan file. Konsol Manajemen AWS
Selain itu, penskalaan otomatis tidak didukung di wilayah Amazon berikut:
+ Afrika (Cape Town): `af-south-1`
+ Timur Tengah (UEA): `me-central-1`
+ AWS GovCloud (AS-Timur): `us-gov-east-1`
+ AWS GovCloud (AS-Barat): `us-gov-west-1`
Mengaktifkan auto-scaling untuk cluster DB Neptunus melibatkan tiga langkah:
### 1. Daftarkan cluster DB Anda dengan Application Auto Scaling
Langkah pertama dalam mengaktifkan auto-scaling untuk cluster Neptune DB adalah mendaftarkan cluster dengan Application Auto Scaling, menggunakan atau salah satu Application Auto Scaling. AWS CLI SDKs Cluster harus sudah memiliki satu instance utama dan setidaknya satu instance read-replica:
Misalnya, untuk mendaftarkan cluster yang akan diskalakan otomatis dengan dari satu hingga delapan replika tambahan, Anda dapat menggunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)perintah sebagai berikut:
```
aws application-autoscaling register-scalable-target \
--service-namespace neptune \
--resource-id cluster:(your DB cluster name) \
--scalable-dimension neptune:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8
```
Ini setara dengan menggunakan operasi [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html)Application Auto Scaling API.
AWS CLI `register-scalable-target`Perintah mengambil parameter berikut:
+ **`service-namespace`** – Atur ke `neptune`.
Parameter ini setara dengan `ServiceNamespace` parameter di Application Auto Scaling API.
+ **`resource-id`**— Setel ini ke pengidentifikasi sumber daya untuk cluster DB Neptunus Anda. Jenis sumber daya adalah`cluster`, yang diikuti oleh titik dua ('`:`'), dan kemudian nama cluster DB Anda.
Parameter ini setara dengan `ResourceID` parameter di Application Auto Scaling API.
+ **`scalable-dimension`**— Dimensi yang dapat diskalakan dalam hal ini adalah jumlah instance replika di cluster DB, jadi Anda mengatur parameter ini ke. `neptune:cluster:ReadReplicaCount`
Parameter ini setara dengan `ScalableDimension` parameter di Application Auto Scaling API.
+ **`min-capacity`**— Jumlah minimum instance replika DB pembaca yang akan dikelola oleh Application Auto Scaling. Nilai ini harus diatur dalam kisaran dari 0 hingga 15, dan harus sama dengan atau kurang dari nilai yang ditentukan untuk jumlah maksimum Replika Neptunus di. `max-capacity` Harus ada setidaknya satu pembaca di cluster DB agar auto-scaling berfungsi.
Parameter ini setara dengan `MinCapacity` parameter di Application Auto Scaling API.
+ **`max-capacity`**— Jumlah maksimum instans replika DB pembaca di cluster DB, termasuk instans yang sudah ada sebelumnya dan instans baru yang dikelola oleh Application Auto Scaling. Nilai ini harus diatur dalam kisaran dari 0 hingga 15, dan harus sama dengan atau lebih besar dari nilai yang ditentukan untuk jumlah minimum Replika Neptunus di. `min-capacity`
`max-capacity` AWS CLI Parameter ini setara dengan `MaxCapacity` parameter di Application Auto Scaling API.
Saat Anda mendaftarkan cluster DB Anda, Application Auto Scaling membuat peran terkait `AWSServiceRoleForApplicationAutoScaling_NeptuneCluster` layanan. *Untuk informasi selengkapnya, lihat [Peran terkait layanan untuk auto-scaling Aplikasi di Panduan Pengguna Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html).*
### 2. Tentukan kebijakan penskalaan otomatis untuk digunakan dengan cluster DB Anda
Kebijakan penskalaan pelacakan target didefinisikan sebagai objek teks JSON yang juga dapat disimpan dalam file teks. Untuk Neptunus kebijakan ini saat ini hanya dapat menggunakan metrik [`CPUUtilization`](cw-metrics.md#cw-metrics-available) CloudWatch Neptunus sebagai metrik yang telah ditentukan sebelumnya. `NeptuneReaderAverageCPUUtilization`
Berikut adalah contoh kebijakan konfigurasi penskalaan pelacakan target untuk Neptunus:
```
{
"PredefinedMetricSpecification": { "PredefinedMetricType": "NeptuneReaderAverageCPUUtilization" },
"TargetValue": 60.0,
"ScaleOutCooldown" : 600,
"ScaleInCooldown" : 600
}
```
**`TargetValue`**Elemen di sini berisi persentase pemanfaatan CPU di atas yang skala *auto-scaling* keluar (yaitu, menambahkan lebih banyak replika) dan di bawahnya *diskalakan (yaitu, menghapus* replika). Dalam hal ini, persentase target yang memicu penskalaan adalah%. `60.0`
**`ScaleInCooldown`**Elemen menentukan jumlah waktu, dalam detik, setelah aktivitas scale-in selesai sebelum scale-in lain dapat dimulai. Waktu default adalah 300 detik. Di sini, nilai 600 menentukan bahwa setidaknya sepuluh menit harus berlalu antara penyelesaian satu penghapusan replika dan awal yang lain.
**`ScaleOutCooldown`**Elemen menentukan jumlah waktu, dalam detik, setelah aktivitas scale-out selesai sebelum scale-out lainnya dapat dimulai. Waktu default adalah 300 detik. Di sini, nilai 600 menentukan bahwa setidaknya sepuluh menit harus berlalu antara penyelesaian satu penambahan replika dan awal yang lain.
**`DisableScaleIn`**Elemennya adalah Boolean yang jika ada dan disetel untuk `true` menonaktifkan scale-in sepenuhnya, yang berarti bahwa auto-scaling dapat menambahkan replika tetapi tidak akan pernah menghapusnya. Secara default, scale-in diaktifkan, dan `DisableScaleIn` sedang. `false`
###
Setelah mendaftarkan cluster DB Neptune Anda dengan Application Auto Scaling dan menentukan kebijakan penskalaan JSON dalam file teks, selanjutnya terapkan kebijakan penskalaan ke cluster DB terdaftar. Anda dapat menggunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)perintah untuk melakukan ini, dengan parameter seperti berikut:
```
aws application-autoscaling put-scaling-policy \
--policy-name (name of the scaling policy) \
--policy-type TargetTrackingScaling \
--resource-id cluster:(name of your Neptune DB cluster) \
--service-namespace neptune \
--scalable-dimension neptune:cluster:ReadReplicaCount \
--target-tracking-scaling-policy-configuration file://(path to the JSON configuration file)
```
Bila Anda telah menerapkan kebijakan auto-scaling, auto-scaling diaktifkan pada cluster DB Anda.
Anda juga dapat menggunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)perintah untuk memperbarui kebijakan auto-scaling yang ada.
Lihat juga [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)di Referensi *API Application Auto Scaling*.
## Menghapus auto-scaling dari cluster DB Neptunus
Untuk menghapus auto-scaling dari cluster DB Neptunus, gunakan perintah and. AWS CLI [delete-scaling-policy[deregister-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/deregister-scalable-target.html)](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html)
# Mempertahankan Cluster DB Amazon Neptunus Anda
Neptunus melakukan pemeliharaan secara berkala pada semua sumber daya yang digunakannya, termasuk:
+ **Mengganti perangkat keras yang mendasarinya seperlunya.** Ini terjadi di latar belakang, tanpa Anda harus mengambil tindakan apa pun, dan umumnya tidak berpengaruh pada operasi Anda.
+ **Memperbarui sistem operasi yang mendasarinya.** Upgrade sistem operasi dari instans di cluster DB Anda dilakukan untuk meningkatkan kinerja dan keamanan, jadi Anda biasanya harus menyelesaikannya sesegera mungkin. Pembaruan biasanya memerlukan waktu sekitar 10 menit. Pembaruan sistem operasi tidak akan mengubah versi mesin DB atau kelas instans DB dari instans DB.
Biasanya yang terbaik adalah memperbarui instance pembaca di cluster DB terlebih dahulu, dan kemudian instance penulis. Memperbarui pembaca dan penulis pada saat yang sama dapat menyebabkan downtime jika terjadi failover. Perhatikan bahwa instans DB tidak secara otomatis dicadangkan sebelum pembaruan sistem operasi, jadi pastikan untuk membuat cadangan manual sebelum Anda menerapkan pembaruan sistem operasi.
+ **Memperbarui mesin database Neptunus.** Neptunus secara teratur merilis berbagai pembaruan mesin untuk memperkenalkan fitur dan peningkatan baru dan untuk memperbaiki bug.
## Nomor versi mesin
### Penomoran versi sebelum rilis mesin 1.3.0.0
Sebelum November 2019, Neptune hanya mendukung satu versi mesin pada satu waktu, dan versi mesin semuanya mengambil bentuk angka, `1.0.1.0.200`, saat `xxx` adalah nomor patch. Semua versi mesin baru dirilis sebagai tambalan ke versi sebelumnya.
Pada November 2019, Neptunus mulai mendukung beberapa versi, memungkinkan pelanggan mengontrol jalur peningkatan mereka dengan lebih baik. Akibatnya, penomoran rilis mesin berubah.
Dari November 2019 hingga [rilis mesin 1.3.0.0](engine-releases-1.3.0.0.md), nomor versi mesin memiliki 5 bagian. Ambil nomor versi `1.0.2.0.R2` sebagai contoh:
+ Bagian pertama selalu 1.
+ Bagian kedua, `0` di`1.0.2.0.R2`), adalah nomor versi utama database.
+ Bagian ketiga dan keempat, `2.0` in`1.0.2.0.R2`) keduanya nomor versi minor.
+ Bagian kelima (`R2`in`1.0.2.0.R2`) adalah nomor patch.
Sebagian besar pembaruan adalah pembaruan tambalan, dan perbedaan antara tambalan dan pembaruan versi minor tidak selalu jelas.
### Penomoran versi dari rilis mesin 1.3.0.0 aktif
Dimulai dengan [rilis mesin 1.3.0.0,](engine-releases-1.3.0.0.md) Neptunus mengubah cara pembaruan mesin diberi nomor dan dikelola.
Nomor versi mesin sekarang memiliki empat bagian, yang masing-masing sesuai dengan jenis rilis, sebagai berikut:
*product-version***.***major-version***.***minor-version***.***patch-version*
Perubahan yang tidak melanggar dari jenis yang sebelumnya dirilis sebagai tambalan sekarang dirilis sebagai versi minor yang dapat Anda kelola menggunakan pengaturan [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu)instans.
Ini berarti bahwa jika Anda mau, Anda dapat menerima pemberitahuan setiap kali versi minor baru dirilis, dengan berlangganan [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156)acara (lihat [Berlangganan pemberitahuan acara Neptunus](events-subscribing.md)).
Rilis patch sekarang dicadangkan untuk perbaikan bertarget yang mendesak, dan diberi nomor menggunakan bagian terakhir dari nomor versi (`*.*.*.1`,`*.*.*.2`, dan sebagainya).
# Berbagai jenis rilis mesin di Amazon Neptunus
Empat jenis pelepasan mesin yang sesuai dengan empat bagian nomor versi mesin adalah sebagai berikut:
+ **Versi produk** — Ini hanya berubah jika produk mengalami perubahan mendasar dalam fungsionalitas atau antarmuka. Versi produk Neptunus saat ini adalah 1.
+ [**Versi utama — Versi**](#major-versions) utama memperkenalkan fitur baru yang penting dan melanggar perubahan, dan umumnya memiliki masa pakai yang berguna setidaknya dua tahun.
+ [**Versi minor - Versi**](#minor-versions) minor dapat berisi fitur baru, perbaikan, dan perbaikan bug tetapi tidak mengandung perubahan yang melanggar. Anda dapat memilih apakah akan menerapkannya secara otomatis atau tidak selama jendela pemeliharaan berikutnya, dan Anda juga dapat memilih untuk diberi tahu setiap kali dirilis.
+ [**Versi patch — Versi**](#patch-version-updates) patch dirilis hanya untuk mengatasi perbaikan bug yang mendesak atau pembaruan keamanan kritis. Mereka jarang mengandung perubahan yang melanggar, dan mereka secara otomatis diterapkan selama jendela pemeliharaan berikutnya setelah rilis mereka.
## Pembaruan versi utama Amazon Neptunus
Pembaruan versi utama umumnya memperkenalkan satu atau lebih fitur baru yang penting dan sering kali berisi perubahan yang melanggar. Biasanya memiliki masa dukungan sekitar dua tahun. Versi utama Neptunus tercantum [dalam rilis Engine](engine-releases.md), bersama dengan tanggal rilis dan perkiraan akhir masa pakainya.
Pembaruan versi utama sepenuhnya opsional sampai versi utama yang Anda gunakan mencapai akhir masa pakainya. Jika Anda memilih untuk meningkatkan ke versi utama baru, Anda harus menginstal versi baru sendiri menggunakan AWS CLI atau konsol Neptunus seperti yang dijelaskan dalam. [Peningkatan versi mayor](engine-updates-manually.md)
Namun, jika versi utama yang Anda gunakan mencapai akhir masa pakainya, Anda akan diberi tahu bahwa Anda diminta untuk meningkatkan ke versi utama yang lebih baru. Kemudian, jika Anda tidak meningkatkan dalam masa tenggang setelah pemberitahuan, peningkatan ke versi utama terbaru secara otomatis dijadwalkan terjadi selama jendela pemeliharaan berikutnya. Untuk informasi selengkapnya, lihat [Rentang hidup versi mesin](engine-updates-eol-planning.md).
## Pembaruan versi minor Amazon Neptunus
Sebagian besar pembaruan mesin Neptunus adalah pembaruan versi minor. Mereka terjadi cukup sering dan tidak mengandung perubahan yang melanggar.
Jika Anda memiliki [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu)bidang yang disetel ke `true` dalam instance writer (primer) dari cluster DB Anda, pembaruan versi minor diterapkan secara otomatis ke semua instance di cluster DB Anda selama jendela pemeliharaan berikutnya setelah dirilis.
Jika Anda memiliki [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu)bidang yang disetel ke `false` dalam instance penulis cluster DB Anda, mereka diterapkan hanya jika Anda [menginstalnya secara eksplisit](engine-updates-manually.md).
**catatan**
Pembaruan versi minor bersifat mandiri (tidak bergantung pada pembaruan versi minor sebelumnya ke versi utama yang sama), dan kumulatif (berisi semua fitur dan perbaikan yang diperkenalkan dalam pembaruan versi minor sebelumnya). Ini berarti Anda dapat menginstal pembaruan versi minor yang diberikan apakah Anda telah menginstal yang sebelumnya atau tidak.
Sangat mudah untuk melacak rilis versi minor dengan berlangganan [`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156)acara (lihat Berlangganan pemberitahuan acara [Neptunus](events-subscribing.md)). Anda kemudian akan diberi tahu setiap kali versi minor baru dirilis.
Juga, apakah Anda berlangganan notifikasi atau tidak, Anda selalu dapat [memeriksa untuk melihat pembaruan apa yang tertunda](engine-maintenance-management.md#check-pending-updates).
## Pembaruan versi patch Amazon Neptunus
Dalam kasus masalah keamanan atau cacat serius lainnya yang memengaruhi keandalan instans, Neptunus menyebarkan patch wajib. Mereka diterapkan ke semua instance di cluster DB Anda selama jendela pemeliharaan berikutnya tanpa intervensi apa pun dari Anda.
Rilis patch hanya diterapkan ketika risiko tidak menerapkannya lebih besar daripada risiko dan waktu henti apa pun yang terkait dengan penerapannya. Rilis patch jarang terjadi (biasanya setiap beberapa bulan sekali) dan jarang membutuhkan lebih dari sebagian kecil jendela pemeliharaan Anda untuk diterapkan.
# Merencanakan masa pakai versi mesin utama Amazon Neptunus
Versi mesin Neptunus hampir selalu mencapai akhir masa pakainya pada akhir seperempat kalender. Pengecualian hanya terjadi ketika masalah keamanan atau ketersediaan penting muncul.
Ketika versi mesin mencapai akhir masa pakainya, Anda akan diminta untuk meningkatkan basis data Neptunus Anda ke versi yang lebih baru.
Secara umum, versi mesin Neptunus terus tersedia sebagai berikut:
+ **Versi mesin minor:** Versi mesin minor tetap tersedia setidaknya selama 6 bulan setelah dirilis.
+ **Versi mesin utama:** Versi mesin utama tetap tersedia setidaknya selama 12 bulan setelah dirilis.
Setidaknya 3 bulan sebelum versi mesin mencapai akhir masa pakainya, AWS akan mengirimkan pemberitahuan email otomatis ke alamat email yang terkait dengan AWS akun Anda dan memposting pesan yang sama ke [Dasbor AWS Kesehatan](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html) Anda. Ini akan memberi Anda waktu untuk merencanakan dan bersiap untuk meningkatkan.
Ketika versi mesin mencapai akhir masa pakainya, Anda tidak akan lagi dapat membuat cluster atau instance baru menggunakan versi itu, juga tidak akan dapat membuat instance menggunakan versi itu.
Versi mesin yang benar-benar mencapai akhir masa pakainya akan secara otomatis ditingkatkan selama jendela pemeliharaan. Pesan yang dikirimkan kepada Anda 3 bulan sebelum akhir masa pakai versi mesin akan berisi detail tentang apa yang akan melibatkan pembaruan otomatis ini, termasuk versi yang akan Anda upgrade secara otomatis, dampaknya pada cluster DB Anda, dan tindakan yang kami rekomendasikan.
**penting**
Anda bertanggung jawab untuk menjaga versi mesin database Anda tetap terkini. AWS mendesak semua pelanggan untuk meningkatkan basis data mereka ke versi mesin terbaru untuk mendapatkan keuntungan dari perlindungan keamanan, privasi, dan ketersediaan terkini. Jika Anda mengoperasikan database Anda pada mesin atau perangkat lunak yang tidak didukung setelah tanggal penghentian (“Legacy Engine”), Anda menghadapi kemungkinan risiko keamanan, privasi, dan operasional yang lebih besar, termasuk peristiwa downtime.
Pengoperasian database Anda pada mesin apa pun tunduk pada Perjanjian yang mengatur penggunaan AWS Layanan oleh Anda. Mesin Legacy umumnya tidak tersedia. AWS tidak lagi memberikan dukungan untuk Legacy Engine, dan AWS dapat membatasi akses atau penggunaan Legacy Engine kapan saja, jika AWS menentukan Legacy Engine menimbulkan risiko keamanan atau kewajiban, atau risiko bahaya, terhadap Layanan, Afiliasinya AWS, atau pihak ketiga mana pun. Keputusan Anda untuk terus menjalankan Konten Anda di Legacy Engine dapat mengakibatkan Konten Anda menjadi tidak tersedia, rusak, atau tidak dapat dipulihkan. Database yang berjalan pada Legacy Engine tunduk pada Pengecualian Perjanjian Tingkat Layanan (SLA).
DATABASE DAN PERANGKAT LUNAK TERKAIT YANG BERJALAN PADA MESIN LAMA MENGANDUNG BUG, KESALAHAN, CACAT, KOMPONEN AND/OR BERBAHAYA. DENGAN DEMIKIAN, DAN TERLEPAS DARI APA PUN YANG BERTENTANGAN DALAM PERJANJIAN ATAU KETENTUAN LAYANAN, AWS MENYEDIAKAN MESIN LAMA “SEBAGAIMANA ADANYA.”
# Mengelola pembaruan mesin ke cluster DB Neptunus Anda
**catatan**
Pembaruan diterapkan ke semua instans dalam klaster DB pada saat yang sama. Pembaruan memerlukan restart database pada instans tersebut, sehingga Anda mengalami downtime mulai dari 20 atau 30 detik hingga beberapa menit, setelah itu Anda dapat melanjutkan menggunakan cluster DB. Pada kesempatan yang jarang terjadi, failover multi-AZ mungkin diperlukan untuk pembaruan pemeliharaan pada instans untuk diselesaikan.
Untuk upgrade versi utama yang dapat memakan waktu lebih lama untuk diterapkan, Anda dapat menggunakan [strategi penyebaran biru-hijau](neptune-BG-deployments.md) untuk meminimalkan waktu henti.
## Menentukan versi mesin mana yang saat ini Anda gunakan
Anda dapat menggunakan AWS CLI [`get-engine-status`](access-graph-status.md)perintah untuk memeriksa versi rilis mesin mana yang saat ini digunakan cluster DB Anda:
```
aws neptunedata get-engine-status
```
[Output JSON](access-graph-status.md#access-graph-status-sample-output) mencakup `"dbEngineVersion"` bidang seperti ini:
```
"dbEngineVersion": "1.3.0.0",
```
## Periksa untuk melihat pembaruan apa yang tertunda dan tersedia
Anda dapat memeriksa pembaruan yang tertunda ke cluster DB Anda menggunakan konsol Neptunus. Pilih **Database** di kolom kiri dan kemudian pilih cluster DB Anda di panel database. Pembaruan yang tertunda tercantum di kolom **Pemeliharaan**. Jika Anda memilih **Actions** dan kemudian **Maintenance**, Anda memiliki tiga pilihan tentang apa yang harus dilakukan:
+ Tingkatkan sekarang.
+ Upgrade di jendela berikutnya.
+ Tunda peningkatan.
Anda dapat membuat daftar pembaruan mesin yang tertunda menggunakan AWS CLI sebagai berikut:
```
aws neptune describe-pending-maintenance-actions \
--resource-identifier (ARN of your DB cluster)
--region (your region) \
--engine neptune
```
Anda juga dapat membuat daftar pembaruan mesin yang tersedia menggunakan AWS CLI sebagai berikut:
```
aws neptune describe-db-engine-versions \
--region (your region) \
--engine neptune
```
Daftar rilis mesin yang tersedia hanya mencakup rilis yang memiliki nomor versi lebih tinggi dari yang sekarang dan yang jalur pemutakhiran ditentukan.
## Selalu uji sebelum Anda meningkatkan
Saat versi mesin Neptunus mayor atau minor baru dirilis, selalu uji aplikasi Neptunus Anda terlebih dahulu sebelum memutakhirkannya. Peningkatan kecil dapat memperkenalkan fitur atau perilaku baru yang akan memengaruhi kode Anda bahkan tanpa perubahan yang merusak.
Mulailah dengan membandingkan halaman catatan rilis dari versi Anda saat ini dengan versi yang ditargetkan untuk melihat apakah akan ada perubahan dalam versi bahasa kueri atau perubahan melanggar lainnya.
Cara terbaik untuk menguji versi baru sebelum memutakhirkan cluster DB produksi Anda adalah dengan menggunakan solusi penerapan [Neptunus Biru-Hijau](neptune-BG-deployments.md). Dengan begitu Anda dapat menjalankan aplikasi dan kueri pada versi baru tanpa memengaruhi cluster DB produksi Anda.
## Selalu buat snapshot manual sebelum Anda meng-upgrade
Sebelum melakukan upgrade, kami sangat menyarankan agar Anda selalu membuat snapshot manual cluster DB Anda. Memiliki snapshot otomatis hanya menawarkan perlindungan jangka pendek, sedangkan snapshot manual tetap tersedia sampai Anda menghapusnya secara eksplisit.
Dalam kasus tertentu Neptunus membuat snapshot manual untuk Anda sebagai bagian dari proses peningkatan, tetapi Anda tidak harus bergantung pada ini, dan harus membuat snapshot manual Anda sendiri dalam hal apa pun.
Ketika Anda yakin bahwa Anda tidak perlu mengembalikan cluster DB Anda ke status pra-pemutakhiran, Anda dapat secara eksplisit menghapus snapshot manual yang Anda buat sendiri, serta snapshot manual yang mungkin dibuat Neptunus. Jika Neptunus membuat snapshot manual, itu akan memiliki nama yang dimulai `preupgrade` dengan, diikuti dengan nama cluster DB Anda, versi mesin sumber, versi mesin target, dan tanggal.
## Jendela Pemeliharaan Neptune
Jendela perawatan mingguan adalah periode 30 menit di mana pembaruan mesin terjadwal dan perubahan sistem lainnya diterapkan. Sebagian besar acara pemeliharaan selesai selama jendela 30 menit, meskipun acara pemeliharaan yang lebih besar terkadang lebih lama untuk diselesaikan.
Setiap cluster DB memiliki jendela pemeliharaan 30 menit mingguan. Jika Anda tidak menentukan waktu yang disukai untuk itu saat Anda membuat cluster DB, Neptunus secara acak memilih satu hari dalam seminggu dan kemudian secara acak menetapkan periode 30 menit di dalamnya dari blok waktu 8 jam yang bervariasi dengan wilayah.
Di sini, misalnya, adalah blok waktu 8 jam untuk jendela pemeliharaan yang digunakan di beberapa AWS wilayah:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/engine-maintenance-management.html)
Jendela pemeliharaan menentukan kapan operasi yang tertunda dimulai, dan sebagian besar operasi pemeliharaan selesai di dalam jendela, tetapi tugas pemeliharaan yang lebih besar dapat berlanjut di luar waktu akhir jendela.
### Memindahkan jendela pemeliharaan cluster DB Anda
Idealnya, jendela pemeliharaan Anda harus jatuh pada saat Anda cluster berada pada penggunaan terendah. Jika itu tidak benar untuk jendela Anda saat ini, Anda dapat memindahkannya ke waktu yang lebih baik, seperti ini:
**Untuk mengubah jendela pemeliharaan cluster DB**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **database**.
1. Pilih klaster DB yang periode pemeliharaannya ingin diubah.
1. Pilih **Ubah**.
1. Pilih **Tampilkan lebih banyak** di bagian bawah halaman **Modify cluster**.
1. Di bagian **jendela Pemeliharaan pilihan**, atur hari, waktu, dan durasi jendela pemeliharaan sesuai keinginan Anda.
1. Pilih **Berikutnya**.
Di halaman konfirmasi, tinjau perubahan Anda.
1. Untuk menerapkan perubahan ke periode pemeliharaan secara langsung, pilih **Terapkan langsung**.
1. Pilih **Kirim** untuk menerapkan perubahan Anda.
Untuk mengedit perubahan, pilih **Sebelumnya**, atau membatalkan perubahan, pilih **Batalkan**.
## Menggunakan AutoMinorVersionUpgrade untuk mengontrol pembaruan versi minor otomatis
**penting**
`AutoMinorVersionUpgrade`hanya efektif untuk peningkatan versi minor di atas [rilis mesin 1.3.0.0](engine-releases-1.3.0.0.md).
Jika Anda memiliki `AutoMinorVersionUpgrade` bidang yang disetel ke `true` dalam instance writer (primer) dari cluster DB Anda, pembaruan versi minor diterapkan secara otomatis ke semua instance di cluster DB Anda selama jendela pemeliharaan berikutnya setelah dirilis.
Jika Anda memiliki `AutoMinorVersionUpgrade` bidang yang disetel ke `false` dalam instance penulis cluster DB Anda, mereka diterapkan hanya jika Anda [menginstalnya secara eksplisit](engine-updates-manually.md#engine-minor-updates-using-console).
**catatan**
Rilis patch (`*.*.*.1``*.*.*.2`,, dll.) selalu diinstal secara otomatis selama jendela pemeliharaan Anda berikutnya, terlepas dari bagaimana `AutoMinorVersionUpgrade` parameter diatur.
Anda dapat mengatur `AutoMinorVersionUpgrade` menggunakan Konsol Manajemen AWS sebagai berikut:
**Untuk mengatur `AutoMinorVersionUpgrade` menggunakan konsol Neptunus**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**.
1. Pilih instance utama (penulis) dari cluster DB yang ingin Anda atur`AutoMinorVersionUpgrade`.
1. Pilih **Ubah**.
1. Pilih **Tampilkan lebih banyak** di bagian bawah halaman **Modify cluster**.
1. Di bagian bawah halaman yang diperluas, pilih **Aktifkan peningkatan versi minor otomatis** atau **Matikan peningkatan versi minor otomatis**.
1. Pilih **Berikutnya**.
Di halaman konfirmasi, tinjau perubahan Anda.
1. Untuk menerapkan perubahan pada peningkatan versi minor otomatis, pilih **Terapkan segera**.
1. Pilih **Kirim** untuk menerapkan perubahan Anda.
Untuk mengedit perubahan, pilih **Sebelumnya**, atau membatalkan perubahan, pilih **Batalkan**.
Anda juga dapat menggunakan AWS CLI untuk mengatur `AutoMinorVersionUpgrade` bidang. Misalnya, untuk mengaturnya`true`, Anda dapat menggunakan perintah seperti ini:
```
1. aws neptune modify-db-instance \
2. --db-instance-identifier (the ID of your cluster's writer instance) \
3. --auto-minor-version-upgrade \
4. --apply-immediately
```
Demikian pula, untuk mengaturnya`false`, gunakan perintah seperti ini:
```
1. aws neptune modify-db-instance \
2. --db-instance-identifier (the ID of your cluster's writer instance) \
3. --no-auto-minor-version-upgrade \
4. --apply-immediately
```
# Menginstal pembaruan ke mesin Neptunus Anda secara manual
## Menginstal upgrade mesin versi utama
Rilis mesin utama harus selalu dipasang secara manual. Untuk meminimalkan waktu henti dan menyediakan banyak waktu untuk pengujian dan validasi, cara terbaik untuk menginstal versi utama baru umumnya dengan menggunakan solusi penyebaran Biru-Hijau [Neptunus](neptune-BG-deployments.md).
Dalam beberapa kasus Anda juga dapat menggunakan CloudFormation template yang Anda gunakan untuk membuat cluster DB Anda untuk menginstal upgrade versi utama (lihat[Menggunakan CloudFormation template untuk memperbarui versi mesin Cluster DB Neptunus Anda](cfn-engine-update.md)).
Jika Anda ingin segera menginstal pembaruan versi utama, Anda dapat menggunakan perintah CLI seperti berikut:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (identifier for your neptune cluster) \
--engine neptune \
--engine-version (the new engine version) \
--apply-immediately
```
Pastikan untuk menentukan versi mesin yang ingin Anda tingkatkan. Jika tidak, mesin Anda dapat ditingkatkan ke versi yang bukan yang terbaru atau yang Anda harapkan.
Alih-alih`--apply-immediately`, Anda dapat menentukan`--no-apply-immediately`.
Jika klaster Anda menggunakan grup parameter cluster kustom, pastikan untuk menentukan menggunakan paramater ini:
```
--db-cluster-parameter-group-name (name of the custom DB cluster parameter group)
```
Demikian pula, jika ada instance di cluster yang menggunakan grup parameter DB kustom, pastikan untuk menentukannya menggunakan parameter ini:
```
---db-instance-parameter-group-name (name of the custom instance parameter group)
```
## Menginstal upgrade mesin versi minor menggunakan Konsol Manajemen AWS
**Untuk melakukan upgrade versi minor menggunakan konsol Neptunus**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Databases**, lalu pilih cluster DB yang ingin Anda modifikasi.
1. Pilih **Ubah**.
1. Di bawah **Spesifikasi instans**, pilih versi baru yang ingin Anda tingkatkan.
1. Pilih **Berikutnya**.
1. Jika Anda ingin segera menerapkan perubahan, pilih **Terapkan segera**.
1. Pilih **Kirim** untuk memperbarui cluster DB Anda.
## Menginstal upgrade mesin versi minor menggunakan AWS CLI
Anda dapat menggunakan perintah seperti berikut ini untuk melakukan upgrade versi minor tanpa menunggu jendela pemeliharaan berikutnya:
```
aws neptune modify-db-cluster \
--db-cluster-identifier (your-neptune-cluster) \
--engine-version (new-engine-version) \
--apply-immediately
```
Jika Anda memutakhirkan secara manual menggunakan AWS CLI, pastikan untuk menyertakan versi mesin yang ingin Anda tingkatkan. Jika tidak, mesin Anda mungkin ditingkatkan ke versi yang bukan yang terbaru atau yang Anda harapkan.
# Upgrade ke engine versi 1.2.0.0 atau lebih tinggi dari versi yang lebih awal dari 1.2.0.0
[Engine release 1.2.0.0](engine-releases-1.2.0.0.md) memperkenalkan beberapa perubahan signifikan yang dapat membuat upgrade dari versi sebelumnya lebih rumit dari biasanya:
+ [Engine release 1.2.0.0](engine-releases-1.2.0.0.md) memperkenalkan format baru untuk grup parameter kustom dan grup parameter cluster kustom. Akibatnya, jika Anda memutakhirkan dari versi engine lebih awal dari 1.2.0.0 ke engine versi 1.2.0.0 atau lebih tinggi, Anda harus membuat ulang semua grup parameter kustom yang ada dan grup parameter cluster kustom menggunakan keluarga grup parameter. `neptune1.2` Rilis sebelumnya menggunakan keluarga grup parameter`neptune1`, dan grup parameter tersebut tidak akan berfungsi dengan rilis 1.2.0.0 ke atas. Untuk informasi selengkapnya, lihat [Grup parameter Amazon Neptunus](parameter-groups.md).
+ Engine release 1.2.0.0 memperkenalkan format baru untuk membatalkan log. Akibatnya, jika Anda memutakhirkan ke versi 1.2.0.0 atau lebih tinggi dari versi yang lebih awal dari 1.2.0.0, [`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)metrik harus di bawah ambang batas tertentu. Jika tidak, tambalan akan berputar kembali dan gagal. Ambang batas didasarkan pada jenis instance: batas default adalah 40k untuk instance 4xlarge atau lebih besar, dan 10k untuk instance yang lebih kecil dari 4xlarge. Jika `UndoLogListSize` melebihi batas saat Anda mencoba memutakhirkan, proses tambalan akan kembali, pemutakhiran akan dibatalkan, dan acara dengan alasannya akan terlihat di halaman acara cluster. Batasan ini dapat berubah karena alasan operasional tanpa peringatan sebelumnya.
Anda dapat mempercepat tingkat pembersihan dengan memutakhirkan instance penulis cluster, di mana pembersihan terjadi. Melakukan itu sebelum mencoba meningkatkan dapat membantu menurunkan batas `UndoLogListSize` di bawah ambang batas yang berlaku. Meningkatkan ukuran penulis ke jenis instans 24XL dapat meningkatkan tingkat pembersihan Anda menjadi lebih dari satu juta catatan per jam.
Jika `UndoLogListSize` CloudWatch metriknya sangat besar, membuka kasus dukungan dapat membantu Anda mengeksplorasi strategi tambahan untuk menurunkannya di bawah batas yang diperlukan.
+ Akhirnya, ada perubahan besar dalam rilis 1.2.0.0 yang mempengaruhi kode sebelumnya yang menggunakan protokol Bolt dengan otentikasi IAM. Dimulai dengan rilis 1.2.0.0, Bolt membutuhkan jalur sumber daya untuk penandatanganan IAM. Di Java, pengaturan jalur sumber daya mungkin terlihat seperti ini:`request.setResourcePath("/openCypher"));`. Dalam bahasa lain, `/openCypher` dapat ditambahkan ke URI endpoint. Lihat [Menggunakan protokol Bolt](access-graph-opencypher-bolt.md) sebagai contoh.
# Menggunakan CloudFormation template untuk memperbarui versi mesin Cluster DB Neptunus Anda
Anda dapat menggunakan kembali template CloudFormation Neptunus yang Anda gunakan untuk membuat Cluster DB Neptunus Anda untuk memperbarui versi mesinnya.
Peningkatan versi mesin Neptunus bisa kecil atau besar. Menggunakan CloudFormation template dapat membantu dengan upgrade versi utama, yang sering berisi perubahan signifikan. Karena upgrade versi mayor dapat berisi perubahan database yang tidak kompatibel dengan aplikasi yang ada, Anda mungkin juga perlu membuat perubahan pada aplikasi Anda saat melakukan upgrade. Selalu [uji sebelum memutakhirkan](engine-maintenance-management.md#always-test-before-upgrading), dan kami sangat menyarankan agar Anda selalu membuat snapshot manual cluster DB Anda sebelum memutakhirkan.
Perhatikan bahwa Anda harus melakukan upgrade mesin terpisah untuk setiap versi utama. Anda tidak dapat melewati versi utama dan meningkatkan langsung ke versi utama berikut.
Sebelum 17 Mei 2023, jika Anda menggunakan tumpukan CloudFormation Neptunus untuk meningkatkan versi mesin Anda, itu hanya membuat cluster DB kosong baru di tempat Anda saat ini. Namun, pada 17 Mei 2023, tumpukan CloudFormation Neptunus sekarang mendukung peningkatan mesin di tempat yang menyimpan data Anda yang ada.
**catatan**
Jika Anda menggunakan AWS Cloud Development Kit (AWS CDK), pastikan bahwa AWS CDK versi yang digunakan adalah 2.82.0 atau yang lebih baru. Versi sebelum 2.82.0 tidak mendukung peningkatan mesin Neptunus di tempat.
Untuk upgrade versi mayor, template Anda harus menetapkan properti berikut di`DBCluster`:
+ `DBClusterParameterGroup`(Kustom atau Default)
+ `DBInstanceParameterGroupName`
+ `EngineVersion`
Demikian pula, untuk DBInstances melekat pada DBCluster Anda harus mengatur:
+ `DBParameterGroup`(Kustom/Default)
Pastikan bahwa semua grup parameter Anda ditentukan dalam template, apakah mereka default atau kustom.
Dalam kasus grup parameter kustom, pastikan bahwa keluarga grup parameter kustom Anda yang ada kompatibel dengan versi mesin baru. Versi engine lebih awal dari [1.2.0.0](engine-releases-1.2.0.0.md) menggunakan keluarga grup parameter`neptune1`, sedangkan rilis engine dari 1.2.0.0 maju memerlukan keluarga grup parameter. `neptune1.2` Untuk informasi selengkapnya, lihat [Grup parameter Amazon Neptunus](parameter-groups.md).
Untuk upgrade versi mesin utama, tentukan grup parameter dengan keluarga yang sesuai di `DBCluster` `DBInstanceParameterGroupName` lapangan.
Grup parameter default harus ditingkatkan ke grup yang kompatibel dengan versi mesin baru.
Perhatikan bahwa Neptunus secara otomatis me-reboot instans DB setelah upgrade engine.
**Topics**
+ [Contoh: Peningkatan mesin kecil dari 1.2.0.1 ke 1.2.0.2](cfn-engine-update-1201-1202.md)
+ [Contoh: Upgrade versi utama dari 1.1.1.0 ke 1.2.0.2 dengan grup parameter default](cfn-engine-update-1110-1202-default.md)
+ [Contoh: Peningkatan versi utama dari 1.1.1.0 ke 1.2.0.2 dengan grup parameter khusus](cfn-engine-update-1110-1202-custom.md)
+ [Contoh: Upgrade versi utama dari 1.1.1.0 ke 1.2.0.2 dengan campuran grup parameter default dan kustom](cfn-engine-update-1110-1202-mixed.md)
# Contoh: Peningkatan mesin kecil dari 1.2.0.1 ke 1.2.0.2
Temukan cluster DB yang ingin Anda upgrade, dan template yang Anda gunakan untuk membuatnya. Contoh:
```
Description: Base Template to create Neptune Stack with Engine Version 1.2.0.1 using custom Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-cluster-parameter-group-description
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-parameter-group-description
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.1
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Perbarui `EngineVersion` properti dari `1.2.0.1` ke`1.2.0.2`:
```
Description: Template to upgrade minor engine version to 1.2.0.2
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-cluster-parameter-group-description
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1.2
Description: test-cfn-neptune-db-parameter-group-description
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Sekarang gunakan CloudFormation untuk menjalankan template yang direvisi.
# Contoh: Upgrade versi utama dari 1.1.1.0 ke 1.2.0.2 dengan grup parameter default
Temukan `DBCluster` yang ingin Anda tingkatkan, dan templat yang Anda gunakan untuk membuatnya. Contoh:
```
Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using default Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.1.1.0
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
+ Perbarui default `DBClusterParameterGroup` ke yang ada di keluarga grup parameter yang digunakan oleh versi mesin baru (di sini`default.neptune1.2`).
+ Untuk setiap yang `DBInstance` dilampirkan ke`DBCluster`, perbarui default `DBParameterGroup` ke yang ada di keluarga yang digunakan oleh versi mesin baru (di sini`default.neptune1.2`).
+ Setel `DBInstanceParameterGroupName` properti ke grup parameter default dalam keluarga itu (di sini`default.neptune1.2`).
+ Perbarui `EngineVersion` properti dari `1.1.0.0` ke`1.2.0.2`.
Template akan terlihat seperti ini:
```
Description: Template to upgrade major engine version to 1.2.0.2 by using upgraded default parameter groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName: default.neptune1.2
DBInstanceParameterGroupName: default.neptune1.2
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName: default.neptune1.2
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
```
Sekarang gunakan CloudFormation untuk menjalankan template yang direvisi.
# Contoh: Peningkatan versi utama dari 1.1.1.0 ke 1.2.0.2 dengan grup parameter khusus
Temukan `DBCluster` yang ingin Anda tingkatkan, dan templat yang Anda gunakan untuk membuatnya. Contoh:
```
Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Name: engineupgradetestcpg
Family: neptune1
Description: 'NeptuneDBClusterParameterGroup with family neptune1'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Name: engineupgradetestpg
Family: neptune1
Description: 'NeptuneDBParameterGroup1 with family neptune1'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.1.1.0
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
+ Perbarui `DBClusterParameterGroup` keluarga khusus ke yang digunakan oleh versi mesin baru di sini`default.neptune1.2`).
+ Untuk setiap yang `DBInstance` dilampirkan pada`DBCluster`, perbarui `DBParameterGroup` keluarga khusus ke yang digunakan oleh versi mesin baru (di sini`default.neptune1.2`).
+ Setel `DBInstanceParameterGroupName` properti ke grup parameter dalam keluarga itu (di sini`default.neptune1.2`).
+ Perbarui `EngineVersion` properti dari `1.1.0.0` ke`1.2.0.2`.
Template akan terlihat seperti ini:
```
Description: Template to upgrade major engine version to 1.2.0.2 by modifying existing custom parameter groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Name: engineupgradetestcpgnew
Family: neptune1.2
Description: 'NeptuneDBClusterParameterGroup with family neptune1.2'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Name: engineupgradetestpgnew
Family: neptune1.2
Description: 'NeptuneDBParameterGroup1 with family neptune1.2'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DBInstanceParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
NeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Sekarang gunakan CloudFormation untuk menjalankan template yang direvisi.
# Contoh: Upgrade versi utama dari 1.1.1.0 ke 1.2.0.2 dengan campuran grup parameter default dan kustom
Temukan `DBCluster` yang ingin Anda tingkatkan, dan templat yang Anda gunakan untuk membuatnya. Contoh:
```
Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1
Description: 'NeptuneDBClusterParameterGroup with family neptune1'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1
Description: 'NeptuneDBParameterGroup with family neptune1'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.1.1.0
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DependsOn:
- NeptuneDBClusterParameterGroup
CustomNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
DefaultNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
+ Untuk grup parameter cluster khusus, perbarui `DBClusterParameterGroup` keluarga ke yang sesuai dengan versi mesin baru, yaitu`neptune1.2`.
+ Untuk grup parameter cluster default, perbarui `DBClusterParameterGroup` ke default yang sesuai dengan versi mesin baru, yaitu`default.neptune1.2`.
+ Untuk setiap yang `DBInstance` dilampirkan ke`DBCluster`, perbarui default `DBParameterGroup` ke yang ada di keluarga yang digunakan oleh versi mesin baru (di sini`default.neptune1.2`), dan grup parameter khusus ke grup yang menggunakan keluarga yang didukung oleh versi mesin baru (di sini`neptune1.2`).
+ Atur `DBInstanceParameterGroupName` properti ke grup parameter dalam keluarga yang didukung oleh versi mesin baru.
Template akan terlihat seperti ini:
```
Description: Template to update Neptune Stack to Engine Version 1.2.0.1 using custom and default Parameter Groups
Parameters:
DbInstanceType:
Description: Neptune DB instance type
Type: String
Default: db.r5.large
Resources:
NeptuneDBClusterParameterGroup:
Type: 'AWS::Neptune::DBClusterParameterGroup'
Properties:
Family: neptune1.2
Description: 'NeptuneDBClusterParameterGroup with family neptune1.2'
Parameters:
neptune_enable_audit_log: 0
NeptuneDBParameterGroup:
Type: 'AWS::Neptune::DBParameterGroup'
Properties:
Family: neptune1.2
Description: 'NeptuneDBParameterGroup1 with family neptune1.2'
Parameters:
neptune_query_timeout: 20000
NeptuneDBCluster:
Type: 'AWS::Neptune::DBCluster'
Properties:
EngineVersion: 1.2.0.2
DBClusterParameterGroupName:
Ref: NeptuneDBClusterParameterGroup
DBInstanceParameterGroupName: default.neptune1.2
DependsOn:
- NeptuneDBClusterParameterGroup
CustomNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName:
Ref: NeptuneDBParameterGroup
DependsOn:
- NeptuneDBCluster
- NeptuneDBParameterGroup
DefaultNeptuneDBInstance:
Type: 'AWS::Neptune::DBInstance'
Properties:
DBClusterIdentifier:
Ref: NeptuneDBCluster
DBInstanceClass:
Ref: DbInstanceType
DBParameterGroupName: default.neptune1.2
DependsOn:
- NeptuneDBCluster
Outputs:
DBClusterId:
Description: Neptune Cluster Identifier
Value:
Ref: NeptuneDBCluster
```
Sekarang gunakan CloudFormation untuk menjalankan template yang direvisi.
# Kloning Basis Data di Neptune
Menggunakan kloning DB, Anda dapat dengan cepat dan berbiaya-efektif membuat klon dari semua basis data Anda di Amazon Neptune. Basis data klon hanya mensyaratkan ruang tambahan yang minimal saat pertama kali dibuat. Kloning database menggunakan *copy-on-write protokol*. Data disalin pada saat yang sama dengan diubah, baik di basis data sumber maupun basis data klon. Anda dapat membuat beberapa klon dari kluster DB yang sama. Anda juga dapat membuat klon tambahan dari klon lain. Untuk informasi lebih lanjut tentang cara kerja copy-on-write protokol dalam konteks penyimpanan Neptunus, lihat. [Copy-on-Write Protokol](#manage-console-cloning-protocol)
Anda dapat menggunakan kloning DB dalam berbagai kasus penggunaan, khususnya jika Anda tidak ingin memiliki dampak pada lingkungan produksi Anda, seperti berikut ini:
+ Lakukan eksperimen dengan dan nilai dampak perubahan, seperti perubahan skema atau perubahan grup parameter.
+ Lakukan operasi dengan beban kerja intensif, seperti mengekspor data atau menjalankan kueri analitis.
+ Buat salinan klaster DB produksi dalam lingkungan nonproduksi untuk pengembangan atau pengujian.
**Untuk membuat klon dari cluster DB menggunakan Konsol Manajemen AWS**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Instans**. Pilih instans primer untuk klaster DB yang ingin Anda buat klonnya.
1. Pilih **Tindakan Instan**, lalu pilih **Buat klon**.
1. Di halaman **Buat Klon**, ketik nama untuk instans primer klaster DB klon sebagai **Pengidentifikasi instans DB**.
Jika ingin, konfigurasikan pengaturan lain untuk klaster DB klon. Untuk informasi tentang pengaturan klaster DB yang berbeda, lihat [Luncurkan menggunakan konsol](manage-console-launch-console.md).
1. Pilih **Buat Klon** untuk meluncurkan klaster DB klon.
**Untuk membuat klon dari cluster DB menggunakan AWS CLI**
+ Panggil perintah [restore-db-cluster-toNeptunus point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) AWS CLI - dan berikan nilai-nilai berikut:
+ `--source-db-cluster-identifier` – Nama klaster DB sumber untuk membuat klon.
+ `--db-cluster-identifier` – Nama klaster DB klon.
+ `--restore-type copy-on-write` – Nilai `copy-on-write` menunjukkan bahwa klaster DB klon harus dibuat.
+ `--use-latest-restorable-time` – Ini menentukan bahwa waktu pencadangan terbaru yang dapat dipulihkan harus digunakan.
**catatan**
point-in-time AWS CLI Perintah [restore-db-cluster-to-](api-snapshots.md#RestoreDBClusterToPointInTime) hanya mengkloning cluster DB, bukan instance DB untuk cluster DB itu.
Linux/UNIX Contoh berikut membuat klon dari cluster `source-db-cluster-id` DB dan menamai klon`db-clone-cluster-id`.
```
aws neptune restore-db-cluster-to-point-in-time \
--region us-east-1 \
--source-db-cluster-identifier source-db-cluster-id \
--db-cluster-identifier db-clone-cluster-id \
--restore-type copy-on-write \
--use-latest-restorable-time
```
Contoh yang sama bekerja pada Windows jika karakter escape line-end `\`digantikan oleh yang setara dengan Windows `^`:
```
aws neptune restore-db-cluster-to-point-in-time ^
--region us-east-1 ^
--source-db-cluster-identifier source-db-cluster-id ^
--db-cluster-identifier db-clone-cluster-id ^
--restore-type copy-on-write ^
--use-latest-restorable-time
```
## Batasan
Kloning DB di Neptune memiliki batasan sebagai berikut:
+ Anda tidak dapat membuat database klon di seluruh AWS Wilayah. Basis data klon harus dibuat dalam Wilayah yang sama dengan basis data sumber.
+ Basis data yang diklonning selalu menggunakan patch terbaru dari versi mesin Neptune yang sedang digunakan oleh basis data yang diklonning. Hal ini benar bahkan jika basis data sumber belum ditingkatkan ke versi patch tersebut. Tetapi, versi mesin itu sendiri tidak berubah.
+ Saat ini, Anda dibatasi tidak lebih dari 15 klon per salinan cluster DB Neptunus Anda, termasuk klon berdasarkan klon lain. Setelah mencapai batas itu, Anda harus membuat salinan lain dari database Anda daripada mengkloningnya. Namun, jika Anda membuat salinan baru, itu juga dapat memiliki hingga 15 klon.
+ Kloning DB cross-account saat ini tidak didukung.
+ Anda dapat menyediakan Virtual Private Cloud (VPC) yang berbeda untuk klon Anda. Namun, subnet di dalamnya VPCs harus dipetakan ke set Availability Zone yang sama.
## Copy-on-Write Protokol untuk Kloning DB
Skenario berikut menggambarkan bagaimana copy-on-write protokol bekerja.
+ [Basis Data Neptune Sebelum Kloning](#manage-console-cloning-protocol-before)
+ [Basis Data Neptune Setelah Kloning](#manage-console-cloning-protocol-after)
+ [Ketika Perubahan Dibuat ke Basis Data Sumber](#manage-console-cloning-protocol-source-write)
+ [Ketika Perubahan Dibuat ke Basis Data Klon](#manage-console-cloning-protocol-clone-write)
### Basis Data Neptune Sebelum Kloning
Data dalam basis data sumber disimpan dalam halaman. Pada diagram berikut, basis data sumber memiliki empat halaman.
![\[Basis data sumber Neptune sebelum kloning DB dengan 4 halaman.\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/neptune-clone-1.png)
### Basis Data Neptune Setelah Kloning
Seperti yang ditunjukkan dalam diagram berikut, tidak ada perubahan pada basis data sumber setelah kloning DB. Baik basis data sumber dan basis data klon menunjuk ke empat halaman yang sama. Tidak ada halaman yang secara fisik disalin, sehingga tidak perlu penyimpanan tambahan.
![\[Basis data sumber Neptune dan basis data klon database menunjuk ke halaman yang sama setelah kloning DB.\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/neptune-clone-2.png)
### Ketika Perubahan Dibuat ke Basis Data Sumber
Pada contoh berikut, basis data sumber membuat perubahan ke data dalam`Page 1`. Alih-alih menulis ke aslinya `Page 1`, itu menggunakan penyimpanan tambahan untuk membuat halaman baru, disebut `Page 1'`. Basis data sumber sekarang menunjuk ke `Page 1'` baru, dan juga ke `Page 2`, `Page 3`, dan`Page 4`. Basis data klon terus menunjuk ke `Page 1` melalui `Page 4`.
![\[Basis data sumber Neptune dan basis data klon setelah basis data sumber berubah.\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/neptune-clone-3.png)
### Ketika Perubahan Dibuat ke Basis Data Klon
Pada diagram berikut, basis data klon juga telah berubah, kali ini dalam `Page 4`. Alih-alih menulis ke aslinya `Page 4`, penyimpanan tambahan digunakan untuk membuat halaman baru, disebut `Page 4'`. Basis data sumber terus menunjuk ke `Page 1'`, dan juga `Page 2` melalui `Page 4`, namun basis data klon sekarang menunjuk ke `Page 1`melalui `Page 3`, dan juga `Page 4'`.
![\[Basis data sumber Neptune dan basis data klon setelah basis data klon berubah.\]](http://docs.aws.amazon.com/id_id/neptune/latest/userguide/images/neptune-clone-4.png)
Seperti yang ditunjukkan dalam skenario kedua, setelah kloning DB, tidak ada penyimpanan tambahan yang diperlukan pada saat pembuatan klon. Namun, karena perubahan terjadi dalam basis data sumber dan basis data klon, hanya halaman yang diubah yang dibuat, seperti yang ditunjukkan dalam skenario ketiga dan keempat. Karena lebih banyak perubahan yang terjadi seiring waktu baik pada basis data sumber maupun basis data klon, Anda perlu lebih banyak penyimpanan secara bertahap untuk menangkap dan menyimpan perubahan tersebut.
## Menghapus Basis Data Sumber
Menghapus basis data sumber tidak mempengaruhi basis data klon database yang terkait dengannya. Basis data klon terus menunjuk ke halaman yang sebelumnya dimiliki oleh basis data sumber.
# Mengelola Instans Amazon Neptune
Bagian berikut memiliki informasi tentang operasi tingkat instans.
**Topics**
+ [Kelas Instans Burstable Neptune T3.](manage-console-instances-t3.md)
+ [Memodifikasi instans DB Neptune (dan Menerapkan Segera)](manage-console-instances-modify.md)
+ [Mengganti nama Instans DB Neptune](manage-console-instances-rename.md)
+ [Mem-boot ulang instans DB di Amazon Neptunus](manage-console-instances-reboot.md)
+ [Menghapus sebuah Instans DB di Amazon Neptune](manage-console-instances-delete.md)
# Kelas Instans Burstable Neptune T3.
Sbagai tambahan kelas instans performa tetap seperti `R5` dan `R6`, Amazon Neptune memberi Anda opsi menggunakan performa burstable-instans `T3`. Sementara Anda sedang mengembangkan aplikasi grafik Anda, Anda ingin basis data Anda menjadi cepat dan responsif, tetapi Anda tidak perlu menggunakannya sepanjang waktu. Kelas instans `db.t3.medium` Neptune satu-satunya yang harus Anda gunakan dalam situasi itu, dengan biaya secara signifikan lebih rendah daripada kelas instans performa tetap paling mahal.
Instans burstable berjalan pada tingkat dasar performa CPU sampai beban kerja membutuhkan lebih banyak, dan kemudian melakukan burst jauh di atas dasar untuk selama beban kerja memerlukannya. Harga per jam mencakup burstnya, asalkan pemanfaatan CPU rata-rata tidak melebihi baseline selama periode 24 jam. Untuk kebanyakan situasi pengembangan dan pengujian, yaitu menerjemahkan ke performa yang baik dengan biaya rendah.
Jika Anda memulai dengan kelas `T3` instance, Anda dapat dengan mudah beralih nanti ke kelas instance performa tetap saat Anda siap untuk masuk ke produksi, menggunakan, Konsol Manajemen AWS AWS CLI, atau salah satu kelas. AWS SDKs
## Bursting T3 diatur oleh CPU Credit
Sebuah kredit CPU mewakili pemanfaatan penuh dari satu inti CPU virtual (vCPU) selama satu menit. Itu juga dapat diterjemahkan menjadi 50% pemanfaatan vCPU selama dua menit, atau 25% pemanfaatan dua CPUs v selama dua menit, dan seterusnya.
Instans `T3` menghasilkan kredit CPU saat diam dan menggunakannya saat aktif, keduanya diukur pada resolusi milidetik. Kelas `db.t3.medium` instance memiliki dua vCPUs, yang masing-masing menghasilkan 12 kredit CPU per jam saat idle. Ini berarti bahwa 20% pemanfaatan setiap vCPU menghasilkan saldo kredit CPU nol. Kredit CPU 12 yang diperoleh dihabiskan oleh pemanfaatan 20% vCPU (sejak 20% dari 60 menit juga 12). Dengan demikian, pemanfaatan 20% ini adalah tingkat pemanfaatan *dasar* yang menghasilkan tidak keseimbangan CPU-credit positif maupun negatif.
Waktu diam (pemanfaatan CPU di bawah 20% dari total yang tersedia) menyebabkan kredit CPU disimpan dalam bucket saldo kredit, sampai batas untuk kelas instans `db.t3.medium` 576 (jumlah maksimum kredit CPU yang dapat diperoleh dalam 24 jam, yaitu 2 x 12 x 24). Lebih dari batas itu, kredit CPU hanya dibuang.
Bila diperlukan, pemanfaatan CPU dapat meledak hingga setinggi 100% selama dibutuhkan oleh beban kerja, bahkan setelah saldo kredit CPU turun di bawah nol. Jika instans mempertahankan saldo negatif terus menerus selama 24 jam, itu akan dikenakan biaya tambahan sebesar \$10,05 untuk setiap -60 kredit CPU di atas periode tersebut. Namun, untuk sebagian besar pengembangan dan beban kerja pengujian, bursting biasanya dilindungi oleh waktu idle sebelum atau setelah burst.
**catatan**
Kelas `T3` instance Neptunus dikonfigurasi seperti mode EC2 [tak terbatas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) Amazon.
## Menggunakan Konsol Manajemen AWS untuk Membuat Instance Burstable T3
Dalam Konsol Manajemen AWS, Anda dapat membuat instance cluster DB primer atau instance read-replica yang menggunakan kelas `db.t3.medium` instance, atau Anda dapat memodifikasi instance yang ada untuk menggunakan kelas instance. `db.t3.medium`
Misalnya, untuk membuat instans utama klaster DB baru di konsol Neptune:
+ Pilih **Buat Basis Data**.
+ Pilih **Versi mesin DB** sama dengan atau lebih lambat dari `1.0.2.2`.
+ Di bawah **Tujuan**, pilih **Pengembangan dan Pengujian**.
+ Sebagai **Kelas instans DB**, terima default: `db.t3.medium — 2 vCPU, 4 GiB RAM`.
## Menggunakan AWS CLI untuk Membuat Instance Burstable T3
Anda juga dapat menggunakan AWS CLI untuk melakukan hal yang sama:
```
aws neptune create-db-cluster \
--db-cluster-identifier (name for a new DB cluster) \
--engine neptune \
--engine-version "1.0.2.2"
aws neptune create-db-instance \
--db-cluster-identifier (name of the new DB cluster) \
--db-instance-identifier (name for the primary writer instance in the cluster) \
--engine neptune \
--db-instance-class db.t3.medium
```
# Memodifikasi instans DB Neptune (dan Menerapkan Segera)
Anda dapat menerapkan sebagian besar perubahan ke instans DB Amazon Neptune segera atau menunda hingga waktu pemeliharaan berikutnya. Beberapa modifikasi, seperti perubahan grup parameter, memerlukan boot ulang instans DB secara manual agar dapat diterapkan.
**penting**
Modifikasi mengakibatkan pemadaman jika Neptunus harus me-reboot instans DB Anda agar perubahan diterapkan. Tinjau dampak pada database dan aplikasi Anda sebelum memodifikasi pengaturan instans DB.
## Implikasi Pengaturan Umum dan Waktu Henti
Tabel berikut berisi detail tentang pengaturan mana yang dapat diubah, kapan perubahan dapat diterapkan, dan apakah perubahan menyebabkan waktu henti untuk instans DB.
****
| Pengaturan instans DB | Catatan waktu henti |
| --- | --- |
| **Kelas instans DB** | Pemadaman terjadi selama perubahan ini, apakah itu diterapkan segera atau selama jendela pemeliharaan berikutnya. |
| **Pengidentifikasi instans DB** | Instans DB di-boot ulang dan pemadaman terjadi selama perubahan ini, apakah itu diterapkan segera atau selama jendela pemeliharaan berikutnya. |
| **Grup subnet** | Instans DB di-boot ulang dan pemadaman terjadi selama perubahan ini, apakah itu diterapkan segera atau selama jendela pemeliharaan berikutnya. |
| **Grup keamanan** | Perubahan diterapkan secara asinkron sesegera mungkin, terlepas dari kapan Anda menentukan perubahan harus dilakukan, dan tidak ada hasil pemadaman. | – |
| **Otoritas Sertifikat** | Secara default, instans DB dimulai ulang saat Anda menetapkan Otoritas Sertifikat baru. |
| **Pelabuhan Database** | Perubahan selalu terjadi segera, menyebabkan instans DB di-boot ulang, dan terjadi pemadaman. |
| **Grup parameter DB** | Mengubah pengaturan ini tidak mengakibatkan pemadaman listrik. Nama grup parameter itu sendiri segera berubah, tetapi perubahan parameter yang sebenarnya tidak diterapkan sampai Anda me-reboot instans tanpa failover. Dalam kasus ini, instans DB tidak di-reboot secara otomatis, dan perubahan parameter tidak diterapkan selama jendela pemeliharaan berikutnya. Namun, jika Anda memodifikasi parameter dinamis dalam grup parameter DB yang baru terkait, perubahan ini diterapkan segera tanpa reboot. Untuk informasi selengkapnya, lihat [Mem-boot ulang instans DB di Amazon Neptunus](manage-console-instances-reboot.md). |
| **Grup parameter klaster basis data** | Nama grup parameter DB segera diubah. |
| **Periode retensi cadangan** | Jika Anda menentukan bahwa perubahan harus segera terjadi, perubahan ini segera terjadi. Jika tidak, jika Anda mengubah pengaturan dari nilai bukan nol ke nilai bukan nol lainnya, perubahan diterapkan secara asinkron, sesegera mungkin. Perubahan lain terjadi selama jendela pemeliharaan berikutnya. Pemadaman terjadi jika Anda mengubah dari nilai 0 ke nilai bukan nol, atau dari nilai bukan nol ke 0. |
| **Log audit** | Pilih **Log audit** jika Anda ingin menggunakan pencatatan audit melalui CloudWatch Log. Anda juga harus mengatur `neptune_enable_audit_log` parameter dalam grup parameter cluster DB ke `enable` (1) agar pencatatan audit diaktifkan. |
| **Peningkatan versi minor otomatis** | Pilih **Aktifkan upgrade versi minor otomatis** jika Anda ingin mengaktifkan klaster DB Neptune agar menerima upgrade versi mesin minor secara otomatis saat tersedia. Opsi *Upgrade versi minor otomatis* hanya berlaku untuk upgrade versi mesin minor untuk klaster DB Amazon Neptune Anda. Opsi ini tidak berlaku untuk patch biasa yang diterapkan untuk menjaga stabilitas sistem. |
# Mengganti nama Instans DB Neptune
Anda dapat mengubah nama instans DB Amazon Neptune dengan menggunakan Konsol Manajemen AWS. Mengganti nama instans DB dapat memiliki efek yang jauh jangkauannya. Berikut ini adalah daftar hal-hal yang harus Anda ketahui sebelum mengubah nama instans DB.
+ Saat Anda mengubah nama instance DB, titik akhir untuk instans DB berubah, karena URL mencakup nama yang Anda tetapkan ke instans DB. Anda harus selalu mengalihkan lalu lintas dari URL lama ke yang baru.
+ Saat Anda mengganti nama instans DB, nama DNS lama yang digunakan oleh instans DB akan segera dihapus, meskipun tetap disimpan selama beberapa menit. Nama DNS baru untuk instans DB yang diubah namanya menjadi efektif dalam waktu sekitar 10 menit. Instans DB yang diubah namanya tidak tersedia hingga nama baru menjadi efektif.
+ Anda tidak dapat menggunakan nama instans DB yang sudah ada saat Anda melakukan penggantian nama suatu instans.
+ Semua replika baca terkait dengan suatu instans DB tetap terkait dengan instans tersebut setelah diberi nama ulang. Misalnya, bayangkan Anda memiliki instans DB yang melayani basis data produksi Anda dan instans tersebut memiliki beberapa replika baca terkait. Jika Anda mengganti nama instans DB lalu IT di lingkungan produksi dengan snapshot DB, instans DB yang Anda ubah namanya masih memiliki replika baca yang terkait dengannya.
+ Metrik dan peristiwa terkait dengan nama instans DB dipertahankan jika Anda menggunakan ulang nama instans DB. Misalnya, jika Anda mempromosikan replika baca dan mengganti namanya menjadi nama instance utama sebelumnya, peristiwa dan metrik yang dikaitkan dengan instance utama kemudian dikaitkan dengan instance yang diganti namanya.
+ Tag instans DB akan dipertahankan dengan instans DB, terlepas dari perubahan namanya.
+ Snapshot DB dipertahankan untuk instans DB yang diubah namanya.
**Mengganti nama instans DB dengan menggunakan konsol Neptune.**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**.
1. Pilih tombol radio di samping instans DB yang ingin Anda ubah namanya.
1. Di menu **Tindakan instans**, pilih **Memodifikasi**.
1. Masukkan nama baru di **Pengidentifikasi instans DB** kotak teks. Pilih **Langsung Terapkan**, lalu pilih **Lanjutkan**.
1. Pilih **Modifikasi instans DB** untuk menyelesaikan perubahan.
# Mem-boot ulang instans DB di Amazon Neptunus
Dalam beberapa kasus, jika Anda memodifikasi instans DB Amazon Neptune, ubah grup parameter DB yang berhubungan dengan instans, atau ubah parameter DB statis dalam grup parameter yang digunakan instans, Anda harus mereboot instans untuk menerapkan perubahan.
Boot ulang instans DB akan mengaktifkan ulang layanan mesin basis data. Reboot juga berlaku untuk instans DB, perubahan apa pun pada grup parameter DB terkait yang tertunda. Mereboot instans DB akan menyebabkan matinya sementara, selama status instans DB diatur ke *rebooting*. Jika instans Neptune dikonfigurasi untuk Multi-AZ, boot ulang dapat dilakukan melalui failover. Peristiwa Neptune dibuat saat boot ulang selesai.
Jika instans DB Anda deployment Multi-AZ, Anda dapat memaksakan failover dari satu Availability Zone ke yang lain saat Anda memilih opsi **Reboot**. Saat Anda memaksa failover instans DB Anda, Neptune secara otomatis beralih ke replika siaga di Availability Zone lain. Kemudian memperbarui catatan DNS untuk instans DB untuk menunjuk ke instans DB siaga. Hasilnya, Anda harus membersihkan dan membangun kembali koneksi yang sudah ada ke instans DB Anda.
**Reboot dengan failover** bermanfaat saat Anda ingin mensimulasikan kegagalan instans DB untuk pengujian, atau memulihkan operasi ke Availability Zone asli setelah failover terjadi. Untuk informasi selengkapnya, lihat [Ketersediaan Tinggi (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) di *Panduan Pengguna Amazon RDS*. Ketika Anda me-reboot klaster DB, klaster akan melakukan failover ke replika siaga. Mereboot replika Neptune tidak memulai failover.
Waktu yang dibutuhkan untuk reboot adalah fungsi dari proses pemulihan crash. Untuk meningkatkan waktu reboot, kami menyarankan agar Anda mengurangi aktivitas basis data sebanyak mungkin selama proses reboot untuk mengurangi aktivitas rollback untuk transaksi in-transit.
Pada konsol, opsi **Mulai ulang** mungkin dinonaktifkan jika instans DB tidak dalam keadaan **Tersedia**. Ini bisa karena beberapa alasan, seperti pencadangan yang sedang berlangsung, modifikasi yang diminta konsumen, atau tindakan jendela-pemeliharaan.
**catatan**
Sebelumnya[Rilis: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md), semua replika baca dalam cluster DB secara otomatis di-boot ulang setiap kali instance utama (penulis) dimulai ulang.
Dimulai dengan[Rilis: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md), memulai ulang instance utama tidak menyebabkan replika apa pun dimulai ulang. Ini berarti bahwa jika Anda mengubah parameter cluster, Anda harus memulai ulang setiap instance secara terpisah untuk mengambil perubahan parameter (lihat[Grup parameter](parameter-groups.md)).
**Untuk me-reboot instans DB menggunakan konsol Neptune**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**.
1. Pilih instans DB yang ingin Anda reboot.
1. Pilih **Tindakan instans**, dan kemudian pilih **Reboot**.
1. Untuk memaksa failover dari satu Availability Zone ke lainnya, pilih **Reboot dengan failover?** di kotak dialog **Reboot instans DB**.
1. Pilih **Boot ulang**. Untuk membatalkan reboot, pilih **Batal**.
# Menghapus sebuah Instans DB di Amazon Neptune
Anda dapat menghapus instans Amazon Neptunus DB di negara bagian mana pun dan kapan saja, selama instans telah dimulai.
**Awas**
Jika Anda menghapus instance terakhir yang tersisa di cluster menggunakan **konsol web**, itu juga akan menghapus volume penyimpanan cluster yang mendasarinya.
## Mengambil Snapshot Final Instans DB Anda Sebelum Menghapusnya
Untuk menghapus instans DB, tentukan nama instans dan apakah Anda ingin memiliki snapshot DB akhir yang diambil dari instans. Jika instans DB yang Anda hapus memiliki status **Membuat**, Anda tidak dapat memiliki snapshot DB akhir yang diambil. Jika instans DB berada dalam status kegagalan dengan status **gagal**, **incompatible-restore**, atau **incompatible-network**, Anda hanya dapat menghapus instans ketika parameter `SkipFinalSnapshot` diatur ke `true`.
Jika Anda menghapus semua instans DB Neptunus di cluster DB menggunakan Konsol Manajemen AWS, seluruh cluster DB dihapus secara otomatis. Jika Anda menggunakan AWS CLI atau SDK, Anda harus menghapus cluster DB secara manual setelah Anda menghapus instance terakhir.
**penting**
Jika Anda menghapus seluruh klaster DB, semua cadangan otomatisnya dihapus pada waktu yang sama dan tidak dapat dipulihkan. Ini berarti kecuali jika Anda memilih untuk membuat snapshot DB akhir secara manual, Anda tidak dapat mengembalikan instans DB ke keadaan akhirnya di lain waktu. Snapshot manual sebiah instans tidak dihapus ketika klaster dihapus.
Jika instans DB yang ingin Anda hapus memiliki replika baca, Anda harus mempromosikan atau menghapus replika baca tersebut.
Pada contoh berikut, Anda menghapus instans DB dengan dan tanpa snapshot DB akhir.
## Menghapus instans DB dengan Tanpa Snapshot Akhir
Jika Anda ingin menghapus instans DB dengan cepat, Anda dapat melewati pembuatan snapshot DB akhir. Ketika Anda menghapus sebuah klaster, semua backup otomatis tersebut dihapus dan tidak dapat dipulihkan. Snapshot manual tidak dihapus.
**Untuk menghapus instans DB tanpa snapshot DB akhir menggunakan konsol Neptune**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**.
1. Di daftar **Instans**, pilih tombol radio di samping instans DB yang ingin Anda hapus.
1. Pilih **Tindakan Instans**, lalu pilih **Hapus**.
1. Pilih **Tidak** di kotak **Membuat snapshot akhir?**.
1. Pilih **Hapus**.
## Menghapus Instans DB dengan Snapshot Akhir
Jika Anda ingin memulihkan instans DB Anda yang dihapus nanti, buat snapshot DB akhir. Semua backup otomatis juga dihapus dan tidak dapat dipulihkan. Snapshot manual tidak dihapus.
**Untuk menghapus instans DB dengan snapshot DB akhir menggunakan konsol Neptune**
1. [Masuk ke Konsol AWS Manajemen, dan buka konsol Amazon Neptunus di rumah. https://console.aws.amazon.com/neptune/](https://console.aws.amazon.com/neptune/home)
1. Di panel navigasi, pilih **Basis data**.
1. Di daftar **Instans**, pilih tombol radio di samping instans DB yang ingin Anda hapus.
1. Pilih **Tindakan Instans**, lalu pilih **Hapus**.
1. Pilih **Ya** di kotak **Membuat snapshot akhir?**.
1. Di kotak **Nama snapshot akhir**, masukkan nama snapshot DB akhir Anda.
1. Pilih **Hapus**.
Anda dapat memeriksa kesehatan sebuah instance, menentukan jenis instans, mencari tahu versi rilis mesin yang saat ini telah Anda instal, dan mendapatkan informasi lain tentang sebuah instance menggunakan [API status instance](access-graph-status.md).