Open Source Summit Japan 2017 の講演 WalB: Real-time and Incremental Backup System for Block Devices のつぶやきまとめ

4
前へ 1 ・・ 4 5 次へ
吉田@板橋 @koedoyoshida

ログデバイスとデータデバイスは同じハードRAID6(10HDD)デバイス #OSSummit

2017-06-01 11:31:09
'or/**/1=1#' @waiha8

“WalB v1.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ” htn.to/beZrKqs

2017-06-01 11:31:31
sat @satoru_takeuchi

データは今一時間に一回リモートに送ってるけどほぼリアルタイムで送り続けてもいい

2017-06-01 11:32:54
sat @satoru_takeuchi

restoreの時間は?=>測ってない

2017-06-01 11:35:13
sat @satoru_takeuchi

DRBDは試したの?=>実用的には有償のDRDB proxyを使う必要があるけどそれは使えなかった

2017-06-01 11:37:06
sat @satoru_takeuchi

他の人のコメント: DRBDはそもそもレプリケーションのためのものでバックアップのためのものではない

2017-06-01 11:38:19
sat @satoru_takeuchi

めちゃくちゃ質問飛んでるなあ

2017-06-01 11:38:36
sat @satoru_takeuchi

ログデバイスの中のデータはリモートに飛ばした後はどうするの?=>消す たしかリングバッファになってたよね

2017-06-01 11:39:17
uchan @uchan_nos

やっぱり皆さん気になるのはWalBでスナップショットを取ったときの整合性。例えばWalB上でファイルシステムやMySQLを動かしている状態でスナップショットを取ると、ブロックレベルで整合性があったとしてもFSやMySQLとしては整合性が崩れるのではと。

2017-06-01 20:55:37
uchan @uchan_nos

それはその通りで、そのスナップショットから再開するにはファイルシステムやMySQLのクラッシュリカバリ機能を使う必要があります。

2017-06-01 20:58:39
uchan @uchan_nos

FSのクラッシュリカバリ(ジャーナリング)はメタデータは保護するがデータ本体は保護しないものがあります。その場合、データ本体まで保護するにはfsyncをちゃんと呼ぶ必要があります。

2017-06-01 21:03:01
uchan @uchan_nos

WalBの発表を(日本語で)再演しようと思います。聞き逃してしまった方、是非! / 第7回 自作OSもくもく会 #atnd #osdev_moku2 atnd.org/events/88555

2017-06-01 23:11:06
Kazuho Oku @kazuho

発表あったのか。行きたかった... / “Open Source Summit Japan 2017 の講演 WalB: Real-time and Incremental Backup System for Block Dev…” htn.to/mEJ6Nj

2017-06-02 06:59:06
sat @satoru_takeuchi

昨日夜の飲み会では、二日間で面白かったセッションとしてNoahとWalBが話題になってました

2017-06-02 07:25:51
ワナベ(wanabe) @wannabe53

WalB 大人気なので、なんなのかぐらいは調べてみようかと。断片化せずに差分でバックアップ・レプリケーションできる、スナップショットが取れないけどまあいいよね、というもの? blog.cybozu.io/entry/5130

2017-06-02 08:02:45
Takashi HOSHINO @starpoz

@uchan_nos @ymmt2005 今の WalB でも、同期的に書き込んだ順序が保証されるという特性がありますので、それを fs が知っていれば、わざわざ fsync しなくても順序を保証できる、という知識を利用して効率化できるという話はありえます。

2017-06-02 08:19:07
Takashi HOSHINO @starpoz

@uchan_nos @ymmt2005 あとは昔 FusionIO が言ってた atomic IO とか。WalB はソフトウェア的にそれを実現可能なので。

2017-06-02 08:20:07
Takashi HOSHINO @starpoz

@uchan_nos @mhiramat @satoru_takeuchi 誤解されそうなので補足。Flush IO request (fsync 相当) が完了して永続化を保証しているデータが消えないための制御が入っています。WalB device はassemble 時に DBMS のようにクラッシュリカバリが動きます。

2017-06-02 08:26:03
Takashi HOSHINO @starpoz

@KengoSawa2 はい、ログデバイスもデータデバイスも冗長化は別途必要です。ログデバイスだけ死んだときは、最新からちょっと古い一貫性のあるデータがデータデバイスにあることは保証されます。

2017-06-02 08:30:08
Takashi HOSHINO @starpoz

@satoru_takeuchi はい、リングバッファになってます。消す前に上書きされたらブロックデバイスとしては動き続けますが、増分が消えてしまったことになるので初期バックアップとはちょっと違う処理ですがフルスキャンしてあげる必要があります。

2017-06-02 08:35:31
Takashi HOSHINO @starpoz

@wannabe53 そんな感じです。その場で snapshot 再現できなくても別のホストで再現できればバックアップに十分なので。その場で snapshot 管理するのは機能面でリッチすぎ、性能面でマイナスという考えです。

2017-06-02 08:59:14
ワナベ(wanabe) @wannabe53

@starpoz ありがとうございます。あまりよくわかっていませんが、小出しにしてかつ順序が保証される、ので(通常は)スパイクしない、というのはとても惹かれます。

2017-06-02 09:45:40
前へ 1 ・・ 4 5 次へ