生产环境下，MySQL大事务操作导致的回滚解决方案
<p>如果mysql中有正在实行的大事件DML语句，此时不能直接将该历程kill，否则会引发回滚，非常消耗数据库资源和性能，生产环境下会导致巨大生产事故。</p><p>如果事件利用的语句非常之多，而且没有办法等待那么久，可以采取以后利用：</p>
<p><strong>1. 在数据库中的配置文件中新增：innodb_force_recovery = 3。</strong></p>
<p>innodb_force_recovery影响整个InnoDB存储引擎的恢复状态。默认为0，体现当需要恢复时实行全部的innodb_force_recovery可以设置为1-6,大的数字包含前面全部数字的影响。当设置参数值大于0后，可以对表举行select,create,drop利用,但insert,update或者delete这类利用是不允许的。</p>
<p>1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。<br />2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要实行full purge利用，会导致crash。<br />3(SRV_FORCE_NO_TRX_UNDO):不实行事件回滚利用。<br />4(SRV_FORCE_NO_IBUF_MERGE):不实行插入缓冲的归并利用。<br />5(SRV_FORCE_NO_UNDO_LOG_SCAN):不检察重做日志，InnoDB存储引擎会将未提交的事件视为已提交。<br />6(SRV_FORCE_NO_LOG_REDO):不实行前滚的利用。</p>
<p><em id="__mceDel"><br /><strong>2. </strong></em><strong>重启msql，drop掉导致回滚的表，再将配置文件恢复成默认值（即不需要在配置文件中设置innodb_force_recovery参数），再次重启mysql。</strong></p>
<p> 重启利用会因为数据量非常大，导致mysql恢复缓慢，此时需要等待mysql举行瓦解恢复。根据数据量的不同，等待的时间也不同。</p>
<p> </p>
<p>注：</p>
<p> 如果需要导入导出数据库数据，可以使用以下下令：</p>
<p> 1. 导出：mysqldump-uroot -p --opt -R -E --default-character-set=utf8 --databases device2> /mysql/device_20191022.sql</p>
<p> mysql5.7以后可以使用pump下令，调用多线程：</p>
<p> /mysql/bin/mysqlpump -uroot -p --default-character-set=utf8 --compress-output=LZ4 --default-parallelism=4 --databases device2 > /mysql/device_20191022.sql.LZ4</p>
<p> 2. 导入：mysql -uroot -p < /opt/device_20191022.sql</p>
<p> 如果使用了pump导出，需要先解压：</p>
<p> lz4_decompress /tmp/backup_kevin.sql /tmp/kevin.sql</p>
<p> mysql < source /tmp/kevin.sql;</p><br><br/><br/><br/><br/><br/>来源：<a href="https://www.cnblogs.com/wangjingu/p/11729462.html" target="_blank">https://www.cnblogs.com/wangjingu/p/11729462.html</a>
页:
[1]