2

「現実的に」とは、実際のシナリオでは、プライマリ インスタンスからレプリカへのフェイルオーバーが発生した場合、そもそもフェイルオーバーの原因となった何らかの理由で (現在は元の) プライマリ インスタンスが使用できないと予想することを意味します。となり、廃棄されます。それにはいくつかの疑問が生じます:

  1. (ex) プライマリ インスタンスが破棄されると、既存のレプリカが新しいプライマリに昇格します。n - 1 個のレプリカ インスタンスがあるため、新しいレプリカも作成されますか?
  2. 私の仮定のいずれかが正しい場合、RDS の「フェイルオーバー」機能はレプリカに切り替えるだけなので、プライマリ インスタンスが実際に失敗して破棄される場所でこれをテストする方法はありますか?
4

1 に答える 1

1

この文脈での「処分」の意味は確かです。障害が発生した場合、aurora はフェイルオーバーを開始します。これは、レプリカがライターに対して PROMOTED を取得し、古いライターが DEMOTED をリーダーに対して取得することを組み合わせたものです。Aurora が障害のあるインスタンスを完全に削除するかのように聞こえます。それは決して起こりません。ホストが故障していると見なされた場合、ホストを完全に交換する場合があります。これはホストの置き換えと呼ばれ、その場合でも、復旧後に同じ数のインスタンスを持つことになります。

具体的な質問に答えるには:

1) ライターでホストの置換が開始された場合について言及していると思われます。この場合、しばらくの間、n-1 個のレプリカが存在しますが、最終的には新しいホストがプロビジョニングされます。

2) インスタンスを完全にクラッシュさせる障害テストを行いたいと思います。Aurora は、失敗をシミュレートできる一連の失敗挿入クエリを提供します。クラッシュを生成し、フェイルオーバー時間をテストするために使用しましたが、ホストの交換を開始するために使用したことはありません。そのルートを探索したいかもしれません。

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FaultInjectionQueries.html

于 2018-10-26T21:31:23.950 に答える