Dr. Thorsten Brandau schrieb am 27.05.23 um 09:36:
Phil Stracchino schrieb am 26.05.23 um 18:57:
On 5/26/23 11:39, Dr. Thorsten Brandau wrote:
When I use mysqlcheck I get
Warning : InnoDB: The B-tree of index PRIMARY is corrupted.
mysqlcheck -r bacula returns
"storage engine does not support repair"
So, the B-Tree is still corrup on PRIMARY.
OK. If that is the only problem, and there is plenty of free disk
space (AT LEAST the size of the File.ibd file), this SHOULD be
straightforward to repair.
Try this:
ALTER TABLE File DROP PRIMARY KEY, ADD PRIMARY KEY (FileId);
That will recreate the corrupted index. Expect it to take a while.
If NOTHING ELSE is corrupted, you should be good.
Thank you. However, it does not seem to work:
in mysql console
use bacula
ALTER TABLE File DROP PRIMARY KEY, ADD PRIMARY KEY (FileId);
Query OK, 0 rows affected (0,002 sec)
Records: 0 Duplicates: 0 Warnings: 0
CHECK TABLE File ;
+-------------+-------+----------+---------------------------------------------------+
| Table | Op | Msg_type | Msg_text
|
+-------------+-------+----------+---------------------------------------------------+
| bacula.File | check | Warning | InnoDB: The B-tree of index PRIMARY
is corrupted. |
| bacula.File | check | error | Corrupt
|
+-------------+-------+----------+---------------------------------------------------+
And I cannot recreate the indicies as previously with the same error
message "ERROR 1030 (HY000): Got error 106 "Transport endpoint is
already connected" from storage engine InnoDB
When I check the indicies:
show indexes from File;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name |
Collation | Cardinality | Sub_part | Packed | Null | Index_type |
Comment | Index_comment | Ignored |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| File | 0 | PRIMARY | 1 | FileId | A
| 46738695 | NULL | NULL | | BTREE |
| | NO |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
1 row in set (0,001 sec)
The Backup that started yesterday as scheduled (I kept it alive to
find out if it works) gives very mixed messages in Bacula. Status Dir
says, one job running, despooling. Status Client says, no job running,
status storage says despooling but about x10 the bytes are the backup
job...
Not sure if there is any other way to heal this that removing the
catalogue and starting fresh. Is that possible? Or is there a way
where Bacula re-reads the catalogues from the changer?
Starting with a fresh full backup would not be an issue at this time
(well unless a couple of raids die tomorrow, that I would be screwed).
Not so cheery Cheers
T
Well, I tried a bit more and found some hints to remove the
AUTO_INCREMENT form the FileId field and readding it. However, I could
remove it, but not added again (ERROR 1034 (HY000): Index for table
'File' is corrupt; try to repair it)
So I am pretty much on the verge of having the database killed.
I hope anybody has something how to repair it, otherwise I would be
happy to understand how I can just remake the cataloge database and
start at zero.
What concerns me most, that this happened without anything going on
except a backup. No power outtage, no crash no nothing. That seriously
makes me think if Bacula is a good solution to rely on backups...
I hope someone can prove me wrong.
Cheers
T
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
