Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
In some test that I have been performing, I have noticed that DRBD is reporting "Digest integrity check FAILED" errors when MySQL is told to perform a large number of SQL inserts into the same table, similar to the following:
INSERT INTO TABLE VALUES ('A1','A2','A3' );
INSERT INTO TABLE VALUES ('B1','B2','B3' );
INSERT INTO TABLE VALUES ('C1','C2','C3' );
..... [ 3000 rows repeated ]
However, if the same amount of data is inserted using a single INSERT statement as shown below, no digest integrity errors occur.
INSERT INTO TABLE VALUES ('A1','A2','A3' ), ('B1','B2','B3' ), 'C1','C2','C3'), ....
I'm using DRBD 8.2.7 on ext3 filesystems. Servers are HP DL580 G5, 4 x Quad-core, Smart Array P400, 16G RAM. Firmware is relatively recent. OS is RHEL 5.3. TCP offload disabled using ethtool.
drbd.conf includes
net {
data-integrity-alg md5;
}
I have imported many gigabytes of MySQL dumps (generated from mysqldump) and have seen no digest integrity errors. But I can almost immediately trigger a "Digest integrity check FAILED", by running a few thousand 'INSERT INTO TABLE' statements that totals about 500KB of data.
I've tried this on 2 seperate MySQL Heartbeat/DRBD clusters with the same results, so I don't believe the hardware is flakey.
Is it possible that similar to ReiserFS and swap, MySQL could be responsible for modifying the data while the transfer is taking place causing these false positives?
I've noticed in the archives a number of people who are trying to find the cause of "Digest integrity check FAILED" errors have been running MySQL.
- Frank