GM
что у них не так пошло, и где там что corrupted
Size: a a a
2021 October 12
МК
бля. журнал базы. ЖУРНАЛ
МК
и вот после его докрутки или отката данные оказались покоррапчены
na
и? в журнал при создании снапа могли писаться изменения или выполняться синки? как откатывали снапшот кстати тоже непонятно, может наживую поверх?))
na
снапшот по умолчанию неконсистентен для любого приклада, если не делать определенных телодвижений со стороны приклада
МК
они и сделаны.
МК
но не помогло
МК
каждый считает что баг не у него
GM
а где ты увидел что они считают что баг не у них?
GM
любитель набросить
GM
укажут где что побилось не по их вине - отлично, будет с чем разбираться и искать проблему с другой стороны
na
какие конкретно? все что я вижу в тикете - This was created from a running a single-node k0s cluster controller. On my system, I take periodic snapshots of the zfs filesystem with the zfs-auto-snapshot tool. This filesystem snapshot was taken when the cluster was idle, and I would have expected all durable writes to have been flushed to disk.
na
потом - Given that etcd's storage design includes a WAL, I would have expected that the service would be able to recover from a perceived crash (in this case, a point-in-time filesystem rollback, and not a bug in etcd), with an acceptable bit of data loss for any writes after the snapshot was taken.
na
сплошные I would have expected - угу..
МК
ну уровень вежливости, чо
E
А в чем с этим проблема?
МК
E
С would have expected
na
This filesystem snapshot was taken when the cluster was idle - что он подразумевает под IDLE?__
МК
типа не под нагрузкой