Jak zmusić tabelę MySQL do uszkodzenia?

17

Napisałem prostą wtyczkę Nagios, która wywołuje mysqlcheck (która sprawdza uszkodzone tabele) i ostrzega, jeśli są uszkodzone.

Jednak żadna z moich tabel nie jest teraz uszkodzona. Nie jestem więc w 100% pewien, że moja wtyczka działa dobrze. Mam serwer deweloperów, który nie jest krytyczny dla misson. Jak zmusić jedną (lub dowolną) ze znajdujących się tam tabel do uszkodzenia, aby móc przetestować alert nagios?

Dla przypomnienia, serwerem jest Ubuntu Dapper, a mysql to wersja 5.0

— Rory
źródło

ciekawe .......

— Sander Versluys

3

Zakładając, że są to stoły MyISAM. Wyobrażam sobie, że możesz po prostu otworzyć okno. Nieznaczne breaze powinno wystarczyć, aby spowodować te wolnego kwasu tabele upaść, przewrócić i zapalić;)

— David

1

Zasadniczo nie można wykonać kopii zapasowej baz danych, kopiując je z / var / lib / mysql, a następnie kopiując je z powrotem, ponieważ uległy uszkodzeniu, zamiast tego należy użyć mysqldump.

Więc jeśli przejdziesz do jednego z folderów bazy danych w / var / lib / mysql, tj. / Var / lib / mysql / myDB / i zadzierasz z niektórymi plikami, które powinny to zrobić :-)

Polecam więc skopiowanie jednego z plików, edycję trochę przy pomocy edytora szesnastkowego i skopiowanie go z powrotem.

— Kyle Brandt
źródło

8

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

— Matt Simmons
źródło

Podoba mi się ten!

— Kyle Brandt,

1

Czy to nie ciągnie danych z / dev / random, dopóki mój dysk twardy się nie zapełni? : P

— Rory,

2

Hej, powiedziałeś zepsuty, prawda? ;-)

— Matt Simmons,

Rory, Ya, ale w pewnym momencie po prostu nacisnąłem Ctrl-C

— Kyle Brandt,

Rory, Lub użyj head / dev / urandom do pliku, a następnie cat tych

— Kyle Brandt

3

Możesz użyć narzędzia do fuzzowania, takiego jak zzuf, aby sfałszować istniejący plik bazy danych, np

zzuf < good.myd > fuzzed.myd

— Gerald Combs
źródło

3

To powinno to zrobić:

cat /dev/urandom > yourdb.myd

— Berkus Aurelius
źródło

Tak będzie, dopóki mój twardy dysk się nie zapełni.

— Rory

2

Sugerowałbym, że bardziej realistycznym sposobem symulowania błędu byłoby wyciągnięcie dywanu spod stóp MySQL podczas intensywnej aktualizacji. Wydanie SIGKILL do mysqldprocesu powinno wystarczyć. Możliwe, że po ponownym uruchomieniu MySQL dane tabele zostaną oznaczone jako zawieszone.

Alternatywnie sugerowałbym zastosowanie sugestii innych osób, ale do .MYIpliku indec zamiast do pliku danych.

— Dan Carley
źródło

2

przykład:

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

— kwanty
źródło

1

być może wykonanie polecenia, które robi coś takiego:

echo "aaa" > file.myd

— Mark L.
źródło