Mysql InnoDb su un dispositivo grezzo in una topologia attiva / passiva

Question

Abbiamo una topologia attiva / passiva in cui ci sono due complessi X86 con una memoria raw condivisa, in cui solo uno dei nodi in un dato momento ha un accesso alla memoria condivisa (AKA il nodo attivo). In caso di un failover nel nodo attivo, il nodo passivo avvia un rilevamento e diventa il nodo attivo con un accesso alla memoria condivisa. Ogni nodo ha la propria archiviazione del dispositivo di avvio con un filesystem. Tuttavia, la memoria condivisa non può avere un filesystem montato su di esso.

Siamo interessati a installare MySQL su entrambi i nodi, in cui i suoi dati risiedono nello spazio di archiviazione condiviso e solo il nodo attivo esegue il server.

mysql con InnoDB è in grado di correre su un crudo Dispositivo e c'è anche una guida su come eseguire mysql su un cluster simile alla nostra topologia . Tuttavia, nel secondo esempio, hanno un filesystem montato sullo stoccaggio condiviso. Il problema del filesystem solleva una preoccupazione importante:

IB_LOGFILE * Richiede ancora un file system. Quindi la funzione Raw MySQL non è esattamente completamente cruda. Per favore correggimi se mi sbaglio. C'è una soluzione alternativa per archiviare quei file nella memoria cruda? Possiamo salvare i registri RedoDo (ib_logfile0, ib_logfile1) nel dispositivo di avvio del nodo e eliminare sempre tali file prima che il server stia iniziando (quindi non avremo vecchi file di file in caso di preavviso multiplo). Tuttavia, ciò potrebbe portare a una transazione non conquistata per essere parzialmente impegnata in caso di fallimento in un mezzo di una transazione, contraddicando così l'intera idea delle transazioni.

Ci sono altri file / funzionalità che potrebbero influire sul comportamento di MySQL in questa topologia?

Answer 1

Vale la pena notare che il registro proseguimento di InnoDB (WAL), IB_LOGFile *, non è l'unica cosa che avrà bisogno di un file system. Hai:

.
1. Tabelle di sistema nello schema MySQL che probabilmente usano il motore di archiviazione Myisam (.FRM, .MYD, .myi per tabella) (la maggior parte ora ora sta usando INNODB IN 5.7)
2. .FRM File per ciascuna tabella InnoDB, anche quando si utilizza il tablespace del sistema condiviso (metadati da tabella richiesti)
3. file di registro mysql (log errori, registro generale, log binario)
4. Artifatti SSL
5. Auto.CNF (dove viene generato l'UUID di istanza MySQL e memorizzato automaticamente)
6. file db.opt per ciascun schema (in /<datadir>/<schema>/)
7. .PAR file se crei una tabella partizionata (andata in 5.7)
8. .trn e .trg file se crei trigger
9. InnoDB TMP Tablespace (5.6 +)
10. Piscina tampone persiste sulla pagina Page (IB_BUFFER_POL, 5.6 +)

Tutto quanto sopra è in genere all'interno del Elenco dati , così a condizione che tu abbia datadir=/some/valid/fs/path - che è anche replicato (ad es. DRBD) o condiviso (ad esempio NFS, GFS, OCFS) tra i due nodi - allora starai bene.

Vale la pena notare che i file .brm, .par, .trn, .trg e .opt andranno via con Nuovi dati dizionario .

Resta sintonizzato per alcuni grandi annunci lì nei prossimi mesi! :)

Non mi è chiaro perché stai usando il dispositivo grezzo? Sono sicuro che hai le tue ragioni però. :)

Buona fortuna!

Answer 2

La tecnica di archiviazione grea è buona per Ibdata1 con INNODB_FILE_PER_TABLE disabilitato.

Ho detto che imposta questo un paio di volte

.
• Jul 25, 2012: Design del database - Creazione di più database per evitare il mal di testa del limite sul formato della tabella
• Feb 26, 2013: Manutenzione in MySQL Quando INNODB_FILE_PER_TABLE disabilitato

Nota Innodb Architecture (Immagine di Percona CTO VADIM Tkachenko)

con Innodb_file_per_table disabilitato, dati E gli indici per tutte le tabelle InnoDB atterrebbero all'interno della memoria grea insieme con il buffer di doppia scrittura, inserire buffer, dizionario dati, segmenti di rollback e svuotamento dello spazio.

Per quanto riguarda i registri Redo, è necessario considerare avere un piccolo dispositivo Block DRBD solo per contenere /var/lib/mysql, con ib_logfile0 e ib_logfile1 in quella cartella. Pertanto, il failover sarebbe andato come segue

.
• Break DRBD tra i due server
• Imposta lo stato DRBD del nuovo server su Primary/Unknown
• Mount DRBD su /var/lib/mysql
• Mount Device Raw con informazioni IBData1
• service mysql start
• Dispositivi DRBD Sync
• Setup Pacemaker / UCARP Servizi per prep per il failover successivo

Preferito DRBD / UCARP per configurazioni di failover. Vedi i miei vecchi post su di loro

Aggiornamento 2015-10-14 11:30 EDT

Come ho già detto, i registri Redo devono essere nel dispositivo Block DRBD montato su /var/lib/mysql. Per quanto riguarda gli altri file essenziali come

.
• log binari
• logs relè
• Accedi errori
• log lento
• Log Generale

Tutti questi file devono essere anche in /var/lib/mysql. In questo modo, i failovers trasporteranno tutto MySQL correlati (meno i dati grezzi che si trovano nel proprio disco).

Avvertenza : questa configurazione non è per tavoli Myisam. Se si verifica un failover rigido, tutte le tabelle Apri Myisam prima del crash / failover saranno contrassegnate come corrotte e richiedono l'esecuzione di REPAIR TABLE su tutte le tabelle Myisam.

Se tutte le tabelle sono InnoDb, ignora questo avviso. Se converti le tue tavole Myisam rimanenti in InnoDB, puoi ignorare questo avviso. (Non convertire tabelle Myisam nello schema mysql in InnoDB).