Re: IDS cluster

IDS require that writes complete in a certain order (write ordering) i.e. logical log data gets written before data/index pages. With multiple parallel writes and IDS making sure writes to one chunk (containing logical logs) complete before writes to another chunk (data/index) how does the chunk replication software drbd or HP handle this? Does it guarantee that writes complete in the same order as on the primary host? If not the whole IDS Fast Recovery Mechanism goes out the window and either after a crash Fast Recovery will - notice and throw an error (e.g. can't delete something that is not in the data/index page) - not notice an leave you with an inconsistent database that can be spotted via onchecks if you run them. i.e. index containing row but not data page or data page containing row but not index entry (not sure if oncheck spots this second one). - not notice an leave you with an inconsistent database that cannot be spotted via oncheck. Consistent database in terms of data+index pages matching but part of a committed transaction not done or a rolled back transaction where part of the transaction is not rolled back. The second one would not be noticed until potentially months later (Like you oncheck all data/index pages during failover!). The third one would be the hardest to spot since the database structure is internally consistent it is the same as if some row updates/inserts/deletes that are part of a transaction were not included in that transaction. How are you going to spot that? So how do these things handle multiple writes that are part of a transaction and write ordering? Including in this Veritas Volume Replicator.

david@smooth1.co.uk wrote: > IDS require that writes complete in a certain order (write ordering) > i.e. logical log data gets written before data/index pages. > > With multiple parallel writes and IDS making sure writes to one > chunk (containing logical logs) complete before writes to another > chunk (data/index) how does the chunk replication software > drbd or HP handle this? > It handles it AIUI as follows. DRBD is a block level device sitting above the ( potentially raw ) disk partition and below IDS or, in the case of cooked chunks below the filesystem. Whan a block write request comes from the upper layer be it IDS or the filesystem it is written locally, AND remotely to the underlying block device(s) before the write request returns to the caller. The ordering of writes is thus the same as it would be without DRBD. This assumes that you use DRBD protocol C -- Clive