データベースの共有とレプリケーション

データベースの共有とレプリケーション

1）なぜそれを必要とします

• スループット（QPS水平成長を書く）。
• 可用性（高速フェイルオーバー、単一障害点なし）。
• データのローカライズ（マルチリージョン、低遅延）。
• 騒々しい隣人（ホットテナント/ホットキー）の分離。

2）基本的な用語と整合性モデル

Primary/Leader ↔ Replica/Follower：リーダーに書き込み、レプリカに読み込みます。
同期レプリケーション：Nノード（低RPO、高遅延）での書き込み後のトランザクション確認。
非同期：リーダーは後でログをコミットして送信します（RPO> 0、低遅延）。
Quorum （Raft/Paxos）：ほとんどのノードへの書き込み。1つのログ自動リーダー。
Read-after-write：レコードの読み取りが保証されています（第5章を参照）。

ネットワークの問題が発生した場合は、重要なオペレーションの一貫性（CP）または可用性（AP）を選択し、異なるパスのレベルを組み合わせることがよくあります。

3）レプリケーション： オプションとプラクティス

3.1物理的および論理的

物理（WAL/redo/binlog）：ブロックログに近い、シンプルで高速。均質なトポロジー/バージョンに限定されます。
論理：行/テーブルレベルのDML/DDLストリーム。部分的なレプリカ、クロスバージョンの移行、DWH/ストリーミング用のCDCを可能にします。

3.2セットアップと管理

モニタラグ（時間/バイト/LSN）。
ホットスタンバイフィードバックとレプリカの長いリクエストを制限します（VACUUM/クリーニングをブロックしないように）。
MySQLの場合-GTIDとオーケストレーター；PostgreSQL-パトロニ/レプリケーションスロット、synchronous_standby_names。

sql
-- на лидере
ALTER SYSTEM SET synchronous_commit = 'on';
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby_a, standby_b)';
SELECT pg_reload_conf();

sql
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL gtid_mode = ON; -- перезапуск
CHANGE MASTER TO MASTER_AUTO_POSITION=1;

3.3トポロジー

1→N（リーダー→レプリカ）+カスケード（レプリカはさらにマージ）。
マルチプライマリ（アクティブアクティブ）-厳密な競合管理なしでOLTPを回避します。
クォーラムクラスター（いかだ）-ゴキブリDB/ユガバイト/PGラフトアドオン。

4）読み取り/書き込み分割とルーティング

常にリーダーとして書く。キューから読み取るが遅れを考慮する。

1.セッションの粘着性：録音が成功した後、クライアントは'Δ T'の間にリーダーから読み取ります。

2.LSN/GTIDゲート：クライアントは「古いLSN=Xを取得したくない」と言い、ルータはLSN ≥ Xを持つレプリカに送信します。

3.Stale-ok：古いデータ（ディレクトリ/テープ）を許可するクエリがあります。

ツール：PgBouncer/Pgpool-II （Postgres）、 ProxySQL/MaxScale （MySQL）、 Vitess（シャードルーティング）。

LSNゲート（アイデア）の例：'pg_current_wal_lsn（）'をHTTPヘッダ/クッキーに保存し、ルータに'pg_last_wal_replay_lsn（）≥ LSN'でレプリカを要求します。

5）シャーディング戦略

5.1キーの選択

• 'tenant_id'/'user_id'-均等にハッシュしますが、範囲のスキャンは奪われます。
• 時間/IDの範囲-時系列/アーカイブに最適ですが、ホットシャードのリスクがあります。
• 一貫性のあるハッシュ-シャードを簡単に追加/削除できます。
• ディレクトリ/ルックアップテーブル-柔軟（任意のアルゴリズム）、しかし別のテーブル/キャッシュ。

5.2パターン

共有なし：各シャードは個別のデータベース/クラスタであり、アプリケーションはルーティングを知っています。
ミドルウェア共有：Vitess （MySQL）、 Citus （Postgres）、 Proxy-levelはトポロジーを非表示にします。
フェデレーション：サービスによるデータドメインの分離（カタログ、支払い、認証）。

5.3つの合成のキー

キースペース'{tenant}： {entity}： {id}'を使用して、アプリケーションとキャッシュに保存します。Postgres-ハッシュパーティション+LIST/RANGEサブパーティション。

sql
CREATE TABLE orders (
tenant_id int,
id     bigint,
created_at timestamptz,
...,
PRIMARY KEY (tenant_id, id)
) PARTITION BY HASH (tenant_id);

CREATE TABLE orders_t0 PARTITION OF orders FOR VALUES WITH (MODULUS 16, REMAINDER 0);
--... t1..t15

6） ID生成

シャーディングの「ホット」単調なオートインクリメントは避けてください。
Snowflake風の64ビットID （time+region+shard+seq）またはULID/KSUID （monotony and distribution）を使用します。
Postgres-シャードごとのシーケンス。MySQL-auto_increment_increment/offset（シャードリーダーのオフセットが異なる）。

7）オンラインオーバーシェアリングと移行

主な原則：二重書き込み、idempotency、一時的な二重ルーティング。

1.新しいシャード/クラスタを追加します。

2.デュアル読み取り（整合性チェック）を有効にします。

3.デュアルライト（両方のシャード）、レコードの不一致を含める。

4.履歴データ（バッチ、論理/CDCレプリケーション）をバックアップします。

5.「真実の源」を新しい破片に切り替えます。「尾」同期を残します。

6.古いものをオフにします。

ツール：Vitess Resharding、 Citus move shards、 pg_logical/pgoutput、 Debezium （CDC）、 gh-ost/pt-online-schema-change（ロックなしのDDL）。

8）複数の地域および地理配分

地域ごとのリーダー-フォロワー：ローカル読み取り、書き込み-グローバルリーダーを介して（単純なモデルですが、領域横断RTT）。
マルチリーダー：両方のリージョンでの録画-競合（timestamp/version/CRDT）が必要です。
真の分散SQL （Raft）： CockroachDB/Yugabyte-データは地域に「接着」され、クエリはローカルクォーラムに移動します。

• お金/注文-CP （quorum/leader）、ディレクトリ/テープ-AP（キャッシュ、最終的な）。
• 常に可能なスプリットブレインでフェンシング（ユニークなキー/バージョン管理）を計画してください。

9）練習の一貫性

読み書き：LSN/GTIDで「追いつく」リーダーまたはキュー。
単調な読み取り：「古い」最後のLSN読み取りよりも。
書き込み競合制御：'SELECT……FOR UPDATE'、versions（'xmin'/'rowversion'）、UPSERT with version check。
Idemotence：支払い/イベントのidempotenceキー。

10）観察可能性、SLOおよび警報

レプリカラグ：時間（秒）、LSN距離（バイト）、seconds_behind_master （MySQL）。
強制ロールバック/競合、レプリケーションのエラー。
p95/p99レイテンシールート（リーダーとレプリカの読み取り、書き込み）。
スループット：TPS/ロック/行コンテンドテーブル。
Bloat/VACUUM （PG）、 InnoDBバッファプールヒット率（MySQL）。
ダッシュボード：シャードごとのロード「、ホット」シャード、キー配布。

11）バックアップ、PITR、 DR

PITR用のフルバックアップ+WAL/binlog（ポイント・イン・タイム・リカバリ）。
別の地域/クラウドに保存し、定期的にテストを復元します。
シャードの場合、一貫した「スライス」（時間調整/LSN）または回復に関する適用的な偶発性。
RPO/RTOはゲームの日に書かれ、テストされます。

bash pg_basebackup -D /backups/base -X stream -C -S slot_replica_1 архивация WAL через archive_command или pgBackRest/Barman

12）セキュリティとアクセス

VPC/ACLによるセグメンテーション、プロキシによるmTLS。
最低権利の原則に関する役割/助成;shard/roleごとの個々のユーザー。
DDL/DCLの監査、レプリカの「重い」要求の制限。
残り（KMS）およびトランジット（TLS）での暗号化。
Panic Button：インシデント/調査期間中のグローバル'読み取り専用'。

13）用具および煉瓦

PostgreSQL： Patroni （HA）、 PgBouncer （pooling/RO-routing）、 repmgr、 pgBackRest/Barman （бэкап）、 Citus、 pglogical/Logical Replication、 pgbadger/pg_stat_statements。
MySQL： Orchestrator（トポロジ/自動フェイルオーバー）、ProxySQL/MaxScale（ルーティング）、Percona XtraBackup（バックアップ）、Group Replication/InnoDB Cluster、 Vitess（シャーディング/リシェーディング）。
Distributed SQL： CockroachDB、 YugabyteDB （quorum、内蔵sharding/geolocation）。
CDC： イベント/ETLのためのDebezium+Kafka/Pulsar。

14）アンチパターン

自動フェイルオーバーなし、DRテストなしのシングルプライマリ。
ラグ→ファントムエラー/怪しいバグを除いた「魔法」読み取り分割。
「シャーディングのために」シャーディング：垂直スケール/インデックス/キャッシュの代わりに早期合併症。
時間バケツ/ハッシュソルトのない熱い範囲（時間範囲）→1つのシャードは溶けます。
グローバルトランザクションは、OLTPの数十のシャードの上に2PCします-高いp99テールと頻繁なロック。
移行中のデュアル書き込み/デュアル読み取りの欠如→損失/同期不良。
オンラインツールなしと互換性のない機能フラグなしでprodでDDL。

15）実装チェックリスト（0-60日）

0-15日

DB SLO、 RPO/RTOを定義します。
レプリケーション、ラグ監視、基本バックアップ+PITRを有効にします。
ルータ（PgBouncer/ProxySQL）とread-after-writeポリシーを入力します。

16-30日

シャーディング戦略を選択し、キーとスキームを説明します。
過充電ツール（Vitess/Citus/CDC）を準備します。
"read-stale-ok"と"strict'とマークされたサービス/テーブルのディレクトリ。

31-60日

パイロットシャード、デュアルリード、バックフィルを実行します。
ゲーム日：リーダーのフェイルオーバー、PITRからのリカバリ、リージョンスイッチ。
ホットシャードキーと不均一なレポートを自動化します。

16）成熟度の指標

レプリカラグp95<ターゲット（例：クリティカルな読み取りのための500ミリ秒）。
成功したDRテスト≥ 1/4 （RTO ≤復元、RPO ≤の損失）。
シャードによる負荷分散：QPS/ストレージによる不均衡<20％。

strict-consistencyが正しくルーティングされたリクエストの割合=100％

CP保証（マネー/オーダー）を必要とするインシデントのゼロデータ損失。
ダウンタイムなしのオンラインDDL/移行、互換性フラグ付き。

17）レシピ例

sql
-- вычисляйте bucket = hash(user_id) % 16, храните (bucket, created_at)
PARTITION BY LIST (bucket) SUBPARTITION BY RANGE (created_at)

python lsn = db.leader_query("SELECT pg_current_wal_lsn()")
ctx.sticky_until = now()+5s ctx.min_lsn = lsn в роутере чтений: выбираем реплику с last_lsn >= ctx.min_lsn, иначе лидер

json
{
"tables": {
"orders": { "column_vindexes": [{ "column": "tenant_id", "name": "hash" }] }
}
}

18）結論

シャーディングとレプリケーションは、技術だけでなく、一貫性に配慮したルーティング、移行規律（デュアル書き込み/読み取り、バックフィル）、定期的なDRテスト、およびラグ/ホットシャードの観察などのプロセスでもあります。簡単な+read-after-write leader→replicaから始め、ロードプロファイルが本当に必要なshardingを追加します。既製のプラットフォーム（Vitess/Citus/Distributed SQL）を使用して、ビジネスに不可欠なデータをCPモードに保ちます。このようにして、ベースはボトルネックでなくなり、プラットフォームの予測可能で弾力的な基盤になります。