Prasyarat UltraWarm persyaratan penyimpanan dan pertimbangan kinerja UltraWarm harga Mengaktifkan UltraWarm Migrasi indeks ke penyimpanan UltraWarm Mengotomatisasi migrasi Penyetelan migrasi Membatalkan migrasi Daftar indeks panas dan hangat Mengembalikan indeks hangat ke penyimpanan panas Memulihkan indeks hangat dari snapshot Cuplikan manual dari indeks hangat Migrasi indeks hangat ke cold storage Menonaktifkan UltraWarm

UltraWarm penyimpanan untuk Amazon OpenSearch Service

UltraWarm menyediakan cara hemat biaya untuk menyimpan sejumlah besar data hanya-baca di Amazon Service. OpenSearch Simpul data standar menggunakan penyimpanan “panas”, yang berbentuk penyimpanan instans atau volume Amazon EBS yang dilampirkan pada setiap simpul. Penyimpanan panas memberikan performa tercepat untuk pengindeksan dan pencarian data baru.

Alih-alih penyimpanan terpasang, UltraWarm node menggunakan Amazon S3 dan solusi caching canggih untuk meningkatkan kinerja. Untuk indeks yang tidak Anda tulis secara aktif, kueri lebih jarang, dan tidak memerlukan kinerja yang sama, UltraWarm menawarkan biaya per GiB data yang jauh lebih rendah. Karena indeks hangat hanya-baca kecuali Anda mengembalikannya ke penyimpanan panas, paling cocok untuk data UltraWarm yang tidak dapat diubah, seperti log.

Dalam OpenSearch, indeks hangat berperilaku seperti indeks lainnya. Anda dapat melakukan kueri menggunakan API yang sama atau menggunakannya untuk membuat visualisasi di OpenSearch Dasbor.

Topik

Prasyarat
UltraWarm persyaratan penyimpanan dan pertimbangan kinerja
UltraWarm harga
Mengaktifkan UltraWarm
Migrasi indeks ke penyimpanan UltraWarm
Mengotomatisasi migrasi
Penyetelan migrasi
Membatalkan migrasi
Daftar indeks panas dan hangat
Mengembalikan indeks hangat ke penyimpanan panas
Memulihkan indeks hangat dari snapshot
Cuplikan manual dari indeks hangat
Migrasi indeks hangat ke cold storage
Menonaktifkan UltraWarm

Prasyarat

UltraWarm memiliki beberapa prasyarat penting:

UltraWarm membutuhkan OpenSearch atau Elasticsearch 6.8 atau lebih tinggi.
Untuk menggunakan penyimpanan hangat, domain harus memiliki simpul utama terdedikasi.
Saat menggunakan Multi-AZ dengan domain Siaga, jumlah node hangat harus kelipatan dari jumlah Availability Zones yang digunakan.
Jika domain Anda menggunakan tipe instans T2 atau T3 untuk simpul data, Anda tidak dapat menggunakan penyimpanan hangat.
Jika indeks Anda menggunakan perkiraan k-nn ("index.knn": true), Anda tidak dapat memindahkannya ke penyimpanan hangat.
Jika domain menggunakan kontrol akses berbutir halus, pengguna harus dipetakan ke ultrawarm_manager peran di OpenSearch Dasbor untuk melakukan panggilan API. UltraWarm

catatan

ultrawarm_managerPeran mungkin tidak ditentukan pada beberapa domain OpenSearch Layanan yang sudah ada sebelumnya. Jika Anda tidak melihat peran di Dasbor, Anda harus membuatnya secara manual.

Konfigurasi izin

Jika Anda UltraWarm mengaktifkan domain OpenSearch Layanan yang sudah ada sebelumnya, ultrawarm_manager peran tersebut mungkin tidak ditentukan pada domain. Pengguna non-admin harus dipetakan ke peran ini untuk mengelola indeks hangat pada domain menggunakan kontrol akses berbutir halus. Untuk membuat secara manual peran ultrawarm_manager, lakukan langkah-langkah berikut:

Di OpenSearch Dasbor, buka Keamanan dan pilih Izin.

Pilih Buat grup tindakan dan konfigurasi grup-grup berikut:

Nama grup	Izin
`ultrawarm_cluster`	`cluster:admin/ultrawarm/migration/list` `cluster:monitor/nodes/stats`
`ultrawarm_index_read`	`indices:admin/ultrawarm/migration/get` `indices:admin/get`
`ultrawarm_index_write`	`indices:admin/ultrawarm/migration/warm` `indices:admin/ultrawarm/migration/hot` `indices:monitor/stats` `indices:admin/ultrawarm/migration/cancel`

Pilih Peran dan Buat peran.
Beri nama peran ultrawarm_manager.
Untuk Izin klaster, pilih ultrawarm_cluster dan cluster_monitor.
Untuk Indeks, ketik *.
Untuk Izin indeks, pilih ultrawarm_index_read, ultrawarm_index_write, dan indices_monitor.
Pilih Buat.
Setelah Anda membuat peran, petakan ke setiap pengguna atau peran backend yang akan mengelola UltraWarm indeks.

UltraWarm persyaratan penyimpanan dan pertimbangan kinerja

Sebagaimana tercakup dalamMenghitung persyaratan penyimpanan, data dalam penyimpanan panas menimbulkan overhead yang signifikan: replika, ruang cadangan Linux, dan OpenSearch ruang cadangan Layanan. Misalnya, pecahan primer 20 GiB dengan satu pecahan replika membutuhkan sekitar 58 GiB penyimpanan panas.

Karena menggunakan Amazon S3, UltraWarm tidak menimbulkan overhead ini. Saat menghitung persyaratan UltraWarm penyimpanan, Anda hanya mempertimbangkan ukuran pecahan utama. Daya tahan data di S3 menghilangkan kebutuhan untuk replika, dan S3 mengabstraksi setiap pertimbangan sistem operasi atau layanan. Serpihan 20 GiB yang sama membutuhkan 20 GiB penyimpanan hangat. Jika Anda menyediakan instans ultrawarm1.large.search, Anda dapat menggunakan semua 20 TiB dari penyimpanan maksimumnya untuk serpihan utama. Lihat UltraWarm kuota penyimpanan untuk ringkasan tipe instans dan jumlah penyimpanan maksimum yang dapat ditangani masing-masing.

Dengan UltraWarm, kami masih merekomendasikan ukuran pecahan maksimum 50 GiB. Jumlah inti CPU dan jumlah RAM yang dialokasikan untuk setiap jenis UltraWarm instans memberi Anda gambaran tentang jumlah pecahan yang dapat mereka cari secara bersamaan. Perhatikan bahwa meskipun hanya pecahan primer yang dihitung terhadap UltraWarm penyimpanan di S3, OpenSearch Dasbor dan _cat/indices masih melaporkan ukuran UltraWarm indeks sebagai total semua pecahan primer dan replika.

Sebagai contoh, setiap instans ultrawarm1.medium.search memiliki dua core CPU dan dapat menangani hingga 1,5 TiB penyimpanan di S3. Dua dari instans ini memiliki gabungan 3 TiB penyimpanan, yang bekerja untuk sekitar 62 serpihan jika setiap serpihan berukuran 50 GiB. Jika permintaan ke klaster hanya mencari empat serpihan ini, performanya mungkin sangat baik. Jika permintaannya luas dan mencari semua 62 darinya, empat core CPU mungkin kesulitan untuk melakukan operasi. Pantau WarmCPUUtilization dan WarmJVMMemoryPressure UltraWarm metrik untuk memahami cara instans menangani beban kerja Anda.

Jika pencarian Anda luas atau sering, pertimbangkan untuk meninggalkan indeks dalam penyimpanan panas. Sama seperti OpenSearch beban kerja lainnya, langkah terpenting untuk menentukan apakah UltraWarm memenuhi kebutuhan Anda adalah melakukan pengujian klien yang representatif menggunakan kumpulan data yang realistis.

UltraWarm harga

Dengan penyimpanan panas, Anda membayar untuk apa yang Anda sediakan. Beberapa instans memerlukan volume Amazon EBS terlampir, sementara yang lain menyertakan penyimpanan instans. Apakah penyimpanan itu kosong atau penuh, Anda membayar harga yang sama.

Dengan UltraWarm penyimpanan, Anda membayar untuk apa yang Anda gunakan. Instans ultrawarm1.large.search dapat menangani hingga 20 TiB penyimpanan di S3, tetapi jika Anda hanya menyimpan 1 TiB data, Anda hanya akan ditagih untuk 1 TiB data. Seperti semua jenis node lainnya, Anda juga membayar tarif per jam untuk setiap UltraWarm node. Untuk informasi selengkapnya, lihat Harga untuk OpenSearch Layanan Amazon.

Mengaktifkan UltraWarm

Konsol adalah cara paling mudah untuk membuat domain yang menggunakan penyimpanan hangat. Saat membuat domain, pilih Aktifkan node UltraWarm data dan jumlah node hangat yang Anda inginkan. Proses dasar yang sama bekerja pada domain yang ada, asalkan proses tersebut memenuhi prasyarat. Bahkan setelah status domain berubah dari Processing ke Active, UltraWarm mungkin tidak tersedia untuk digunakan selama beberapa jam.

Saat menggunakan Multi-AZ dengan domain Siaga, jumlah node hangat harus kelipatan dari jumlah Availability Zones yang digunakan. Untuk informasi selengkapnya, lihat Multi-AZ dengan Siaga.

Anda juga dapat menggunakan API konfigurasi AWS CLIatau untuk mengaktifkan UltraWarm, khususnya WarmEnabledWarmCount, dan WarmType opsi diClusterConfig.

catatan

Domain mendukung jumlah maksimum simpul hangat. Untuk detailnya, lihat Kuota OpenSearch Layanan Amazon.

Perintah CLI sampel

AWS CLI Perintah berikut membuat domain dengan tiga node data, tiga node master khusus, enam node hangat, dan kontrol akses berbutir halus diaktifkan:


aws opensearch create-domain \
  --domain-name my-domain \
  --engine-version Opensearch_1.0 \
  --cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.search \
  --ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \
  --node-to-node-encryption-options Enabled=true \
  --encryption-at-rest-options Enabled=true \
  --domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \
  --advanced-security-options Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions='{MasterUserName=master-user,MasterUserPassword=master-password}' \
  --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":["123456789012"]},"Action":["es:*"],"Resource":"arn:aws:es:us-west-1:123456789012:domain/my-domain/*"}]}' \
  --region us-east-1

Untuk informasi rinci, lihat AWS CLI Referensi Perintah.

Sampel permintaan API konfigurasi

Permintaan berikut ke API konfigurasi membuat domain dengan tiga simpul data, tiga simpul utama terdedikasi, enam simpul hangat, dan kontrol akses detail diaktifkan dan kebijakan akses terbatas:


POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain
{
  "ClusterConfig": {
    "InstanceCount": 3,
    "InstanceType": "r6g.large.search",
    "DedicatedMasterEnabled": true,
    "DedicatedMasterType": "r6g.large.search",
    "DedicatedMasterCount": 3,
    "ZoneAwarenessEnabled": true,
    "ZoneAwarenessConfig": {
      "AvailabilityZoneCount": 3
    },
    "WarmEnabled": true,
    "WarmCount": 6,
    "WarmType": "ultrawarm1.medium.search"
  },
  "EBSOptions": {
    "EBSEnabled": true,
    "VolumeType": "gp2",
    "VolumeSize": 11
  },
  "EncryptionAtRestOptions": {
    "Enabled": true
  },
  "NodeToNodeEncryptionOptions": {
    "Enabled": true
  },
  "DomainEndpointOptions": {
    "EnforceHTTPS": true,
    "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
  },
   "AdvancedSecurityOptions": {
    "Enabled": true,
    "InternalUserDatabaseEnabled": true,
    "MasterUserOptions": {
      "MasterUserName": "master-user",
      "MasterUserPassword": "master-password"
    }
  },
  "EngineVersion": "Opensearch_1.0",
  "DomainName": "my-domain",
  "AccessPolicies": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":[\"123456789012\"]},\"Action\":[\"es:*\"],\"Resource\":\"arn:aws:es:us-east-1:123456789012:domain/my-domain/*\"}]}"
}

Untuk informasi selengkapnya, lihat Referensi API OpenSearch Layanan Amazon.

Migrasi indeks ke penyimpanan UltraWarm

Jika Anda selesai menulis ke indeks dan tidak lagi membutuhkan kinerja pencarian tercepat, migrasikan dari panas ke UltraWarm:


POST _ultrawarm/migration/my-index/_warm

Kemudian periksa status migrasi:


GET _ultrawarm/migration/my-index/_status

{
  "migration_status": {
    "index": "my-index",
    "state": "RUNNING_SHARD_RELOCATION",
    "migration_type": "HOT_TO_WARM",
    "shard_level_status": {
      "running": 0,
      "total": 5,
      "pending": 3,
      "failed": 0,
      "succeeded": 2
    }
  }
}

Kesehatan indeks harus hijau untuk melakukan migrasi. Jika Anda memigrasikan beberapa indeks secara berurutan, Anda bisa mendapatkan ringkasan semua migrasi dalam plaintext, mirip dengan API: _cat


GET _ultrawarm/migration/_status?v

index    migration_type state
my-index HOT_TO_WARM    RUNNING_SHARD_RELOCATION

OpenSearch Layanan memigrasikan satu indeks pada satu waktu ke UltraWarm. Anda dapat memiliki hingga 200 migrasi dalam antrian. Setiap permintaan yang melebihi batas akan ditolak. Untuk memeriksa jumlah migrasi saat ini dalam antrean, pantau metrik HotToWarmMigrationQueueSize. Indeks tetap tersedia selama proses migrasi — tidak ada waktu henti.

Proses migrasi memiliki status sebagai berikut:


PENDING_INCREMENTAL_SNAPSHOT
RUNNING_INCREMENTAL_SNAPSHOT
FAILED_INCREMENTAL_SNAPSHOT
PENDING_FORCE_MERGE
RUNNING_FORCE_MERGE
FAILED_FORCE_MERGE
PENDING_FULL_SNAPSHOT
RUNNING_FULL_SNAPSHOT
FAILED_FULL_SNAPSHOT
PENDING_SHARD_RELOCATION
RUNNING_SHARD_RELOCATION
FINISHED_SHARD_RELOCATION

Seperti yang ditunjukkan oleh status ini, migrasi mungkin gagal selama snapshot, relokasi serpihan, atau penggabungan paksa. Kegagalan selama snapshot atau relokasi serpihan biasanya karena kegagalan simpul atau masalah konektivitas S3. Kurangnya ruang disk biasanya menjadi penyebab kegagalan penggabungan paksa.

Setelah migrasi selesai, permintaan _status yang sama mengembalikan kesalahan. Jika Anda memeriksa indeks pada saat itu, Anda dapat melihat beberapa pengaturan yang unik untuk indeks hangat:


GET my-index/_settings

{
  "my-index": {
    "settings": {
      "index": {
        "refresh_interval": "-1",
        "auto_expand_replicas": "false",
        "provided_name": "my-index",
        "creation_date": "1599241458998",
        "unassigned": {
          "node_left": {
            "delayed_timeout": "5m"
          }
        },
        "number_of_replicas": "1",
        "uuid": "GswyCdR0RSq0SJYmzsIpiw",
        "version": {
          "created": "7070099"
        },
        "routing": {
          "allocation": {
            "require": {
              "box_type": "warm"
            }
          }
        },
        "number_of_shards": "5",
        "merge": {
          "policy": {
            "max_merge_at_once_explicit": "50"
          }
        }
      }
    }
  }
}

number_of_replicas, dalam kasus ini, adalah jumlah replika pasif, yang tidak mengonsumsi ruang disk.
routing.allocation.require.box_type menetapkan bahwa indeks harus menggunakan simpul hangat daripada simpul data standar.
merge.policy.max_merge_at_once_explicit menentukan jumlah segmen untuk secara bersamaan digabungkan selama migrasi.

Indeks dalam penyimpanan hangat hanya dapat dibaca kecuali Anda mengembalikannya ke penyimpanan panas, yang UltraWarm paling cocok untuk data yang tidak dapat diubah, seperti log. Anda dapat menanyakan indeks dan menghapusnya, tetapi Anda tidak dapat menambahkan, memperbarui, atau menghapus dokumen individual. Jika Anda mencobanya, Anda mungkin mengalami kesalahan berikut:


{
  "error" : {
    "root_cause" : [
      {
        "type" : "cluster_block_exception",
        "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
      }
    ],
    "type" : "cluster_block_exception",
    "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
  },
  "status" : 429
}

Mengotomatisasi migrasi

Sebaiknya gunakan Manajemen Negara Indeks di OpenSearch Layanan Amazon untuk mengotomatisasi proses migrasi setelah indeks mencapai usia tertentu atau memenuhi kondisi lain. Lihat kebijakan sampel yang menunjukkan alur kerja ini.

Penyetelan migrasi

Migrasi indeks ke UltraWarm penyimpanan memerlukan penggabungan paksa. Setiap OpenSearch indeks terdiri dari sejumlah pecahan, dan setiap pecahan terdiri dari beberapa segmen Lucene. Operasi penggabungan paksa membersihkan dokumen yang ditandai untuk penghapusan dan menghemat ruang disk. Secara default, UltraWarm menggabungkan indeks menjadi satu segmen.

Anda dapat mengubah nilai ini hingga 1.000 segmen menggunakan pengaturan index.ultrawarm.migration.force_merge.max_num_segments. Nilai yang lebih tinggi mempercepat proses migrasi, tetapi meningkatkan latensi kueri untuk indeks hangat setelah migrasi selesai. Untuk mengubah pengaturan, buat permintaan berikut:


PUT my-index/_settings
{
  "index": {
    "ultrawarm": {
      "migration": {
        "force_merge": {
          "max_num_segments": 1
        }
      }
    }
  }
}

Untuk memeriksa berapa lama tahap proses migrasi ini berlangsung, pantau HotToWarmMigrationForceMergeLatency metrik.

Membatalkan migrasi

UltraWarm menangani migrasi secara berurutan, dalam antrian. Jika migrasi dalam antrean, namun belum dimulai, Anda dapat menghapusnya dari antrean menggunakan permintaan berikut:


POST _ultrawarm/migration/_cancel/my-index

Jika domain Anda menggunakan kontrol akses detail, Anda harus memiliki izin indices:admin/ultrawarm/migration/cancel untuk membuat permintaan ini.

Daftar indeks panas dan hangat

UltraWarm menambahkan dua opsi tambahan, mirip dengan_all, untuk membantu mengelola indeks panas dan hangat. Untuk daftar semua indeks hangat atau panas, buat permintaan berikut:


GET _warm
GET _hot

Anda dapat menggunakan opsi ini dalam permintaan lain yang menentukan indeks, seperti:


_cat/indices/_warm
_cluster/state/_all/_hot

Mengembalikan indeks hangat ke penyimpanan panas

Jika Anda perlu menulis ke indeks lagi, migrasikan kembali ke penyimpanan panas:


POST _ultrawarm/migration/my-index/_hot

Anda dapat memiliki hingga 10 migrasi antrian dari penyimpanan hangat ke penyimpanan panas sekaligus. OpenSearch Layanan memproses permintaan migrasi satu per satu, dalam urutan bahwa mereka mengantri. Untuk memeriksa jumlah saat ini, pantau metrik WarmToHotMigrationQueueSize.

Setelah migrasi selesai, periksa pengaturan indeks untuk memastikan itu memenuhi kebutuhan Anda. Indeks kembali ke penyimpanan panas dengan satu replika.

Memulihkan indeks hangat dari snapshot

Selain repositori standar untuk snapshot otomatis, UltraWarm tambahkan repositori kedua untuk indeks hangat,. cs-ultrawarm Setiap snapshot dalam repositori ini hanya berisi satu indeks. Jika Anda menghapus indeks hangat, snapshotnya tetap berada di repositori cs-ultrawarm selama 14 hari, sama seperti snapshot otomatis lainnya.

Saat Anda memulihkan snapshot dari cs-ultrawarm, itu memulihkan ke penyimpanan hangat, bukan penyimpanan panas. Snapshot di repositori cs-automated dan cs-automated-enc memulihkan ke penyimpanan panas.

Untuk mengembalikan UltraWarm snapshot ke penyimpanan hangat

Identifikasi snapshot terbaru yang berisi indeks yang ingin Anda pulihkan:
```
GET _snapshot/cs-ultrawarm/_all?verbose=false

{
  "snapshots": [{
    "snapshot": "snapshot-name",
    "version": "1.0",
    "indices": [
      "my-index"
    ]
  }]
}
```
catatan
Secara default, GET _snapshot/<repo> operasi menampilkan informasi data verbose seperti waktu mulai, waktu akhir, dan durasi untuk setiap snapshot dalam repositori. GET _snapshot/<repo>Operasi mengambil informasi dari file setiap snapshot yang terdapat dalam repositori. Jika Anda tidak memerlukan waktu mulai, waktu akhir, dan durasi dan hanya memerlukan informasi nama dan indeks snapshot, sebaiknya gunakan verbose=false parameter saat mencantumkan snapshot untuk meminimalkan waktu pemrosesan dan mencegah waktu habis.
Jika indeks sudah ada, hapuslah:
```
DELETE my-index
```
Jika Anda tidak ingin menghapus indeks, kembalikan indeks ke penyimpanan panas dan indeks ulang itu.
Memulihkan snapshot:
```
POST _snapshot/cs-ultrawarm/snapshot-name/_restore
```
UltraWarm mengabaikan pengaturan indeks apa pun yang Anda tentukan dalam permintaan pemulihan ini, tetapi Anda dapat menentukan opsi seperti rename_pattern danrename_replacement. Untuk ringkasan opsi pemulihan OpenSearch snapshot, lihat OpenSearch dokumentasi.

Cuplikan manual dari indeks hangat

Anda dapat mengambil snapshot manual dari indeks hangat, tetapi kami tidak merekomendasikannya. Repositori cs-ultrawarm otomatis sudah berisi snapshot untuk setiap indeks hangat, yang diambil selama migrasi, tanpa biaya tambahan.

Secara default, OpenSearch Layanan tidak menyertakan indeks hangat dalam snapshot manual. Misalnya, panggilan berikut hanya menyertakan indeks panas:


PUT _snapshot/my-repository/my-snapshot

Jika Anda memilih untuk mengambil snapshot manual dari indeks hangat, beberapa pertimbangan penting berlaku.

Anda tidak dapat mencampur indeks panas dan hangat. Sebagai contoh, permintaan berikut gagal:
```
PUT _snapshot/my-repository/my-snapshot
{
  "indices": "warm-index-1,hot-index-1",
  "include_global_state": false
}
```
Jika mereka menyertakan campuran indeks panas dan hangat, pernyataan wildcard (*) juga gagal.

Anda hanya dapat menyertakan satu indeks hangat per snapshot. Sebagai contoh, permintaan berikut gagal:


PUT _snapshot/my-repository/my-snapshot
{
  "indices": "warm-index-1,warm-index-2,other-warm-indices-*",
  "include_global_state": false
}

Permintaan ini berhasil:


PUT _snapshot/my-repository/my-snapshot
{
  "indices": "warm-index-1",
  "include_global_state": false
}

Snapshot manual selalu mengembalikan ke penyimpanan panas, bahkan jika awalnya termasuk indeks hangat.

Migrasi indeks hangat ke cold storage

Jika Anda memiliki data UltraWarm yang jarang Anda kueri, pertimbangkan untuk memigrasikannya ke penyimpanan dingin. Penyimpanan dingin dimaksudkan untuk data yang hanya Anda akses sesekali atau tidak lagi digunakan secara aktif. Anda tidak dapat membaca dari atau menulis ke indeks dingin, tetapi Anda dapat memigrasikannya kembali ke penyimpanan hangat tanpa biaya kapan pun Anda perlu menanyakannya. Untuk petunjuk, lihat Migrasi indeks ke cold storage.

Menonaktifkan UltraWarm

Konsol adalah cara paling sederhana untuk menonaktifkan UltraWarm. Pilih domain, Tindakan, dan Edit konfigurasi cluster. Hapus pilihan Aktifkan node UltraWarm data dan pilih Simpan perubahan. Anda juga dapat menggunakan opsi WarmEnabled di AWS CLI dan API konfigurasi.

Sebelum menonaktifkan UltraWarm, Anda harus menghapus semua indeks hangat atau memigrasikannya kembali ke penyimpanan panas. Setelah penyimpanan hangat kosong, tunggu lima menit sebelum mencoba menonaktifkan UltraWarm.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Mengelola indeks

Penyimpanan dingin