エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思え
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思え
key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場... key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思えるのですが,この問題はうまく回避できるのでしょうか 前提として世の中にあるデータベースは基本的にログファイルが破損する事を想定していません。ログは信頼できるストレージに複製込で保存されており、化けたり消えたりする事はないという前提を置いています。想定する一番大きな障害でもMedia Fai