Wie kann ich eine MySQL-Tabelle zur Beschädigung zwingen?

17

Ich habe ein einfaches Nagios- Plugin geschrieben, das mysqlcheck aufruft (das nach beschädigten Tabellen sucht ) und bei Beschädigung eine Warnung ausgibt .

Jedoch ist keine meiner Tabellen jetzt beschädigt. Ich bin mir also nicht 100% sicher, ob mein Plugin einwandfrei funktioniert. Ich habe einen Entwickler-Server, der nicht missionskritisch ist. Wie kann ich eine (oder mehrere) der Tabellen erzwingen, dass sie beschädigt sind, damit ich meinen Nagios-Alarm testen kann?

Für die Aufzeichnung ist der Server Ubuntu Dapper und der MySQL ist Version 5.0

— Rory
quelle

interessant .......

— Sander Versluys

3

Angenommen, es handelt sich um MyISAM-Tabellen, könnte man ein Fenster öffnen. Eine leichte Pause sollte ausreichen, um diese säurefreien Tische zum Absturz zu bringen, umzukippen und Feuer zu fangen;)

— David

1

Im Allgemeinen können Sie die Datenbanken nicht sichern, indem Sie sie aus / var / lib / mysql kopieren und dann zurückkopieren, da sie beschädigt werden. Sie müssen stattdessen mysqldump verwenden.

Also, wenn Sie in einen der Ordner für die Datenbank in / var / lib / mysql gehen, dh / var / lib / mysql / myDB / und mit einigen der Dateien herumspielen, die das tun sollten :-)

Daher würde ich empfehlen, eine der Dateien zu kopieren, ein wenig mit einem Hex-Editor zu bearbeiten und sie zurück zu kopieren.

— Kyle Brandt
quelle

8

cat DB1.myd /dev/random > DB2.myd

— Matt Simmons
quelle

Ich mag dieses!

— Kyle Brandt

1

Wird das nicht so lange Daten aus / dev / random ziehen, bis meine Festplatte voll ist? : P

— Rory

2

Hey, du sagtest korrupt, oder? ;-)

— Matt Simmons

Rory, Ya, aber drück einfach irgendwann Strg-C

— Kyle Brandt

Rory, oder verwenden Sie head / dev / urandom, um eine Datei und dann die Katze

— Kyle Brandt

3

Sie können ein Fuzzing-Tool wie zzuf verwenden, um eine bereits vorhandene Datenbankdatei zu fuzzeln , z

zzuf < good.myd > fuzzed.myd

— Gerald Combs
quelle

3

Das sollte es tun:

cat /dev/urandom > yourdb.myd

— Berkus Aurelius
quelle

Das geht so lange, bis meine Festplatte voll ist.

— Rory

2

Ich würde vorschlagen, dass ein realistischerer Weg, Fehler zu simulieren, darin besteht, den Teppich unter den Füßen von MySQL herauszuziehen, während ein intensives Update durchgeführt wird. Die Ausgabe von SIGKILL an den mysqldProzess sollte ausreichen. Wenn Sie MySQL neu starten, werden die betreffenden Tabellen wahrscheinlich als abgestürzt markiert.

Alternativ würde ich vorschlagen, die Vorschläge anderer Personen zu übernehmen, jedoch nicht in der .MYIDatendatei, sondern in der Indec-Datei.

— Dan Carley
quelle

2

Beispiel:

mysql> repair table Transactions;
^CQuery aborted by Ctrl+C
+-----------------------------------+--------+----------+-----------------------+
| Table                             | Op     | Msg_type | Msg_text              |
+-----------------------------------+--------+----------+-----------------------+
| test.Transactions | repair | error    | 137 when fixing table |
| test.Transactions | repair | status   | Operation failed      |
+-----------------------------------+--------+----------+-----------------------+
2 rows in set (17.84 sec)

mysql> select * from Transactions limit 1;
ERROR 144 (HY000): Table './test/Transactions' is marked as crashed and last (automatic?) repair failed

— Quanten
quelle

1

Vielleicht eine Befehlsausführung, die etwa Folgendes bewirkt:

echo "aaa" > file.myd

— Mark L
quelle