I might be mistaken in the previous note. If the replication is initiated by the client, it's not a problem as the client doesn't hold data files. But if the replication failure is detected and handled by the client, it looks the multiple failure including the client and replica servers cannot be recovered without some journaling before starting the replication.
- Etsuji Nakai, Red Hat K.K.
----- 元のメッセージ ----- 差出人: "Etsuji Nakai" enakai@redhat.com To: cloudfs-devel@lists.fedorahosted.org 送信済み: 2011年9月14日, 水曜日 午前 9:49:24 件名: Re: RFC: improved replication
Hi,
Here's a simple question.
- Forward the write to all N replicas
- If all N replicas indicate success, we're done
- If any replica fails, add information about the failed request (e.g. file, offset, length) to journals on the replicas where it succeeded
- As part of the startup process, defer completion of startup until brought up to date by replaying peers' journals
What would happen if the primary (forwarder) node fails in the middle of writing its own local file (i.e. before starting the replication)? The file on the primary node is now corrupted, and should be roll-backed to be synced with other replicas. How would it be achieved?
- Etsuji Nakai, Red Hat K.K.
_______________________________________________ cloudfs-devel mailing list cloudfs-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cloudfs-devel