Untuk kemampuan serupa dengan Amazon Timestream LiveAnalytics, pertimbangkan Amazon Timestream untuk InfluxDB. Ini menawarkan konsumsi data yang disederhanakan dan waktu respons kueri milidetik satu digit untuk analitik waktu nyata. Pelajari lebih lanjut [di sini](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Deployment instans DB Multi-AZ
Amazon TimeStream untuk InfluxDB menyediakan ketersediaan tinggi dan dukungan failover untuk instans DB menggunakan penerapan multi-AZ dengan satu instans DB siaga. Jenis deployment ini disebut deployment instans DB Multi-AZ. Amazon Timestream untuk InfluxDB menggunakan teknologi failover Amazon.
Dalam penerapan instans DB multi-AZ, Amazon Timestream secara otomatis menyediakan dan memelihara replika siaga sinkron di Availability Zone yang berbeda. Instans DB primer direplikasi secara sinkron ke seluruh Zona Ketersediaan ke replika siaga untuk memberikan redundansi data. Menjalankan instans DB dengan ketersediaan tinggi dapat meningkatkan ketersediaan selama kegagalan instans DB dan gangguan Availability Zone. Untuk informasi lebih lanjut tentang, lihat[Wilayah AWS dan Availability Zone](timestream-for-influxdb.md#timestream-for-influx-dbi-regions).
**catatan**
Opsi ketersediaan tinggi bukanlah solusi penskalaan untuk skenario hanya baca. Anda tidak dapat menggunakan replika siaga untuk menyajikan lalu lintas baca.
Menggunakan konsol Amazon Timestream, Anda dapat membuat penerapan instans DB multi-AZ hanya dengan menentukan opsi **Buat instans siaga di bagian **konfigurasi Ketersediaan dan daya tahan** saat membuat instans** DB. Anda juga dapat menentukan penerapan instans DB multi-AZ dengan API Amazon Timestream AWS Command Line Interface atau Amazon. Gunakan perintah `create-db-instance` atau CLI, atau operasi `CreateDBInstance` API.
Instans DB yang menggunakan deployment instans DB Multi-AZ dapat meningkatkan latensi tulis dan commit dibandingkan dengan deployment AZ Tunggal. Hal ini karena replikasi data sinkron yang terjadi. Anda mungkin mengalami perubahan latensi jika penerapan Anda gagal ke replika siaga, meskipun direkayasa dengan konektivitas jaringan latensi AWS rendah di antaranya. Untuk beban kerja produksi, kami menyarankan Anda menggunakan IOPS Included storage 12K atau 16K IOPS untuk kinerja yang cepat dan konsisten. Untuk informasi selengkapnya tentang kelas instans DB, lihat [Kelas instans DB](timestream-for-influxdb.md#timestream-for-influx-dbi-classes).
# Mengkonfigurasi dan mengelola penyebaran Multi-AZ
Timestream untuk penyebaran InfluxDB multi-AZ hanya dapat memiliki satu siaga. Ketika deployment memiliki satu instans DB siaga, itu disebut deployment instans DB Multi-AZ. Deployment instans DB Multi-AZ memiliki satu instans DB siaga yang menyediakan dukungan failover, tetapi tidak melayani lalu lintas baca.
**penting**
Instans Anda harus memiliki setidaknya dua subnet yang terkait dengannya untuk menjalankan pembaruan Single-AZ ke Multi-AZ. Setelah instance dibuat, Anda tidak dapat mengubah mode penerapannya dari Single-AZ ke Multi-AZ.
Anda dapat menggunakan Konsol Manajemen AWS untuk menentukan apakah instans DB Anda adalah penerapan Single-AZ atau Multi-AZ.
**Menggunakan Konsol Manajemen AWS**
1. Masuk ke Konsol Manajemen AWS dan buka [Amazon Timestream untuk konsol InfluxDB](https://console.aws.amazon.com/timestream/).
1. **Di panel navigasi, pilih **database InfluxDB**, lalu pilih DB identifier.**
Deployment instans DB Multi-AZ memiliki karakteristik sebagai berikut:
+ Hanya ada satu baris untuk instans DB.
+ Nilai Peran adalah Instans atau Primer.
+ Nilai Multi-AZ adalah Ya.
# Proses failover untuk Amazon Timestream
Jika pemadaman instans DB yang direncanakan atau tidak direncanakan disebabkan oleh cacat infrastruktur, Amazon TimeStream untuk InfluxDB secara otomatis beralih ke replika siaga di Availability Zone lain jika Anda telah mengaktifkan Multi-AZ. Durasi penyelesaian failover bergantung pada aktivitas basis data dan kondisi lain pada saat instans DB primer tidak tersedia. Durasi failover biasanya antara 60–120 detik. Namun, transaksi besar atau proses pemulihan yang panjang dapat meningkatkan waktu failover. Ketika failover selesai, dibutuhkan waktu tambahan untuk konsol Timestream untuk mencerminkan Availability Zone yang baru.
**catatan**
Amazon Timestream menangani failover secara otomatis sehingga Anda dapat melanjutkan operasi database secepat mungkin tanpa intervensi administratif. Instans DB primer otomatis beralih ke replika siaga jika salah satu dari kondisi yang dijelaskan dalam tabel berikut terjadi.
****
| Alasan failover | Deskripsi |
| --- | --- |
| Sistem operasi yang mendasari instance database Timestream sedang ditambal dalam operasi offline. | Failover dipicu selama periode pemeliharaan untuk patch OS atau pembaruan keamanan. |
| Host utama instans Timestream Multi-AZ tidak sehat. | Deployment instans DB Multi-AZ mendeteksi instans DB primer mengalami gangguan dan failover. |
| Host utama instans Timestream Multi-AZ tidak dapat dijangkau karena hilangnya konektivitas jaringan. | Pemantauan Timestream mendeteksi kegagalan jangkauan jaringan ke instans DB utama dan memicu failover. |
| Instans Timestream dimodifikasi oleh pelanggan. | Modifikasi instans Timesteam untuk InfluxDB DB memicu failover. Untuk informasi selengkapnya, lihat [Memperbarui instans DB](timestream-for-influx-managing-modifying-db.md). |
| Instans utama Timestream Multi-AZ sibuk dan tidak responsif. | Instans DB primer tidak responsif. Kami menyarankan Anda melakukan hal berikut: \$1 Periksa acara untuk penggunaan CPU, memori, atau ruang swap yang berlebihan. \$1 Evaluasi beban kerja Anda untuk menentukan apakah Anda menggunakan kelas instans DB yang sesuai. Untuk informasi selengkapnya, lihat Kelas instans DB. |
| Volume penyimpanan yang mendasari host utama instans Timestream Multi-AZ mengalami kegagalan. | Deployment instans DB Multi-AZ mendeteksi masalah penyimpanan pada instans DB primer dan mengalami failover. |
# Mengatur TTL JVM untuk pencarian nama DNS
Mekanisme failover otomatis mengubah catatan Sistem Nama Domain (DNS) instans DB menjadi titik ke instans DB siaga. Oleh karena itu, Anda perlu membuat kembali koneksi yang ada ke instans DB Anda. Di lingkungan mesin virtual Java (JVM), karena cara kerja mekanisme caching DNS Java, Anda mungkin perlu mengonfigurasi ulang pengaturan JVM.
JVM menyimpan cache pencarian nama DNS. Ketika JVM menyelesaikan nama host ke alamat IP, itu cache alamat IP untuk jangka waktu tertentu, yang dikenal sebagai (TTL). *time-to-live*
Karena AWS sumber daya menggunakan entri nama DNS yang terkadang berubah, kami sarankan Anda mengonfigurasi JVM Anda dengan nilai TTL tidak lebih dari 60 detik. Hal ini dapat memastikan bahwa ketika alamat IP sumber daya berubah, aplikasi Anda dapat menerima dan menggunakan alamat IP baru sumber daya dengan mengueri ulang DNS.
Pada beberapa konfigurasi Java, TTL default JVM diatur untuk tidak pernah menyegarkan entri DNS hingga JVM dimulai ulang. Jadi, jika alamat IP untuk AWS sumber daya berubah saat aplikasi Anda masih berjalan, itu tidak dapat menggunakan sumber daya itu sampai Anda secara manual me-restart JVM dan informasi IP cache di-refresh. Dalam kasus ini, penting untuk mengatur TTL JVM untuk menyegarkan informasi IP yang tersimpan dalam cache secara berkala.
Anda bisa mendapatkan TTL default JVM dengan mengambil nilai properti `networkaddress.cache.ttl`:
```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```
**catatan**
TTL default dapat bervariasi berdasarkan versi JVM Anda dan apakah manajer keamanan telah diinstal. Banyak yang JVMs menyediakan TTL default kurang dari 60 detik. Jika Anda menggunakan JVM seperti itu dan tidak menggunakan manajer keamanan, Anda dapat mengabaikan topik selanjutnya.
Untuk memodifikasi TTL JVM, atur nilai properti networkaddress.cache.ttl. Gunakan salah satu metode berikut, tergantung pada kebutuhan Anda:
Untuk menetapkan nilai properti secara global untuk semua aplikasi yang menggunakan JVM, tetapkan `networkaddress.cache.ttl` dalam file `$JAVA_HOME/jre/lib/security/java.security`.
```
networkaddress.cache.ttl=60
```
Untuk menetapkan properti secara lokal hanya untuk aplikasi Anda, tetapkan `networkaddress.cache.ttl` dalam kode inisialisasi aplikasi Anda sebelum koneksi jaringan dibuat.
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```