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

# 高可用性

> ClickHouse Managed Postgres で高可用性を実現するためのスタンバイレプリカとレプリケーションモードを設定します

export const Image = ({img, alt, size}) => {
  return <Frame>
      <img src={img} alt={alt} />
    </Frame>;
};

export const galaxyOnClick = eventName => () => {
  try {
    if (typeof window !== "undefined" && window.galaxy && eventName) {
      window.galaxy.track(eventName, {
        interaction: "click"
      });
    }
  } catch (e) {}
};

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}>
                <Icon />
                <span>Beta</span>
            </a>;
  }
  return <div className="betaBadge">
            <Icon />
            <span>
                Beta feature. 
                <u>
                    <a href="/docs/beta-and-experimental-features#beta-features">
                        Learn more.
                    </a>
                </u>
            </span>
        </div>;
};

Managed Postgres では、耐久性とパフォーマンスの要件に応じて、異なるレベルの高可用性を利用できます。データベースのプロビジョニング時に 1 台または 2 台のスタンバイ レプリカを追加でき、必要に応じて後から **Settings** ページでこの構成を調整することもできます。

<div id="high-availability-options">
  ## 高可用性オプション
</div>

<div id="two-standbys">
  ### 2 つのスタンバイ
</div>

2 つのスタンバイ構成では、プライマリに加えて 2 つのレプリカノードがプロビジョニングされます。どちらのスタンバイもプライマリと同じサイズで、プライマリに障害が発生した場合は、そのいずれかが引き継ぐことができます。

この構成では、**同期レプリケーション**を使用します。これは、プライマリが書き込みを確定する前に、少なくとも 1 つのスタンバイからの確認応答を待つ方式です。これにより、非同期レプリケーションよりも高い耐久性が得られます。必要な確認応答は 1 つだけでよく (両方は不要) 、スタンバイが 1 つだけの同期レプリケーションに比べて、パフォーマンスへの影響も小さくなります。

<div id="one-standby">
  ### 1 スタンバイ
</div>

1 台のスタンバイでは、プライマリに加えてレプリカノードが 1 つプロビジョニングされます。スタンバイはプライマリと同じサイズで、プライマリに障害が発生した場合は引き継ぐことができます。

データは **非同期レプリケーション** を使用してスタンバイにレプリケーションされます。つまり、書き込みはスタンバイからの確認応答を待たずにプライマリにコミットされます。非同期レプリケーションにより、高可用性のために追加のネットワークレイテンシで書き込みが遅くなることはありません。ただしその一方で、プライマリ障害が発生した時点では、スタンバイが最新のトランザクションをまだ受信していない可能性があることも意味します。ほとんどのアプリケーションでは、パフォーマンスと、ごく最近の書き込みが失われるわずかなリスクとのこのトレードオフには十分な価値があります。書き込みの耐久性が必要な場合は、スタンバイを 2 台にすることを推奨します。

<div id="no-standby">
  ### スタンバイなし
</div>

このオプションでは、選択したサイズでプライマリノードのみがプロビジョニングされ、スタンバイノードは作成されません。プライマリノードは引き続き障害を監視されますが、引き継ぎ可能なレプリカが待機していないため、問題の内容によっては復旧に時間がかかる場合があります。この構成は、ある程度のダウンタイムを許容できる開発環境、テスト、または重要度の低いワークロードに適しています。

<div id="standbys-vs-read-replicas">
  ## スタンバイと読み取りレプリカの違い
</div>

Managed Postgres では、スタンバイと読み取りレプリカは用途が異なり、それぞれ個別に構成されます。

**スタンバイ** は、高可用性と自動フェイルオーバー専用です。ストリーミングレプリケーションによってプライマリからデータを複製し、プライマリに障害が発生した場合にいつでも昇格できる状態に保たれています。スタンバイは読み取りクエリ向けには公開されません。

**読み取りレプリカ** は、読み取りのスケーリングを目的として設計されています。オブジェクトストレージから WAL (Write-Ahead Log) データを取得し、専用の接続エンドポイントを持つ独立したネットワーク環境で稼働します。これにより、高可用性の保証に影響を与えることなく、プライマリから読み取りトラフィックを切り離せます。

<div id="why-standbys-dont-serve-read-queries">
  ### スタンバイが読み取りクエリを受け付けない理由
</div>

一部のデータベースプロバイダーは、読み取り専用クエリ向けにホットスタンバイを提供していますが、Managed Postgres では意図的に提供していません。スタンバイで読み取りクエリを許可すると、本来の役割、つまりプライマリに障害が発生した際に即座に引き継げる状態を保つことが損なわれるおそれがあるためです。

主な懸念は 2 つあります。

1. **WAL リプレイとの競合**: 書き込み負荷の高いワークロードでは、スタンバイ上の読み取りクエリが WAL リプレイとシステムリソースを巡って競合します。この競合によりレプリケーションラグが大きくなり、スタンバイがプライマリに後れを取ることがあります。スタンバイにラグがある状態でフェイルオーバーが発生すると、最新のデータを反映しておらず、正常に引き継げない可能性があります。

2. **VACUUM への干渉**: スタンバイ上で長時間実行される読み取りクエリは、プライマリで `VACUUM` (および `AUTOVACUUM`) が不要なタプルをクリーンアップするのを妨げることがあります。PostgreSQL は、いずれかのレプリカ上で実行中のクエリがまだアクセスする可能性のある行を削除できません。その結果、時間の経過とともにテーブルの肥大化やパフォーマンス低下を招くおそれがあります。

スタンバイをフェイルオーバー専用に保つことで、Managed Postgres はスタンバイが常に同期され、最小限のデータ損失とダウンタイムで引き継げる状態を維持しています。読み取りをスケールさせるには、代わりに[読み取りレプリカ](/ja/products/managed-postgres/read-replicas)を使用してください。

<div id="handling-failures">
  ## 障害への対応
</div>

高可用性が有効かどうかにかかわらず、すべての Managed Postgres インスタンスは継続的に障害監視されています。いずれの場合も、システムは障害からの自動復旧を試みます。

スタンバイを利用できる場合は、自動復旧がより迅速かつ容易になります。通常、システムはスタンバイをプライマリに昇格させることで、数分以内に復旧します。スタンバイがない場合は、復旧に手動での対応が必要になることがあり、停止時間が大幅に長引く可能性があります。