ElasticSearch 1.x升级至6.x最佳方案及数据安全实操步骤咨询

Hey there! Upgrading from Elasticsearch 1.x to 6.x is a big jump—especially with millions of records on the line—so let's walk through the safest, step-by-step plan with strict data safeguards built in. First off, you can't skip intermediate versions directly; ES doesn't support cross-major-version jumps like that, so we'll go 1.x → 2.x → 5.x → 6.x, with data checks and backups at every stage.

Pre-Upgrade: Lock in Data Safety First #

• Full Cluster Snapshot Backup
  Use the official snapshot API to create a complete backup of your cluster. Here's how:
  1. Register a snapshot repository (use a separate storage system like network-attached storage or object storage to avoid cluster failures affecting backups):

     PUT _snapshot/prod_backup
     {
       "type": "fs",
       "settings": {
         "location": "/path/to/secure/backup/storage",
         "compress": true
       }
     }
     

  2. Trigger a full snapshot:

     PUT _snapshot/prod_backup/upgrade_pre_1x_to_2x?wait_for_completion=true
     

  3. Verify the snapshot is valid by restoring a small portion of it to a test cluster—never skip this step.
• Mirror Production in a Test Environment
  Spin up a test cluster that matches your production setup exactly: same number of nodes, configuration, and a full copy of your data. Run the entire upgrade flow here first to catch compatibility issues, mapping conflicts, or plugin problems before touching production.
• Audit Plugin Compatibility
  Most 1.x plugins won't work with newer ES versions. List all plugins you're using (run plugin list on 1.x nodes) and find official replacements or compatible versions for 2.x, 5.x, and 6.x. Remove any unused plugins to reduce risk.

Stage 1: Upgrade from 1.x to 2.x (Latest Patch: 2.4.6) #

ES supports rolling upgrades from 1.x to 2.x, so you can keep the cluster online during this step:

1. Prepare each node:
   • Stop one data/master node.
   • Uninstall the old 1.x ES package, install 2.4.6.
   • Update the configuration file: replace deprecated settings (e.g., discovery.zen.ping.multicast.enabled is removed—use discovery.zen.ping.unicast.hosts instead) and set discovery.zen.minimum_master_nodes to (number_of_master_nodes / 2) + 1 to prevent split-brain.
2. Start the node and validate:
   • Boot the upgraded node, wait for it to join the cluster.
   • Run GET _cat/health?v to confirm the cluster is green.
   • Run GET _cat/nodes?v to verify all nodes (so far) are on 2.4.6.
3. Repeat for all nodes: Go through the same process for every node in the cluster.
4. Post-Upgrade Checks:
   • Count documents across all indices (GET _cat/count?v) and compare to pre-upgrade numbers.
   • Run sample queries and aggregations to ensure data is intact and functional.
   • Create a new snapshot of the 2.x cluster before moving on.

Stage 2: Upgrade from 2.x to 5.x (Latest Patch: 5.6.23) #

2.x to 5.x is another major jump—here's how to do it safely:

1. Pre-Upgrade Prep:
   • Ensure all nodes are already on 2.4.6 (the last 2.x release).
   • Check for deprecated features in 2.x: run GET _cluster/settings?include_defaults=true and fix any settings marked deprecated.
   • Note: 5.x replaces the old string field type with text and keyword—ES will auto-migrate existing mappings, but verify this in your test cluster first.
2. Rolling Upgrade (Same as Stage 1):
   • Stop one node, upgrade to 5.6.23, update config (e.g., network.host must be explicitly set now), start the node.
   • Validate cluster health and node version after each upgrade.
3. Critical Post-Upgrade Step: Reindex for Compatibility
   • Some old 1.x indices might have mapping quirks that 5.x doesn't handle well. Reindex all indices to ensure full compatibility:

     POST _reindex
     {
       "source": { "index": "old_index_name" },
       "dest": { "index": "new_index_name_v5" }
     }
     

   • Once reindexing is done, switch your applications to use the new indices, then delete the old ones (after confirming data is correct).
4. Backup Again: Create a snapshot of the 5.x cluster.

Stage 3: Upgrade from 5.x to 6.x (Latest Patch: 6.8.23) #

This is the final jump, and 6.x has a key restriction: one index can only have one document type. If your 1.x indices have multiple types, you must fix this in 5.x before upgrading to 6.x (use reindex to split types into separate indices or merge them).

1. Rolling Upgrade Process:
   • Stop a node, install 6.8.23, update config (e.g., xpack.security settings if you're using X-Pack, which is included by default in 6.x).
   • Start the node, wait for it to join the cluster, validate health.
   • Repeat for all nodes.
2. Post-Upgrade Validation:
   • Confirm all indices are green with GET _cluster/health?level=indices.
   • Test end-to-end functionality: write new documents, run queries, check dashboards (once Kibana is upgraded).
   • Upgrade Kibana to 6.x (must match the ES 6.x version exactly) and verify it connects and works correctly.

Non-Negotiable Data Safety Rules #

• Backup Before Every Stage: Never move to the next version without a verified, restorable snapshot.
• Test Everything in Staging: Don't try anything in production that you haven't validated in your test cluster first.
• Upgrade During Low Traffic: Schedule upgrades during off-peak hours to minimize impact and reduce the risk of write failures.
• Have a Rollback Plan: If any stage breaks the cluster, shut down the upgraded nodes, restore the previous snapshot to the cluster, and troubleshoot the issue in staging before retrying.

内容的提问来源于stack exchange，提问作者Vaibhav Magon