DBの色んなレプリケーション方法

# 前書き
この記事でが様々なレプリケーション方法について解説する
色んなレプリケーションについて軽く触れていく

# 本節
最初にバックアップとレプリケーションの違いについて書いておく

- バックアップ：
  - データの長期保存を目的としており、データの消失や破損に対して備えるための対策。復元作業に時間がかかるため、即時利用するものには向かない
　
- レプリケーション：
  - データの可用性と冗長性を確保し、システム障害時に瞬時に切り替えてダウンタイムを最小限にする、という目的がある
  - 他にも負荷分散などを目的に使用されたりもする
  - しかし、データが壊された場合はその壊されたデータもレプリケーションされてしまい、元の状態などに戻すことができなくなるため、バックアップもレプリケーションもそれぞれ適所に使用する必要がある


この記事では、以下のレプリケーションについての違いや、メリット、デメリットについて述べていく。

- マスタースレーブレプリケーション(Master-Slave Replication)
- マルチマスターレプリケーション(Multi-Master Replication)
- リングレプリケーション(Ring Replication)
- ハブアンドスポークレプリケーション(Hub and Spoke Replication)
- ピアツーピアレプリケーション(Peer-to-Peer Replication)
- ストリーミングレプリケーション(Streaming Replication)
- データベースシャーディング(Database Sharding)

## マスタースレーブレプリケーション(Master-Slave Replication)

マスタサーバの DB を 2台目, 3台目のスレーブに配布する仕組み。一台のマスターサーバーは読み書きが可能で、複数のスレーブサーバーは読み込みのみ可能。スレーブはマスターのデータからのデータの変更を受け取り、自身のデータを更新する。読み取り動作はスレーブで行われることが多く、サーバー台数を増やして負荷を分散したり、マスタに障害が発生した際のリカバリサーバとして利用することができる

特徴：
- 主に非同期レプリケーションが使用される
- 適用例としては、大規模な読み取りが必要なwebアプリケーションなどに使用し、負荷分散を可能にしている

メリット：
- 読み取りが複数サーバーに分散するので、各サーバーの負荷が減る
- スレーブをバックアップなどに使用できる
デメリット；
-  SPOF(Single Point Of Failure)であり、マスターサーバーがダウンしたら書き込みができなくなる
-  非同期レプリケーションの場合、マスターとスレーブに一時的な差異が生じる可能性がある

## マルチマスターレプリケーション(Multi-Master Replication)

複数のマスターサーバーが存在し、各マスターが読み書き可能なレプリケーション方式。各マスター間でデータを相互に同期し、一方のマスターでの変更が他方のマスターにも反映される。

特徴：

- 複数のマスターサーバーが存在し、それぞれが読み書き可能
- 各マスター間で双方向のレプリケーションを実施
- 高可用性とスケーラビリティを提供

メリット：

- 書き込み負荷を複数のマスターに分散できる
- マスターの一つに障害が発生しても、他のマスターが機能を継続できるため、単一障害点を回避できる
- 高可用性が実現可能

デメリット：

- データの競合が発生する可能性があるため、競合解決の仕組みが必要
- 設定や管理が複雑で、運用コストが高くなる
- データの整合性維持が難しくなる場合がある

## リングレプリケーション (Ring Replication)
データベースノードがリング状に接続され、各ノードが隣接するノードにデータをレプリケートする方式。データはリング内を順次伝播し、最終的に全ノードに行き渡る。

特徴：

- ノードがリング状に接続されている
- 各ノードは隣接するノードにのみデータをレプリケート
- データがリングを巡って伝播する

メリット：

- レプリケーショントラフィックが分散される
- ノードの追加や削除が比較的容易

デメリット：

- ノード障害時にデータ伝播が遅延または中断する可能性がある
- データの整合性維持が難しく、遅延が発生しやすい
- 管理が複雑になることがある

## ハブアンドスポークレプリケーション (Hub and Spoke Replication)

中央のハブサーバーが複数のスポークサーバーにデータをレプリケートする方式。ハブがデータの集中管理を行い、スポークはハブからのみデータを受け取る。

特徴：

- 中央のハブサーバーがデータの一元管理を担当
- スポークサーバーはハブからデータを受信する一方向レプリケーション
- スポーク同士の直接通信は行わない

メリット：

- データの一貫性を維持しやすい
- スポークサーバーの追加・削除が容易
- ハブを通じて集中管理が可能

デメリット：

- ハブサーバーに負荷が集中しやすい
- ハブが単一障害点となり、障害発生時に全体に影響を及ぼす可能性がある
- スポーク間のデータ同期が必要な場合、対応が難しい

## ピアツーピアレプリケーション (Peer-to-Peer Replication)

すべてのノードが対等な関係で、各ノードが他のノードとデータを相互にレプリケートする方式。各ノードが読み書き可能で、分散システムを形成する。

特徴：

- すべてのノードが対等で、読み書き操作が可能
- 各ノード間でデータを相互同期
- 高い可用性とスケーラビリティを提供

メリット：

- ノードの追加・削除が容易で、システムの拡張性が高い
- 高可用性を実現し、単一障害点が存在しない
- 負荷をシステム全体で分散できる

デメリット：

- データの競合が発生する可能性が高く、競合解決の仕組みが必要
- レプリケーショントラフィックが増加し、ネットワーク負荷が高くなる
- 設定や管理が複雑で、運用が難しい

## ストリーミングレプリケーション (Streaming Replication)

主にPostgreSQLで使用される、プライマリサーバーのトランザクションログをリアルタイムでスタンバイサーバーにストリーミングしてデータを同期する方式。

特徴：

- プライマリとスタンバイ間でリアルタイムのデータ同期を実現
- データの整合性が高い
- フェイルオーバーによる高可用性を提供

メリット：

- データの整合性が保証され、スタンバイがプライマリとほぼ同期
- プライマリ障害時にスタンバイを昇格させることで迅速な復旧が可能
- データ同期の遅延が少ない

デメリット：

- スタンバイサーバーは通常読み取り専用で、書き込み負荷の分散はできない
- 設定や管理が複雑で、専門知識が必要
- ネットワーク帯域の消費が増加する可能性がある

## データベースシャーディング (Database Sharding)
データベースを複数のシャード（分割されたデータベース）に分割し、それぞれを別々のサーバーで管理する方式。各シャードはデータの一部を保持する。

> 水平シャーディングと垂直シャーティング
> 水平シャーティングは各データの行ごとに分割して保存する
> 垂直シャーティングは各データの列ごとに分割して保存する

特徴：

- データを分割して管理
- 各シャードが独立して動作
- アプリケーション側でデータのルーティングが必要

メリット：

- データベースのスケーラビリティが向上し、大規模データの処理が可能
- 読み書きのパフォーマンスが向上
- サーバー間で負荷を分散できる

デメリット：

- シャード間のデータ結合や集計が困難で、アプリケーションの複雑化につながる
- シャーディングの設計・管理が複雑で、運用が難しい
- データの一貫性を維持するために追加の仕組みが必要となる場合がある

# 終わり
色んなレプリケーション方法のメリットデメリットなどについて簡単に紹介した。詳しくはそれぞれの単語で調べると出てくると思うので、気になったら調べてください！