QA - Aria Recovery
Contents
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.
