The Ultimate Guide to High Availability with MariaDB

QA - Aria Recovery

Stai visualizzando una vecchia versione di questo article. Visualizza la versione più recente.

Contents

  1. Principi generali
  2. Test individuali
    1. Il test standard kill -9
    2. Testing con blocchi di piccole dimensioni
    3. Testing con la cache delle pagine di piccole dimensioni
    4. Killing and restarting the recovery process itself
    5. Another realistic workload
    6. Transactional consistency

Principi generali

Il recupero viene testato tramite il Random Query Generator, 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.

Killing and restarting the recovery process itself

In Progress

The AriaDoubleRecovery reporter currently attempts doble recovery via maria_read_log. The first invocation of maria_read_log is killed halfway through the process and the second invocation is left to complete the recovery.

Future testing will involve doing the same with the mysqld server in place of maria_read_log.

Another realistic workload

The usefullness of the SMF workload, derived from the SimpleMachines forum application means that another such workload is required in order to make sure no residual recovery bugs remain. Hopefully something can be cooked up using Wikipedia so that longer fields and blobs are exercised.

Transactional consistency

A transactional grammar that simulates transactions using LOCK TABLEs is required. The RecoveryConsistency Reporter can then be used to validate that no partial transactions appear in the database after recovery.

Commenti

Sto caricando i commenti......
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.