精华内容
下载资源
问答
  • 如发生在 mysql 软件可承受力够但是服务器硬件,或者...宕机 又或者 MYSQL 参数配置过大或者参数配置不合理导致服务器崩溃 ,出现宕机的可能多种多样,本文档主要体现的是宕机后可能出现的问题和后遗症较大的情况是什么
  • Mysql数据库宕机恢复mysql增量恢复必备条件:*开启mysqllog-bin日志功能mysql数据库开启了log-bin参数记录binlog日志功能如下:[root@wikiDB~]# grep log-bin /data/3306/my.cnflog-bin= /data/330...

    WIKI系统宕机恢复:

    由于WIKI系统为虚拟机环境,当出现问题时可直接使用镜像恢复。而且虚拟机环境故障率较低。

    Mysql数据库宕机恢复:

    9b8bfe3ed1e6e4d964c9d6f5c03a0df6.png

    mysql增量恢复必备条件:

    *开启mysqllog-bin日志功能

    mysql数据库开启了log-bin参数记录binlog日志功能如下:

    [root@wikiDB~]# grep log-bin /data/3306/my.cnf

    log-bin= /data/3306/mysql-bin

    *存在mysql数据库全备

    宕机恢复解读:

    如上图所示;我们的mysql数据库,每天凌晨00:00-01:00期间,对数据库进行分库备份。备份方式为不锁表备份,不影响线上用户查看资料。同时定时任务每2个小时就对binlog日志进行一次远端推送,到WIKI虚拟主机上(至于为什么放在虚拟主机上,我是这样做的。虚拟主机首先关于硬件的故障是没有的,只要不是人为操作。那么它就很安全;而且虚拟主机备份起来很方便,做个镜像即可。当出现问题时,还原镜像;)。同时mysql数据库开启samba服务,允许备份服务器进行拷贝数据。也就是说我们同时做了双备份,当出现问题时,有多余的备份在手里。

    宕机恢复步骤:

    1)检查全备及binlog日志

    [root@lamp3306]# ll /server/backup/

    总计148

    drwxr-xr-x2 root root 4096 2013-06-17192.168.126.129

    -rw-r--r--1 root root 136950 06-16 22:18 mysql_backup_2013-06-16.sql.gz

    -rw-r--r--1 root root 140 06-16 22:18mysqllogs_2013-06-16.log

    [root@lamp3306]# ll -rt /data/3306/mysql-bin.*

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000014

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000013

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000012

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000011

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000010

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000009

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000008

    -rw-rw----1 mysql mysql 1292 06-16 22:18 /data/3306/mysql-bin.000007

    -rw-rw----1 mysql mysql 415 06-16 22:40 /data/3306/mysql-bin.000015

    增量日志的开始点,可以看时间的先后,进行判断。这里我们发现是22:40为最新的binlog。

    立即刷新并备份出binlog

    [root@lamp3306]# mysqladmin -uroot -p'oldboy' -S /data/3306/mysql.sock flush-logs

    [root@lamp3306]# ll -rt /data/3306/mysql-bin.*

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000014

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000013

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000012

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000011

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000010

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000009

    -rw-rw----1 mysql mysql 149 06-16 22:18/data/3306/mysql-bin.000008

    -rw-rw----1 mysql mysql 1292 06-16 22:18 /data/3306/mysql-bin.000007

    -rw-rw----1 mysql mysql 106 06-16 22:51/data/3306/mysql-bin.000016

    -rw-rw----1 mysql mysql 458 06-16 22:51/data/3306/mysql-bin.000015

    [root@lamp3306]# cp mysql-bin.000015 /server/backup/

    恢复binlog生成SQL语句

    [root@lamp3306]# cd /server/backup/

    [root@lampbackup]# mysqlbinlog mysql-bin.000015 >bin.sql #该命令为将二进制的binlog日志,转换为sql语句。

    [root@lampbackup]# egrep -v "^#|^$|\*" bin.sql

    BINLOG'

    M8m9UQ8BAAAAZgAAAGoAAAAAAAQANS4xLjYyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

    AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC

    BEGIN

    insertinto student values(0006,'xiaobao','man',29,'computer')

    dropdatabase oldboy

    DELIMITER;

    可以看出,这个文件就是我们数据库的增量。也就是从0点备份到发现出问题期间的所有mysql数据库的操作。

    提示:如果有多个库,此时:

    2)恢复凌晨全备

    开始恢复,先回复凌晨全备,然后恢复整备到出问题时的所有增量数据。

    解压全备文件

    [root@lampbackup]# gzip -d mysql_backup_2013-06-16.sql.gz

    开始恢复全备

    [root@lampbackup]# mysql -uroot -p'oldboy' -S /data/3306/mysql.sock

    [root@lampbackup]# mysql -uroot -p'oldboy' -S /data/3306/mysql.sock -e "showdatabases;"

    +--------------------+

    |Database |

    +--------------------+

    |information_schema |

    |baozi |

    |chengcai |

    |haole |

    |lalala |

    |mysql |

    |oldboy |

    |test |

    |xiaobao |

    +--------------------+

    [root@lampbackup]# mysql -uroot -p'oldboy' -S /data/3306/mysql.sock -e "set namesgbk;select * from oldboy.student;"

    +-----+-----------+------+------+--------------------+

    | Sno| Sname | Ssex | Sage | Sdept |

    +-----+-----------+------+------+--------------------+

    | 1 | ???? | ?? | 24 | ?????ú???? |

    | 2 | elain | ?? | 26 | computer applica |

    | 3 | xiaozhang | ?? | 28| ???÷???í |

    | 4 | jeacen | ?? | 20 | computer applica |

    | 5 | ???? | ?? | 29 | ?????ú???§?????? |

    +-----+-----------+------+------+--------------------+

    3)恢复增量备份

    然后我们进行恢复全备和增量备份:

    [root@lampbackup]# mysql -uroot -p'oldboy' -S /data/3306/mysql.sock

    [root@lampbackup]# mysql -uroot -p'oldboy' -S /data/3306/mysql.sock

    +-----+-----------+------+------+--------------------+

    | Sno| Sname | Ssex | Sage | Sdept |

    +-----+-----------+------+------+--------------------+

    | 1 | ???? | ?? | 24 | ?????ú???? |

    | 2 | elain | ?? | 26 | computer applica |

    | 3 | xiaozhang | ?? | 28| ???÷???í |

    | 4 | jeacen | ?? | 20 | computer applica |

    | 5 | ???? | ?? | 29 | ?????ú???§?????? |

    | 6 | xiaobao | ma | 29 | computer |

    +-----+-----------+------+------+--------------------+

    现在我们恢复到了0点到出现问题时刻的全备数据。

    注意:恢复时应严格按照步骤进行,提取最新的binlog日志。尽量减少数据的丢失。保证数据的完整。

    展开全文
  • 针对突然宕机的问题不会自动继续执行,不会自动直接回滚,但是可以人工手动选择继续执行或者直接回滚,依据是事务日志。事务开启时,事务中的操作,都会先写入存储引擎的日志缓冲中,在事务提交之前,这些缓冲的日志...

    针对突然宕机的问题

    不会自动继续执行,不会自动直接回滚,但是可以人工手动选择继续执行或者直接回滚,依据是事务日志。

    事务开启时,事务中的操作,都会先写入存储引擎的日志缓冲中,在事务提交之前,这些缓冲的日志都需要提前刷新到磁盘上持久化,这就是人们口中常说的“日志先行”(Write-Ahead Logging)

    日志分为2种

    redo log

    保障的是事务的持久性和一致性

    在系统启动的时候,就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录redo log,通过顺序io来改善性能

    所有的事务共享redo log的存储空间,它们的redo log按语句的执行顺序,依次交替的记录在一起

    如果数据库崩溃或者宕机,那么当系统重启进行恢复时,就可以根据redo log中记录的日志,把数据库恢复到崩溃前的一个状态。未完成的事务,可以继续提交,也可以选择回滚,这基于恢复的策略而定。

    undo log

    保障了事务的原子性

    主要为事务的回滚服务

    undo log记录了数据在每个操作前的状态,如果事务执行过程中需要回滚,就可以根据undo log进行回滚操作

    redo log和undo log的过程分析

    eg : 假设有2个数值,分别为A和B,值为1,2

    1 start transaction;

    2 记录 A=1 到undo log;

    3 update A = 3;

    4 记录 A=3 到redo log;

    5 记录 B=2 到undo log;

    6 update B = 4;

    7 记录B = 4 到redo log;

    8 将redo log刷新到磁盘

    9 commit

    在1-8的任意一步系统宕机,事务未提交,该事务就不会对磁盘上的数据做任何影响.

    如果在8-9之间宕机,恢复之后可以选择回滚,也可以选择继续完成事务提交,因为此时redo log已经持久化

    若在9之后系统宕机,内存映射中变更的数据还来不及刷回磁盘,那么系统恢复之后,可以根据redo log把数据刷回磁盘

    展开全文
  • mysql宕机恢复原理

    2020-04-12 23:02:11
    异常故障恢复 并行复制总是存在一个不可避免的问题,那就是在从库并行执行的过程中,如果数据库或操作系统挂了,那么此时每个线程执行的点就都是不确定的。也就是说顺序的binlog被分发出去了之后,从最小位置到最大...

    异常故障恢复

    并行复制总是存在一个不可避免的问题,那就是在从库并行执行的过程中,如果数据库或操作系统挂了,那么此时每个线程执行的点就都是不确定的。也就是说顺序的binlog被分发出去了之后,从最小位置到最大位置之间这块连续的内容之间存在断点的。如此一来,从库恢复之后,开始执行时就需要准确无误地还原哪些已经执行,哪些还没有执行。

    一个正在并行执行的事物队列,也可以说这些事务的last_committed都是相同的,并且从前到后。此外sequence_number是顺序增长的,也就是说以binlog文件内容的顺序排列的。

    整个队列被分配之后,在某一时刻,队列执行的状态,假设从库挂了,,那么在次启动之后,如何继续执行?

    mysql为了实现对执行状态的记录,做了很多工作,首先就是维护一个队列,这个队列叫做GAQ,group assigned queue,SQL线程在分配某一个事务时,首先会将这个事物加入到这个队列,之后系统会将当前事物分发到一个线程来执行。可以想到,在某一个时刻,任务队列GAQ及每个线程的执行队列,每一个事物,在分发之后,都会有一个标号,这个标号在某一段时间内,都是相对固定的,这个编号在某一时间段内都是相对固定的如图:

    每一个事务都有一个编号,编号只要分配了,就不会在变。在事物获取编号且被所属线程执行之后,它的位置信息会被FLUSH一次,这与mysql5.5.版本中的relay_info是类似的,用来存储从库执行的位置。但是现在已经变为多线程了,那么每个线程执行到什么位置,是需要记录下来的,此时就用另一个表mysql.slave_worker_info来存储。

     

    mysql> show create table slave_worker_info\G
    *************************** 1. row ***************************
           Table: slave_worker_info
    Create Table: CREATE TABLE `slave_worker_info` (
      `Id` int(10) unsigned NOT NULL,
      `Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
      `Relay_log_pos` bigint(20) unsigned NOT NULL,
      `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
      `Master_log_pos` bigint(20) unsigned NOT NULL,
      `Checkpoint_relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
      `Checkpoint_relay_log_pos` bigint(20) unsigned NOT NULL,
      `Checkpoint_master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
      `Checkpoint_master_log_pos` bigint(20) unsigned NOT NULL,
      `Checkpoint_seqno` int(10) unsigned NOT NULL,
      `Checkpoint_group_size` int(10) unsigned NOT NULL,
      `Checkpoint_group_bitmap` blob NOT NULL,
      `Channel_name` char(64) NOT NULL COMMENT 'The channel on which the slave is connected to a source. Used in Multisource Replication',
      PRIMARY KEY (`Channel_name`,`Id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Worker Information'
    1 row in set (0.00 sec)
    这个表用来存储每一个线程的执行情况,有多少个线程,就有多少条记:

    Relay_log_name:存储挡墙线程最新执行到的从库relay_log的文件名。

    Relay_log_pos:存储当前线程罪行执行到的上面文件中的位置。

    Master_log_name:存储当前线程最新执行到的主库master log的文件名。

    Master_log_pos:存储当前线程最新执行到的上面文件中的位置。

    Checkpoint_relay_log_name:存储当前线程最新的检查点的从库relay log的文件名。

    Checkpoint_relay_log_pos:存储当前线程最新执行到的上面温江中的位置。

    Checkpoint_master_log_name存储当前线程最新检查点的主库masterlog文件名。

    Checkpoint_master_log_pos:存储当前线程最新执行到的上面的文件中的位置。

    Checkpoint_seqno:分配给当前最新执行事务,这时相对于当前线程最新的检查点而言的。

    Checkpoint_group_size:用来存储最大的执行队列长度,当执行线程的队列达到这个长度时,必须做一次检查点。

    Checkpoint_group_bitmap:用来存储在当前线程最新检查点的上下文环境里,这个线程已经执行的事务,是一个位图值,这是用来恢复数据库的一个关键值。

    Channel_name:多源复制时使用。

     

     

    每个线程在执行玩一个事务之后,会把执行星系写入到slave_worker_info表中。到那时CAQ队列长度是有限的,不可能一直增长下去,所以必须在这个队列中,找到一个位置,这个位置事物CAQ的起点,并且之前的binlog都是已经执行过的,而这个过程,就被称作,检查点。那么多线程复制就可以归结为:检查点在CAQ中周而复始地向前推进复制位置,每个线程在不断地APPLY binlog,并且通过checkpoint_group_bitmap记录已经执行的事务与最新检查点的相对位置。

     

    从库crash之后如何恢复复制?而在恢复时,系统首先要做的就是把slave_master_info,slave_relay_log_info及slave_worker_info表中的内容读出来,找到连接主库的信息(slave_master_info),然后在找到复制位置及线程个数(slave_relay_log_info),然后在找到每一个线程的复制信息(slave_worker_info)等,读取完毕后就可以开始恢复了。

    从slave_relay_log_info读出来的位置,就是系统整体最新检查点的位置。这个位置以前的每个事物肯定都已经复制完成了,那么恢复也从这个位置开始。因为从这个位置开始,后面的有些事物已经执行,有写还没有执行。

    恢复的过程是按照不同线程诸葛分析的过程。首先如果线程最新的执行位置落后于最新检查点的位置,那么这个线程就不需要恢复了,因为这个线程执行的所有事务都是完整的,做完这层过滤之后,就分别对剩下的线程做恢复检查。

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 首先介绍几个概念:REDO 为了重做对数据页(page)更改保存的信息,用于恢复UNDO 为了撤销对数据记录(tuple)更改保存的信息,用于回滚事务LSN(Log Sequence NO) 日志号,一个递增的64位整数,一个LSN表示一个(redo)Log...

    首先介绍几个概念:

    REDO 为了重做对数据页(page)更改保存的信息,用于恢复

    UNDO 为了撤销对数据记录(tuple)更改保存的信息,用于回滚事务

    LSN(Log Sequence NO) 日志号,一个递增的64位整数,一个LSN表示一个(redo)Log结构。

    CHECKPOINT表示一个时间点,在CHECKPOINT LSN之前的更改都已经保存到了持久存储。恢复时只需从最后一个CHECKPOINT LSN开始。

    下面从update, commit, recovery三个方面简单说明:

    update(Insert与之类似)

    1.计算更新后tuple到原tuple的delta信息,把这个delta复制到rollback segment中的undo

    2.写redo log,记录对rollback segment的更改

    3.把buffer pool中的对应tuple更新成新值,把新值的rollback pointer写入undo log

    4.写redo log,记入对页(page)的更改

    5.将页状态改成dirty

    commit

    force log, flush当前事务的redo log

    recovery

    1.启动开始时检测是否发生崩溃

    2.定位到最近的一个checkpoint

    3.定位在这个checkpoint时flush到磁盘的数据页,检查checksum。如果不正确,说明这个页在上次写入是不完整的,从doublewrite buffer里把正确的页读出来,更新到buffer中的页

    4.分析redo log,标识出未提交事务

    5.顺序执行redo

    6.rollback未提交的事务

    以上是我个人的一些简单总结,具体细节的可以参考:

    Jeremy Cole的InnoDB: A journey to the core

    展开全文
  • 如题,不需要介绍这两者的区别,我比较好奇这两者在宕机恢复时各自的作用? 感觉宕机恢复只需要binlog就可以了?那redolog有什么用呢?
  • 该参数取值为0、1、20 代表党MySql关闭时,InnoDB需要完成所有的full purge 和 merge insert buffer操作,这会需要一些时间。1 代表不需要完成上述的full purge ,merge insert buffer操作,但是在缓冲池的一些数据脏...
  • Mysql数据库宕机恢复mysql增量恢复必备条件:*开启mysqllog-bin日志功能mysql数据库开启了log-bin参数记录binlog日志功能如下:[root@wikiDB~]# grep log-bin /data/3306/my.cnflog-bin= /data/330...
  • mysql主从宕机恢复步骤

    千次阅读 2020-08-21 20:27:46
    mysql主从宕机恢复步骤 在生产环境中经常会出现slave出现错误,从而发生主从同步故障,此时就需要人工干预了。以下是小生整理出的一个回复思路,欢迎大佬指导,分享更好的方法。 宕机恢复分为几种情况: 1.从库数据...
  • 1. 指定恢复时间对于MySQL 4.1.4,可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明,假设在今天上午10:00(今天是2005年4月20日),执行SQL语句来删除一个大表。要想...
  • mysql5.7数据安装目录是C:\ProgramData\MySQL\MySQL Server 5.7\Data,将要恢复的数据库和ibdata1复制运行良好的数据库上下面,重启mysql就可以恢复数据了。如图所示
  • Mysql数据库宕机恢复mysql增量恢复必备条件:*开WIKI提示:如果有多个库,此时:2)恢复凌晨全备开始恢复,先回复凌晨全备,然后恢复整备到出问题时的所有增量数据。解压全备文件[root@lampbackup]# gzip -d mysql_...
  • 问题:服务器宕机之后数据库无法启动(数据库文件损坏,非正常重启导致的文件损坏)描述:数据库是mycat+mysql的读写分离集群解决方式寻找问题的过程服务器宕机了之后,重启全部的mysql,mycat,keepalived,haproxy。...
  • Mysql主从架构-主库宕机如何恢复业务一、Mysql主库宕机情况分类:1)硬件问题,(服务器、ecs、虚拟主机等等)宕机2)service问题,Mysql宕机,服务异常,端口异常等二、硬件问题处理思路硬件问题我们可以查看IDC巡检...
  • 在我们日常工作场景,首先要做到架构...----MySQL 主从同步原理图一、Mysql主库宕机情况分类:1)硬件问题,(服务器、ecs、虚拟主机等等)宕机2)service问题,Mysql宕机,服务异常,端口异常等二、硬件问题处理思路硬...
  • WIKI系统宕机恢复:由于...Mysql数据库宕机恢复mysql增量恢复必备条件:*开启mysqllog-bin日志功能mysql数据库开启了log-bin参数记录binlog日志功能如下:[root@wikiDB~]# grep log-bin /data/3306/my.cnf log-bi...
  • https://serverfault.com/questions/698038/mysql-innodb-recovery-from-datafileshttps://serverfault.com/questions/851342/mysql-crashed-and-not-starting-even-after-adding-innodb-force-recoveryhttps://stac...
  • 在我们日常工作场景,首先要做到架构...----MySQL 主从同步原理图一、Mysql主库宕机情况分类:1)硬件问题,(服务器、ecs、虚拟主机等等)宕机2)service问题,Mysql宕机,服务异常,端口异常等二、硬件问题处理思路硬...
  • 事件起始某夜,我正在床上冥想准备入睡,忽然同事向我求救:消息内容如下:Oh My Gold 改了些配置,啥都没了!...修复过程我们数据库用的版本是 MySQL5.7 ,放置在Linux服务器上,在my.cnf 配置了数据库物...
  • 一、mysql group replication 生来就要面对两个问题:一、主节点宕机如何恢复。二、多数节点离线的情况下、余下节点如何继续承载业务。在这里我们只讨论第一个问题、也就是说当主结点宕机之后、我们怎么把它从新加入...
  • mysql8宕机恢复

    2020-11-04 10:21:25
    mysql8宕机恢复先备份方案1:强制启动(Forcing InnoDB Recovery)方案2:恢复模式启动重新初始化mysql 先备份 方案1:强制启动(Forcing InnoDB Recovery) 在 /etc/my.cnf中添加如下配置 [mysqld] innodb_force_...
  • 首先介绍几个概念:REDO 为了重做对数据页(page)更改保存的信息,用于恢复UNDO 为了撤销对数据记录(tuple)更改保存的信息,用于回滚事务LSN(Log Sequence NO) 日志号,一个递增的64位整数,一个LSN表示一个(redo)Log...
  •  一、主节点宕机如何恢复。  二、多数节点离线的情况下、余下节点如何继续承载业务。  在这里我们只讨论第一个问题、也就是说当主结点宕机之后、我们怎么把它从新加入到高可用集群中去。这个问题又可以细分成...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 649
精华内容 259
关键字:

mysql宕机恢复

mysql 订阅