Cara melakukan backup dan pemulihan data secara manual - Elasticsearch

Gunakan fitur Snapshot Elasticsearch untuk mencadangkan data indeks dari kluster Anda ke Alibaba Cloud Object Storage Service (OSS) dan memulihkannya saat diperlukan. Snapshot manual sangat ideal untuk migrasi data, pemulihan pada titik waktu, menyiapkan lingkungan pengembangan dan pengujian, serta membuat cadangan sebelum operasi berisiko tinggi. Dibandingkan dengan snapshot otomatis, snapshot manual menawarkan fleksibilitas lebih besar dalam cakupan dan waktu, tetapi Anda harus mengelola siklus hidupnya sendiri.

Backup dan pemulihan data bergantung pada plugin elasticsearch-repository-oss. Plugin ini diinstal secara default pada instans Alibaba Cloud Elasticsearch dan tidak dapat diuninstall. Untuk informasi selengkapnya, lihat elasticsearch-repository-oss.

Snapshot hanya menyimpan data indeks. Snapshot tidak menyimpan data pemantauan (indeks dengan awalan .monitoring atau .security_audit), metadata, translog, konfigurasi instans, paket perangkat lunak, plugin, atau log. Semua perintah dalam topik ini dapat dijalankan di Dev Tools Konsol Kibana. Untuk informasi selengkapnya, lihat Masuk ke Konsol Kibana.

Buat repositori snapshot

Repositori snapshot adalah wadah logis untuk menyimpan snapshot. Sebelum membuat repositori, Anda harus memiliki bucket OSS di wilayah yang sama dengan instans Elasticsearch Anda. Kami merekomendasikan penggunaan kelas penyimpanan Standard. Untuk petunjuknya, lihat Buat bucket. Pengguna RAM harus memiliki kebijakan AliyunOSSFullAccess. Untuk petunjuknya, lihat Berikan izin kepada Pengguna RAM.

Contoh berikut membuat repositori bernama my_backup.

Kluster Alibaba Cloud

PUT _snapshot/my_backup/
{
    "type": "oss",
    "settings": {
        "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
        "access_key_id": "xxxx",
        "secret_access_key": "xxxxxx",
        "bucket": "xxxxxx",
        "compress": true,
        "chunk_size": "500mb",
        "base_path": "snapshot/"
    }
}

Kluster 8.x yang dikelola sendiri

Untuk kluster yang dikelola sendiri, Anda harus menginstal plugin elasticsearch-repository-oss terlebih dahulu. Untuk informasi selengkapnya, lihat plugin elasticsearch-repository-oss. Saat mengonfigurasi kluster yang dikelola sendiri, Anda harus memberi awalan nama parameter dengan oss.client..

PUT /_snapshot/my_backup
{
    "type": "oss",
    "settings": {
        "oss.client.endpoint": "oss-cn-shanghai.aliyuncs.com",
        "oss.client.access_key_id": "xxx",
        "oss.client.secret_access_key": "xxx",
        "oss.client.bucket": "xxxxxx",
        "oss.client.base_path":"snapshot/",
        "oss.client.compress": true
    }
}

Parameter

Parameter	Deskripsi
endpoint	Titik akhir internal bucket OSS. Untuk informasi selengkapnya, lihat Wilayah dan titik akhir.
access_key_id	ID AccessKey Pengguna RAM. Untuk petunjuknya, lihat Dapatkan Pasangan Kunci Akses.
secret_access_key	Rahasia AccessKey Pengguna RAM. Untuk petunjuknya, lihat Dapatkan Pasangan Kunci Akses.
bucket	Nama bucket OSS yang sudah ada.
compress	Menentukan apakah file metadata snapshot, seperti pemetaan dan pengaturan indeks, dikompresi. File data tidak terpengaruh. Nilai default-nya adalah `false`.
chunk_size	Batas ukuran untuk setiap chunk data. Data yang lebih besar dari ukuran ini akan dibagi menjadi beberapa chunk sebelum diunggah ke OSS.
base_path	Jalur dasar repositori di dalam bucket. Nilai default-nya adalah root bucket. Anda dapat menentukan subdirektori untuk mengisolasi snapshot dari kluster atau lingkungan yang berbeda, seperti `snapshot/prod/` atau `snapshot/dev/`.

Verifikasi konektivitas repositori

POST _snapshot/my_backup/_verify

Permintaan yang berhasil akan mengembalikan daftar semua node yang berhasil terhubung ke repositori. Jika terjadi error, periksa titik akhir, nama bucket, dan izin Pengguna RAM Anda.

Dapatkan informasi repositori

# Dapatkan informasi tentang semua repositori
GET _snapshot
# Dapatkan informasi tentang repositori tertentu
GET _snapshot/my_backup

Buat snapshot

Snapshot semua indeks

PUT _snapshot/my_backup/snapshot_1

Perintah ini membuat snapshot bernama snapshot_1 untuk semua indeks yang terbuka. Perintah langsung mengembalikan respons, dan proses snapshot berjalan di latar belakang. Untuk memblokir panggilan hingga backup selesai, tambahkan parameter wait_for_completion=true:

PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true

Sebuah repositori dapat berisi beberapa snapshot. Snapshot pertama merupakan cadangan penuh. Snapshot berikutnya merupakan cadangan inkremental yang hanya menyimpan data yang berubah sejak snapshot terakhir, sehingga mengurangi waktu backup.

Snapshot indeks tertentu

PUT _snapshot/my_backup/snapshot_2
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false
}

Parameter	Deskripsi
indices	Menentukan indeks yang akan dicadangkan. Pisahkan beberapa indeks dengan koma. Wildcard didukung, seperti `logs-*`.
ignore_unavailable	Jika `true`, Elasticsearch mengabaikan indeks yang ditentukan tetapi tidak ada, alih-alih gagal menjalankan permintaan.
include_global_state	Jika `false`, snapshot tidak menyertakan status global kluster. Pengaturan ini direkomendasikan jika Anda hanya perlu mencadangkan data.

Informasi snapshot

# Lihat semua snapshot
GET _snapshot/my_backup/_all

# Lihat snapshot tertentu
GET _snapshot/my_backup/snapshot_1

# Lihat status detail snapshot, termasuk statistik untuk setiap indeks dan shard
GET _snapshot/my_backup/snapshot_1/_status

Hapus snapshot

DELETE _snapshot/my_backup/snapshot_1

Jika snapshot sedang berlangsung, perintah ini akan menghentikan proses dan menghapus data parsial yang telah dibuat.

Penting

Jangan menghapus file snapshot secara langsung dari Konsol OSS atau menggunakan alat lain. Tindakan ini akan memutus rantai cadangan inkremental dan dapat merusak semua snapshot berikutnya sehingga tidak dapat dipulihkan.

Pulihkan dari snapshot

Sebelum memulihkan data, perhatikan hal berikut:

Kami merekomendasikan untuk tidak memulihkan indeks sistem, yang diawali dengan tanda titik (.), karena dapat menyebabkan akses Kibana gagal.
Jika indeks dengan nama yang sama sudah ada di kluster target, Anda harus menutup atau menghapus indeks tersebut terlebih dahulu. Jika tidak, proses pemulihan akan gagal.
Untuk melakukan pemulihan cross-region, Anda harus terlebih dahulu memigrasikan data snapshot di OSS ke wilayah target, lalu memulihkannya ke kluster target. Untuk informasi tentang migrasi data antar bucket OSS, lihat Implementasi migrasi.

Buat repositori di kluster target

Sebelum dapat memulihkan data, Anda harus membuat repositori di kluster target yang mengarah ke lokasi OSS tempat backup disimpan. Untuk konfigurasi parameter, lihat Buat repositori snapshot.

PUT _snapshot/my_backup_restore/
{
    "type": "oss",
    "settings": {
        "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
        "access_key_id": "xxxx",
        "secret_access_key": "xxxxxx",
        "bucket": "xxxxxx",
        "compress": true,
        "chunk_size": "500mb",
        "base_path": "snapshot/"
    }
}

Pulihkan indeks tertentu

Pulihkan indeks tertentu dan ubah namanya untuk menghindari konflik dengan indeks yang sudah ada:

POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
 "indices": "index_1",
 "rename_pattern": "index_(.+)",
 "rename_replacement": "restored_index_$1"
}

Parameter	Deskripsi
indices	Menentukan indeks yang akan dipulihkan, mengabaikan semua indeks lain dalam snapshot.
rename_pattern	Pola ekspresi reguler yang cocok dengan nama indeks yang akan dipulihkan.
rename_replacement	Pola pengganti untuk nama indeks baru. Mendukung referensi grup tangkapan ekspresi reguler.

Pulihkan indeks non-sistem

POST _snapshot/my_backup_restore/snapshot_1/_restore
{"indices": "*,-.monitoring*,-.security*,-.kibana*,-.internal.alerts*,-.alerts*","ignore_unavailable": true}

Pola pengecualian di atas mencakup indeks sistem umum. Versi kluster yang berbeda mungkin memiliki indeks sistem lain, seperti .ds-ilm-history-* dan .slo-*. Sesuaikan daftar pengecualian berdasarkan indeks sistem di kluster Anda. Untuk kluster versi 8.x, Anda biasanya juga perlu mengecualikan indeks pendukung data stream, misalnya dengan menambahkan -.ds* ke daftar.

Pulihkan semua indeks

POST _snapshot/my_backup_restore/snapshot_1/_restore

API _restore langsung mengembalikan respons, dan proses pemulihan berjalan di latar belakang. Untuk memblokir panggilan hingga pemulihan selesai, tambahkan parameter wait_for_completion=true:

POST _snapshot/my_backup_restore/snapshot_1/_restore?wait_for_completion=true

Pulihkan ke Indexing Service

Saat memulihkan snapshot ke instans Indexing Service, gunakan parameter ignore_index_settings untuk mengabaikan pengaturan indeks yang tidak kompatibel:

POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
  "indices": "index_1",
  "ignore_index_settings": [
    "index.apack.cube.following_index"
  ]
}

Status pemulihan snapshot

Monitor status dan progres pemulihan menggunakan API _recovery.

# Periksa status pemulihan indeks tertentu
GET restored_index_1/_recovery

# Periksa status pemulihan untuk semua indeks (mungkin termasuk shard yang tidak terkait)
GET /_recovery/

Bidang utama dalam output:

Bidang	Deskripsi
type	Jenis pemulihan. `snapshot` menunjukkan pemulihan dari snapshot.
source	Repositori sumber dan snapshot.
percent	Progres pemulihan, dalam persentase.

Batalkan pemulihan

Untuk membatalkan pemulihan, hapus indeks yang sedang dipulihkan:

DELETE /restored_index_3