This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-24. For the latest, interactive version please visit https://mariadb.com/kb/.

QA - Aria Recovery

Principi generali

Il recupero viene testato tramite l'RQG, che causa un carico di lavoro casuale sul server, per poi usare kill -9 per terminare il processo. Dopodiché tenta il recupero sia con maria_read_log, sia riavviando il processo mysqld. Una volta avviato il server, le tabelle vengono verificate in vari modi, tra cui ALTER|OPTIMIZE|ANALYZE|REPAIR TABLE e alcune query SELECT che rileggono le tabelle, oltre a diversi altri metodi di accesso.

In una combinazione di file .CC chiamata lp:randgen/conf/engines/maria/maria_recovery.cc vengono definite varie opzioni di mysql e parametri dell'RQG che hanno effetto sul recupeto. Poi lo script combinations.pl dell'RQG viene utilizzato per eseguire centinaia di test individuali. Ogni esecuzione usa una permutazione casuale delle impostazioni nel file .CC per poter generare un carico di lavoro univoco che viene poi validato dal Reporter RQG Recovery.

Test individuali

I singoli test o esecuzioni di test che devono essere completati o creati per assicurarsi che il recupero di Aria sia solido, sono i seguenti.

Il test standard kill -9

Fatto il 28-02-2011 Il test standard conf/engines/maria/maria_recovery.cc passa senza fallimenti quando esegue centinaia di tentativi.

Testing con blocchi di piccole dimensioni

In attesa di 2 bug fix relativi a --maria-block-size=1K e --maria-block-size=2K

Testing con la cache delle pagine di piccole dimensioni

Fatto il 04-03-2011 Completati 400 round con

'--mysqld=--maria-block-size=4K --mysqld=--maria-pagecache-buffer-size=128K',
'--mysqld=--maria-block-size=16K --mysqld=--maria-pagecache-buffer-size=256K',
'--mysqld=--maria-block-size=32K --mysqld=--maria-pagecache-buffer-size=512K'

Due crash pre-recupero sono stati registrati, nessun incidente nel recupero.

Terminare e riavviare il processo stesso del recupero

In corso

Il reporter AriaDoubleRecovery attualmente tenta un doppio recupero con maria_read_log. La prima invocazione di maria_read_log viene terminata a metà dell'esecuzione e si lascia che la seconda invocazione termini il recupero.

In futuro il testing farà la stessa cosa con il server mysqld, invece che con maria_read_log.

Un altro carico di lavoro realistico

L'utilità del carico di lavoro SMF, che viene dall'applicazione di forum SimpleMachines, implica che è necessario un altro carico di lavoro simile per assiurarsi che non resti alcun bug residuo nel recupero. Si spera che sia possibile preparare qualcosa usando Wikipedia per poter stressare campi e blob di dimensioni maggiori.

Consistenza transazionale

E' necessaria una grammatica transazionale che simuli le transazioni per mezzo di LOCK TABLE. Si può usare il Reporter RecoveryConsistency per verificare che non appaia alcuna transazione parziale nel database dopo il recovery.

Vedi anche

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.