Raj N 2012-06-14, 14:56
Jonathan Simms 2012-06-14, 17:03
Raj N 2012-06-14, 18:56
Patrick Hunt 2012-06-15, 18:17
Raj N 2012-06-15, 19:45
Patrick Hunt 2012-06-16, 00:33
Flavio Junqueira 2012-06-16, 11:25
Raj N 2012-06-16, 16:05
Flavio Junqueira 2012-06-18, 14:41
Mahadev Konar 2012-06-15, 22:27
Patrick Hunt 2012-06-16, 00:27
Please note that in general not doing fsync may lead to inconsistent
data where latter data was written and earlier was not. This may not be
a problem if ZooKeeper validates all it's data on start, but in the
worst scenario I can imagine it will read "last transaction counter"
updated to the latest value but will data not consistent with the
counter. So the problem may be not to handle error, but to detect error.
Best regards, Vitalii Tymchyshyn
14.06.12 21:56, Raj N написав(ла):
> Sorry, I should have been more specific. By corrupt, I mean that the
> zookeeper node doesn't come back up on a restart. I would have imagined
> that zookeeper would sync the lost transactions from its peers. I agree I
> will have a problem if I have multiple failures. But for a single node
> failure in a 3-node ensemble, I should be able to recover even if
> On Thu, Jun 14, 2012 at 1:03 PM, Jonathan Simms<[EMAIL PROTECTED]> wrote:
>> There's a big warning in the documentation that says that's a possibility.
>> If you don't force both Java and the OS to flush their IO buffers to disk,
>> then you have no guarantees that your data is consistent.
>> On 6/14/12 10:56 AM, "Raj N"<[EMAIL PROTECTED]> wrote:
>>> Are you guys aware of any issues with forceSync=no that could cause the
>>> transaction log to get corrupted on a zookeeper crash.