Zero-downtime переіндексація Elasticsearch з аліасами

PUT /products_v2
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 0,
    "refresh_interval": "-1",
    "analysis": {
      "analyzer": {
        "product_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "russian_stemmer"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "id": {
        "type": "keyword"
      },
      "title": {
        "type": "text",
        "analyzer": "product_analyzer",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "price": {
        "type": "scaled_float",
        "scaling_factor": 100
      },
      "new_field": {
        "type": "keyword"
      }
    }
  }
}

На час завантаження вимикаємо репліки та рефреш — це прискорює запис.

Запуск переіндексації з паралельними зрізами

Запускаємо reindex з опцією slices: auto:

POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "products_v1",
    "size": 500
  },
  "dest": {
    "index": "products_v2",
    "op_type": "create"
  },
  "conflicts": "proceed",
  "slices": "auto"
}

slices: auto розбиває задачу на число зрізів, рівне числу шардів джерела. Кожен зріз обробляється незалежно — прискорення в 5-10 разів порівняно з послідовним запуском.

Інкрементальна синхронізація

Поки йде переіндексація, додаток продовжує записувати в старий індекс. Щоб наздогнати нові дані, виконуємо incremental sync:

POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "products_v1",
    "query": {
      "range": {
        "updated_at": {
          "gte": "now-1h",
          "lte": "now"
        }
      }
    }
  },
  "dest": {
    "index": "products_v2",
    "op_type": "index",
    "version_type": "external"
  }
}

version_type: external використовує _version для вирішення конфліктів. Для цього в маппінгу обов'язково поле updated_at.

Як забезпечити атомарне перемикання?

Після завершення переіндексації та синхронізації виконуємо:

# 1. Відновити production налаштування в новому індексі
PUT /products_v2/_settings
{
  "index.number_of_replicas": 1,
  "index.refresh_interval": "1s"
}

# 2. Дочекатися відновлення реплік
curl -u elastic:pw "localhost:9200/_cluster/health/products_v2?wait_for_status=green&timeout=30s"

# 3. Атомарно перемкнути аліас
POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "products_v2",
        "alias": "products",
        "is_write_index": true
      }
    },
    {
      "remove": {
        "index": "products_v1",
        "alias": "products"
      }
    }
  ]
}

Операція атомарна — запити не втрачаються. План відкату: зворотне перемикання аліасу. Не видаляйте старий індекс 24-48 годин. Якщо новий маппінг виявився невірним, просто перемикаємо аліас назад. Всі дані в старому індексі цілі. Додатково можна тримати резервну копію обох індексів.

Чому паралельні зрізи прискорюють процес у рази?

Без slices переіндексація виконується одним потоком. З slices: auto задача розбивається на N підзадач (за числом шардів джерела). На індексі з 5 шардами та 100 млн документів переіндексація займає 6 годин без slices і близько 1 години з ними — прискорення в 5-6 разів. Навантаження на кластер розподіляється рівномірно.

Трансформація даних через Painless

Якщо потрібно змінити структуру документа (розділити поле, нормалізувати ціну), використовуйте скрипт в _reindex:

POST _reindex
{
  "source": {
    "index": "products_v1"
  },
  "dest": {
    "index": "products_v2"
  },
  "script": {
    "source": """
      if (ctx._source.full_name != null) {
        def parts = ctx._source.full_name.splitOnToken(' ');
        ctx._source.first_name = parts[0];
        ctx._source.last_name = parts.length > 1 ? parts[1] : '';
        ctx._source.remove('full_name');
      }
      if (ctx._source.price instanceof String) {
        ctx._source.price = Float.parseFloat(ctx._source.price.replace(',', '.'));
      }
    """,
    "lang": "painless"
  }
}

Покрокова інструкція zero-downtime переіндексації

1. Створіть новий індекс з оптимізованими налаштуваннями (вимкніть репліки та рефреш, налаштуйте аналізатори).
2. Запустіть переіндексацію з опцією slices: auto — це прискорить процес до 10 разів.
3. Виконайте інкрементальну синхронізацію для догонки нових даних.
4. Відновіть production налаштування (репліки, refresh_interval).
5. Дочекайтеся статусу green кластера.
6. Атомарно перемкніть аліас — переіндексація завершена.

Етапи переіндексації з аліасами

Що входить у роботу

• Аудит поточного маппінгу та даних — виявлення полів, що потребують змін, аналіз обсягів та патернів доступу.
• Проектування нового маппінгу — з урахуванням аналізаторів, вкладених полів та типів даних.
• Розробка сценарію міграції — налаштування паралельних зрізів, інкрементальної синхронізації, скриптів трансформації.
• Запуск та моніторинг — відстеження прогресу, швидкості, помилок.
• Документація процесу — опис кроків для повторного використання.
• Пост-міграційна підтримка — 48 годин спостереження після перемикання.

Зв'яжіться з нами для розробки плану міграції. Отримайте консультацію щодо вашого сценарію без даунтайму.