> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

export const Image = ({img, alt, size = "lg", background}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} style={{
    backgroundColor
  }} />
      </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-vortex-format/xHfTFhAoB3hIpGFb/images/managed-postgres/instance-types.webp?fit=max&auto=format&n=xHfTFhAoB3hIpGFb&q=85&s=32587ab9de145844f42b20c17a6345cc" 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-vortex-format/xHfTFhAoB3hIpGFb/images/managed-postgres/scaling-settings.webp?fit=max&auto=format&n=xHfTFhAoB3hIpGFb&q=85&s=34d4b7cc4deea34c62811c7754b14906" 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

Переключение — единственный этап с простоем, который обычно длится менее минуты. Настроенное [запланированное окно обновления](/ru/products/managed-postgres/upgrades#scheduled-upgrades) не откладывает его: это окно применяется к обслуживанию платформы, а не к масштабированию. Во время переключения открытые соединения разрываются, а незавершённые транзакции откатываются. Строка подключения не изменяется: 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>

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