Halaman ini menjelaskan cara memulihkan atau memulihkan Cassandra di beberapa region.
Dalam deployment multi-region, Apigee hybrid di-deploy di beberapa lokasi geografis di seluruh pusat data yang berbeda. Jika satu atau beberapa region gagal, tetapi region yang sehat tetap ada, Anda dapat menggunakan region yang sehat untuk memulihkan
region Cassandra yang gagal dengan data terbaru.
Jika terjadi kegagalan besar di semua region hybrid, Cassandra dapat dipulihkan.
Penting untuk diperhatikan bahwa, jika Anda memiliki beberapa organisasi Apigee dalam deployment,
proses pemulihan akan memulihkan data untuk semua organisasi. Dalam penyiapan multi-organisasi,
hanya memulihkan organisasi tertentu tidak didukung.
Topik ini menjelaskan kedua pendekatan untuk menyelamatkan region yang gagal:
Memulihkan region yang gagal - Menjelaskan langkah-langkah untuk memulihkan region yang gagal berdasarkan
region yang responsif.
Memulihkan region yang gagal - Menjelaskan langkah-langkah untuk memulihkan region yang gagal dari cadangan. Pendekatan ini hanya diperlukan jika semua region campuran terpengaruh.
Memulihkan wilayah yang gagal
Untuk memulihkan region yang gagal dari region yang sehat, lakukan langkah-langkah berikut:
Alihkan traffic API dari region yang terpengaruh ke region yang berfungsi dengan baik. Rencanakan
kapasitas yang sesuai untuk mendukung traffic yang dialihkan dari region yang gagal.
Nonaktifkan region yang terpengaruh. Untuk setiap region yang terpengaruh, ikuti langkah-langkah yang diuraikan
di Menonaktifkan region hybrid.
Tunggu hingga penghentian layanan selesai sebelum melanjutkan ke langkah berikutnya.
Pencadangan Cassandra dapat berada di Cloud Storage atau di server jarak jauh berdasarkan konfigurasi Anda.
Untuk memulihkan Cassandra dari cadangan, lakukan langkah-langkah berikut:
Hapus deployment hybrid apigee dari semua wilayah:
APIGEE_JMX_USER adalah nama pengguna untuk pengguna operasi JMX Cassandra. Digunakan
untuk mengautentikasi dan berkomunikasi dengan antarmuka JMX Cassandra. Lihat
cassandra:auth:jmx:username.
APIGEE_DDL_USER dan APIGEE_DDL_PASSWORD adalah nama pengguna dan sandi admin untuk pengguna Cassandra Data Definition Language (DDL). Nilai defaultnya adalah "ddl_user" dan "iloveapis123".
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-03 UTC."],[[["\u003cp\u003eThis document outlines procedures for recovering or restoring Cassandra in multi-region Apigee hybrid deployments, where recovering is for when some regions fail, and restoring is when all regions have failed.\u003c/p\u003e\n"],["\u003cp\u003eIf one or more regions fail, you can recover them by redirecting traffic to a healthy region, decommissioning the failed region, and then restoring the impacted region.\u003c/p\u003e\n"],["\u003cp\u003eIn case of total regional failure, you need to restore Cassandra from a backup, which will restore data for all organizations in a multi-organization setup, as restoring a specific organization is not supported.\u003c/p\u003e\n"],["\u003cp\u003eRestoration from a backup involves deleting the existing Apigee hybrid deployment, restoring the desired region from a backup, updating the KeySpaces metadata, and adjusting replication settings via the CQL interface.\u003c/p\u003e\n"],["\u003cp\u003eBefore starting either process you should know that this version of Apigee hybrid is end of life, and you should upgrade to a newer version.\u003c/p\u003e\n"]]],[],null,["# Restoring in multiple regions\n\n| You are currently viewing version 1.8 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nThis page describes how to *recover* or *restore* Cassandra in multiple regions.\n\nIn a multi-region deployment, Apigee hybrid is deployed in multiple geographic locations across\ndifferent datacenters. If one or more regions fail, but healthy regions remain, you can use a healthy region to *recover*\nfailed Cassandra regions with the latest data.\n\n\nIn the event of a catastrophic failure of all hybrid regions, Cassandra can be *restored* .\nIt is important to note that, if you have multiple Apigee organizations in your deployment,\nthe restore process restores data for **all** the organizations. In a multi-organization setup,\nrestoring only a specific organization is **not** supported.\n\nThis topic describes both approaches to salvaging failed region(s):\n\n- [Recover failed region(s)](#recover-failed-region) - Describes the steps to recover failed region(s) based on a healthy region.\n- [Restore failed region(s)](#restore-nongcs) - Describes the steps to restore failed region(s) from a backup. This approach is only required if *all* hybrid regions are impacted.\n\nRecover failed region(s)\n------------------------\n\nTo recover failed region(s) from a healthy region, perform the following steps:\n\n1. Redirect the API traffic from the impacted region(s) to the good working region. Plan the capacity accordingly to support the diverted traffic from failed region(s).\n2. Decommission the impacted region. For each impacted region, follow the steps outlined in [Decommission a hybrid region](/apigee/docs/hybrid/v1.8/decommission-region). Wait for decommissioning to complete before moving on to the next step.\n\n \u003cbr /\u003e\n\n3. Restore the impacted region. To restore, create a new region, as described in [Multi-region deployment on GKE, GKE on-prem, and AKS](/apigee/docs/hybrid/v1.8/multi-region).\n\nRestoring from a backup\n-----------------------\n\n| **Note** : If you want to preserve an existing setup for troubleshooting and root cause analysis (RCA), you should delete all the `org` and `env` components from the Kubernetes cluster *except* the Apigee controller, and retain the cluster. The cluster will contain the existing Apigee datastore (Cassandra) which you can use for troubleshooting. Create a new Kubernetes cluster and then restore Cassandra in the new cluster.\n\nThe Cassandra backup can either reside on Cloud Storage or on a remote server based on your configuration.\nTo restore Cassandra from a backup, perform the following steps:\n\n1. Delete apigee hybrid deployment from all the regions: \n\n ```\n apigeectl delete -f overrides.yaml\n ```\n2. Restore the desired region from a backup. For more information,\n see [Restoring a region from a backup](/apigee/docs/hybrid/v1.8/restore-cassandra-single-region#restore-gcs).\n\n3. Remove the deleted region(s) references and add the restored region(s) references in the `KeySpaces` metadata.\n4. Get the region name by using the `nodetool status` option. \n\n ```\n kubectl exec -n apigee -it apigee-cassandra-default-0 -- bash\n nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status |grep -i Datacenter\n ```\n\n where:\n - \u003cvar translate=\"no\"\u003eAPIGEE_JMX_USER\u003c/var\u003e is the username for the Cassandra JMX operations user. Used to authenticate and communicate with the Cassandra JMX interface. See [`cassandra:auth:jmx:username`](/apigee/docs/hybrid/v1.8/config-prop-ref#cassandra-auth-jmx-username).\n - \u003cvar translate=\"no\"\u003eAPIGEE_JMX_PASSWORD\u003c/var\u003e is the password for the Cassandra JMX operations user. See [`cassandra:auth:jmx:password`](/apigee/docs/hybrid/v1.8/config-prop-ref#cassandra-auth-jmx-password).\n5. Update the `KeySpaces` replication.\n 1. [Create a client container](/apigee/docs/hybrid/v1.8/ts-cassandra#create-a-client-container-for-debugging) and connect to the Cassandra cluster through the CQL interface.\n 2. Get the list of user keyspaces from CQL interface: \n\n ```\n cqlsh CASSANDRA_SEED_HOST -u APIGEE_DDL_USER -p APIGEE_DDL_PASSWORD\n --ssl -e \"select keyspace_name from system_schema.keyspaces;\"|grep -v system\n ```\n\n where:\n - \u003cvar translate=\"no\"\u003eCASSANDRA_SEED_HOST\u003c/var\u003e is the Cassandra multi-region seed host. For most multi-region installations, use the IP address of a host in your first region. See [Configure Apigee\n hybrid for multi-region](/apigee/docs/hybrid/v1.8/multi-region#configure-apigee-hybrid-for-multi-region) and [`cassandra:externalSeedHost`](/apigee/docs/hybrid/v1.8/config-prop-ref#cassandra-externalseedhost).\n - \u003cvar translate=\"no\"\u003eAPIGEE_DDL_USER\u003c/var\u003e and \u003cvar translate=\"no\"\u003eAPIGEE_DDL_PASSWORD\u003c/var\u003e are the admin username and password for the Cassandra Data Definition Language (DDL) user. The default values are \"`ddl_user`\" and \"`iloveapis123`\". You can check the DDL username and password by checking the value stored in the `apigee-datastore-default-creds`secret. You must have admin privileges to check this secret. The following command will return base-64 encoded values for the DDL username and password: \n |\n | ```\n | kubectl get secret apigee-datastore-default-creds -n apigee -o yaml\n | ```\n\n\n See [`cassandra.auth.ddl.password`](/apigee/docs/hybrid/v1.8/config-prop-ref#cassandra-auth.ddl.password)\n in the Configuration properties reference and\n [Command\n Line Options](https://cassandra.apache.org/doc/4.1/cassandra/tools/cqlsh.html#command-line-options) in the Apache Cassandra cqlsh documentation.\n 3. For each keyspace, run the following command from the CQL interface to update the replication settings: \n\n ```\n ALTER KEYSPACE KEYSPACE_NAME WITH replication = {'class': 'NetworkTopologyStrategy', 'REGION_NAME':3};\n ```\n\n where:\n - \u003cvar translate=\"no\"\u003eKEYSPACE_NAME\u003c/var\u003e is the name of the keyspace listed in the previous step's output.\n - \u003cvar translate=\"no\"\u003eREGION_NAME\u003c/var\u003e is the region name obtained in Step 4."]]
