È sicuro uccidere un processo di replica MySQL che sta 'copiando in tmp table'?

Question

Sto riscontrando un problema su un server master MySQL (5.0, Linux): Ho provato ad aggiungere un commento a una riga della tabella, che si traduce in un comando ALTER TABLE. Ora il processo è bloccato su 'copia su tabella tmp', copiando le 100'000'000 + righe. L'utilizzo del disco IO è troppo alto.

Poiché il master utilizza la replica, non sono sicuro di poter interrompere questo processo. Gli schiavi non hanno ancora visto il comando ALTER TABLE.

(Per chiarire questo punto: sto parlando di uccidere il processo dal MySQL-PROCESSLIST, non il MySQL-daemon-processo stesso.)

Answer 1

Sì, puoi ucciderlo - l'ALTER non lo farà nei binlog fino a quando la transazione non viene confermata, cioè finché ALTER non è terminato. Quindi gli schiavi non la vedranno né la eseguiranno, e il master tornerà alla vecchia struttura del tavolo.

È possibile verificare facilmente che ALTER non è ancora nei binlog utilizzando show binlog events o l'utilità mysqlbinlog.

Answer 2

No, non è sicuro. Solo se si dispone di un backup completo (recentemente) del database, da ripristinare in caso di problemi. Potrebbero esserci dei lucchetti e finirai dopo con le tabelle bloccate, possibili danni ai tasti.

Come consiglio se si aggiungono nuove colonne per un database così grande. E 'più facile

• per creare un copione dello schema tavolo
• eseguire l'alter su quel tavolo mentre è vuota,
• Popola dall'originale con un inserto in ...() selezionare i campi da .. ..

Questo è molto più veloce. Quindi, ovviamente, rinominare il tavolo in originale.

Answer 3

Si può uccidere l'operazione, ma possono accadere due cose:

1. lo schema schiavo è in contrasto con il maestro (e quindi :)
2. la replicazione sugli slave può interrompere.

Quando la replica si ferma, si può provare a correggere manualmente slave (s) saltando sopra la 'alter table' istruzioni immettendo sul server slave:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; SLAVE START;