> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Масштабирование

> Масштабируйте инстанс ClickHouse Managed Postgres по вертикали с помощью гибких типов VM и независимого масштабирования ресурсов

export const Image = ({img, alt, size = "lg"}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} />
      </Frame>
    </div>;
};

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <span>Бета</span>
            </a>;
  }
  return <a href="https://clickhouse.com/docs/reference/settings/beta-and-experimental-features#beta-features" className="betaBadge">
            <span>Возможность в статусе бета</span>
        </a>;
};

<BetaBadge link="https://clickhouse.com/cloud/postgres" galaxyTrack={true} galaxyEvent="docs.managed-postgres.scaling-beta" />

ClickHouse Managed Postgres предоставляет возможности гибкого масштабирования в соответствии с требованиями вашей рабочей нагрузки. Доступно более 50 типов инстансов с NVMe-накопителями, поэтому вы можете независимо масштабировать CPU, память и хранилище, чтобы оптимизировать производительность и стоимость под свой сценарий использования.

<div id="instance-types">
  ## Типы инстансов и гибкость
</div>

ClickHouse Managed Postgres предлагает широкий выбор типов инстансов, каждый из которых оптимизирован под разные рабочие нагрузки:

* **Более 50 типов инстансов** доступны в конфигурациях, оптимизированных по вычислительным ресурсам, памяти и хранилищу
* **NVMe-хранилище** на всех типах инстансов обеспечивает стабильно высокую производительность дискового ввода-вывода
* **Независимое масштабирование ресурсов**: выбирайте оптимальный баланс CPU, памяти и хранилища в зависимости от вашей рабочей нагрузки

<Image img="https://mintcdn.com/private-7c7dfe99/1Nz1dAkMe4yV28t-/images/managed-postgres/instance-types.webp?fit=max&auto=format&n=1Nz1dAkMe4yV28t-&q=85&s=11879f83fe95efa5dd129ed7ce6b532c" alt="Типы инстансов" size="md" border width="1442" height="3288" data-path="images/managed-postgres/instance-types.webp" />

<div id="choosing-instance">
  ### Выбор подходящего типа инстанса
</div>

Для разных рабочих нагрузок подходят разные конфигурации ресурсов:

| Тип рабочей нагрузки                                          | CPU     | Память  | Хранилище | Рекомендуемый инстанс                                          |
| ------------------------------------------------------------- | ------- | ------- | --------- | -------------------------------------------------------------- |
| **С упором на вычисления**                                    | Высокий | Средний | Среднее   | Оптимизированный для вычислений (большое число vCPU)           |
| **С упором на память** (большой рабочий набор)                | Средний | Высокий | Среднее   | Оптимизированный для памяти (высокое соотношение памяти к CPU) |
| **С упором на хранилище** (большие датасеты, интенсивный I/O) | Средний | Средний | Высокое   | Оптимизированный для хранилища (большая ёмкость NVMe)          |

<Tip>
  Из соображений безопасности переход на типы инстансов, объём хранилища которых близок к текущему используемому объёму, может быть недоступен. Чтобы избежать проблем, всегда выбирайте типы инстансов с запасом относительно текущего используемого объёма.
</Tip>

<div id="how-scaling-works">
  ## Как работает масштабирование
</div>

При смене типа инстанса ClickHouse Managed Postgres выполняет вертикальное масштабирование: подготавливает новую инфраструктуру и переносит вашу базу данных с минимальным простоем.

<Image img="https://mintcdn.com/private-7c7dfe99/1Nz1dAkMe4yV28t-/images/managed-postgres/scaling-settings.webp?fit=max&auto=format&n=1Nz1dAkMe4yV28t-&q=85&s=b3a89adf0d75fb1f29c5f6f16d7f285e" alt="Настройки масштабирования" size="md" border width="2478" height="1742" data-path="images/managed-postgres/scaling-settings.webp" />

<div id="scaling-process">
  ### Процесс масштабирования
</div>

В процессе масштабирования из резервных копий поднимается новый резервный инстанс и выполняется контролируемый failover:

1. **Подготовка резервного инстанса**: Создаётся новый резервный инстанс с целевым типом инстанса (CPU, память и конфигурация хранилища)

2. **Восстановление из резервных копий в S3**: Резервный инстанс инициализируется восстановлением из самой свежей резервной копии, хранящейся в S3

3. **Параллельное воспроизведение WAL**: Резервный инстанс применяет все изменения Write-Ahead Log (WAL), произошедшие с момента создания резервной копии, с помощью механизмов параллельного восстановления на базе [WAL-G](https://github.com/wal-g/wal-g)
   * WAL-G обеспечивает быстрые параллельные операции восстановления
   * Создатель WAL-G входит в команду Ubicloud, с которой мы сотрудничаем, что обеспечивает глубокую экспертизу и оптимизацию

4. **Догоняющая репликация**: Резервный инстанс догоняет основной, потоково получая и применяя текущие изменения WAL

5. **Failover**: Когда резервный инстанс полностью синхронизирован, контролируемый failover переводит его в роль нового основного
   * **Это единственный шаг, который вызывает простой** (\~30 секунд)
   * Все активные соединения прерываются во время failover
   * После завершения failover клиентам необходимо переподключиться

6. **Вывод старого инстанса из эксплуатации**: Исходный инстанс выводится из эксплуатации после завершения failover

<div id="scaling-duration">
  ### Продолжительность масштабирования
</div>

Общее время, требуемое для масштабирования, в первую очередь зависит от размера вашей базы данных и объема данных WAL, которые нужно воспроизвести из резервных копий:

* **Восстановление резервной копии**: время, необходимое для восстановления последней полной резервной копии из S3 на новый инстанс
* **Воспроизведение WAL**: время, необходимое для воспроизведения инкрементальных изменений WAL с момента последней полной резервной копии
* **Параллельное восстановление**: механизмы параллельного восстановления WAL-G значительно ускоряют процесс

Время восстановления может составлять от нескольких минут до нескольких часов, но время обслуживания/простоя при этом очень мало (всего \~30 секунд).

<Warning>
  **Минимальный простой**

  Во время переключения на резервный инстанс ваше приложение будет недоступно примерно 30 секунд, независимо от того, сколько времени займет весь процесс масштабирования. Все восстановление и догоняющая синхронизация выполняются в фоновом режиме на резервном инстансе.
</Warning>

<div id="parallel-restore">
  ### Параллельное восстановление с WAL-G
</div>

ClickHouse Managed Postgres использует [WAL-G](https://github.com/wal-g/wal-g) для ускорения восстановления из резервных копий во время операций масштабирования. Важно отметить, что создатель WAL-G входит в команду Ubicloud, с которой мы сотрудничаем, что добавляет процессу восстановления глубокую экспертизу.

WAL-G обеспечивает:

* **Параллельную загрузку и распаковку**: Несколько сегментов резервной копии одновременно загружаются из S3 и распаковываются
* **Эффективное воспроизведение WAL**: Инкрементальные изменения WAL по возможности применяются параллельно
* **Оптимизированную потоковую передачу**: Прямая потоковая передача из хранилища S3 без промежуточного копирования
* **Быстрое восстановление**: Хотя общее время зависит от объема данных, параллельный подход заметно ускоряет этот процесс

Эти оптимизации значительно сокращают время, необходимое для ввода в работу нового резервного инстанса. Что особенно важно, восстановление полностью выполняется в фоновом режиме — ваше приложение столкнется с простоем только во время короткого, примерно 30-секундного окна failover.

<div id="initiating-scaling">
  ### Запуск операции масштабирования
</div>

Чтобы масштабировать инстанс ClickHouse Managed Postgres:

1. Перейдите на вкладку **Настройки** вашего инстанса
2. В разделе **Масштабирование** прокрутите страницу до пункта **Размер сервиса**
3. Выберите целевой тип инстанса
4. Просмотрите изменения и нажмите «Применить изменения»

<div id="scaling-strategies">
  ## Стратегии масштабирования
</div>

<div id="vertical-scaling">
  ### Вертикальное масштабирование
</div>

Вертикальное масштабирование (смена типа инстанса) — основной способ изменения объёма ресурсов в ClickHouse Managed Postgres. Этот подход обеспечивает:

* **Точную настройку**: Выбирайте из более чем 50 типов инстансов, чтобы точно подобрать CPU, память и хранилище
* **Оптимизацию под рабочую нагрузку**: Выбирайте конфигурации, оптимизированные под конкретную рабочую нагрузку (с упором на вычисления, память или хранилище)
* **Экономичность**: Платите только за те ресурсы, которые вам нужны, без избыточного выделения

<div id="read-replicas">
  ### Реплики для чтения для горизонтального масштабирования
</div>

Для рабочих нагрузок с преобладанием чтения рассмотрите возможность использования [реплик для чтения](/docs/ru/products/managed-postgres/read-replicas) для горизонтального масштабирования производительности чтения:

* Перенесите запросы на чтение на выделенные реплики для чтения
* Каждая реплика для чтения — это полностью независимый инстанс Postgres с собственными вычислительными ресурсами и памятью
* Реплики для чтения получают изменения WAL из Объектного хранилища, что обеспечивает эффективную репликацию

Этот подход идеально подходит для приложений с высоким соотношением операций чтения к записи, таких как отчетные панели мониторинга, аналитические запросы или конечные точки API с преобладанием чтения.

<div id="cdc-scaling">
  ### Масштабирование CDC для интеграции ClickHouse
</div>

Если вы реплицируете данные в ClickHouse с помощью [ClickPipes](/docs/ru/products/managed-postgres/clickhouse-integration), вы можете независимо масштабировать конвейер CDC (фиксация изменений данных):

* Масштабируйте CDC-воркеры от 1 до 24 ядер ЦП
* Объем памяти автоматически масштабируется в 4 раза от количества ядер ЦП
* Настраивайте масштабирование через [ClickPipes OpenAPI](/docs/ru/integrations/clickpipes/postgres/scaling)

Это позволяет оптимизировать пропускную способность репликации независимо от ресурсов вашего инстанса Postgres.

<div id="autoscaling">
  ## Автомасштабирование
</div>

ClickHouse Managed Postgres отслеживает использование диска и автоматически увеличивает объём хранилища, чтобы на вашем инстансе не закончилось место:

* **Использование диска: 85%**: Вы получите [уведомление](/docs/ru/products/managed-postgres/monitoring/notifications) в облачной консоли и по электронной почте.
* **Использование диска: 90%**: Запускается автомасштабирование. Объём хранилища увеличивается до следующего доступного размера для семейства вашего инстанса. CPU и память не изменяются, если текущий размер инстанса не поддерживает диск большего объёма; в этом случае размер инстанса также увеличивается. [Реплики для чтения](/docs/ru/products/managed-postgres/read-replicas) масштабируются одновременно с основным инстансом.
* **Использование диска: 95%**: Переключение выполняется без учёта настроенного окна обслуживания сразу после готовности нового сервера.

Если для вашего инстанса уже выбрана максимальная доступная конфигурация, автомасштабирование не может увеличить её дальше. Освободите место на диске или обратитесь в [службу поддержки](https://clickhouse.com/support/program).

<div id="autoscaling-cutover">
  ### Переключение и соединения
</div>

Размер хранилища не изменяется на месте. Автомасштабирование выполняется по тому же [процессу масштабирования](#scaling-process), что и при ручном изменении типа инстанса: подготавливается сервер замены с большим объёмом хранилища, восстанавливается из последней резервной копии, догоняет WAL, а затем в ходе контролируемого переключения становится новым основным. Для инстансов с [высокой доступностью](/docs/ru/products/managed-postgres/high-availability) в рамках той же операции создаются резервные инстансы замены нового размера.

Переключение — единственный этап с простоем, который обычно длится менее минуты. Если настроено [окно обслуживания](/docs/ru/products/managed-postgres/upgrades#maintenance-windows), переключение выполняется в его рамках, если только использование диска не достигнет 95%. Во время переключения открытые соединения разрываются, а незавершённые транзакции откатываются. Строка подключения не изменяется: DNS обновляется и начинает указывать на новый основной инстанс, а приложения со стандартной логикой переподключения автоматически восстанавливают работу.

<div id="autoscaling-read-only">
  ### Режим только для чтения
</div>

Если операции записи заполняют диск быстрее, чем завершается автомасштабирование, инстанс переходит в режим только для чтения, чтобы предотвратить полное заполнение диска. Порог определяется оставшимся свободным местом:

| Общий размер диска | Режим только для чтения при | Запись возобновляется при |
| ------------------ | --------------------------- | ------------------------- |
| До 64 ГБ           | 1 ГБ свободного места       | 2 ГБ свободного места     |
| До 128 ГБ          | 5 ГБ свободного места       | 7 ГБ свободного места     |
| До 512 ГБ          | 7 ГБ свободного места       | 10 ГБ свободного места    |
| Более 512 ГБ       | 2% свободного места         | 3% свободного места       |

Операции чтения продолжают работать, а операции записи завершаются стандартной ошибкой Postgres `cannot execute INSERT in a read-only transaction`. Если свободное место продолжает уменьшаться, существующие соединения разрываются, чтобы каждый сеанс применил настройку только для чтения; после повторного подключения клиентов операции чтения снова работают. Режим только для чтения отключается автоматически после восстановления свободного места, обычно сразу после завершения переключения при масштабировании вверх.

<div id="autoscaling-example">
  ### Пример
</div>

Инстанс с хранилищем объёмом 1024 ГБ обслуживает рабочую нагрузку с интенсивной записью:

1. При использовании 870 ГБ (85%) вы получите уведомление о заполнении хранилища.
2. При использовании 922 ГБ (90%) запускается автомасштабирование. Будет подготовлен сервер замены с хранилищем объёмом 2048 ГБ и восстановлен из последней резервной копии, при этом ваш инстанс продолжит обслуживать трафик.
3. Когда сервер замены синхронизируется, будет выполнено переключение — в пределах окна обслуживания, если оно настроено. Подключения прервутся менее чем на минуту, ваше приложение повторно подключится к тому же имени хоста, а использование хранилища снизится примерно до 45%.
4. Если до завершения переключения свободное пространство опустится ниже 2% (около 20 ГБ), инстанс перейдёт в режим только для чтения. Запись автоматически возобновится после завершения переключения на диск большего размера.

<div id="resources">
  ## Дополнительные материалы
</div>

* [Настройки и конфигурация](/docs/ru/products/managed-postgres/settings)
* [Реплики для чтения](/docs/ru/products/managed-postgres/read-replicas)
* [Высокая доступность](/docs/ru/products/managed-postgres/high-availability)