摘要: 1、mysiam表进行锁表,保证备份一致性 2、innodb表进行了redo log的保留,可以将备份恢复到备份结束的时刻,这个时刻的备份能够保障数据的一致性 3、info文件中记录了binlog恢复的起点,可以参考info文件进行binlog恢复 1、 innobackupex --user=ro 阅读全文
posted @ 2019-07-29 20:00 Tech_Shrimp 阅读(135) 评论(0) 推荐(0) 编辑
摘要: 我们一般采用mysqldump的方式,对于mysql dump,有两种备份方式,一种是形成恢复脚本,这个是默认的备份方式,还有就是生成行数据文件,将来采用load data加载数据,后者速度更快,因此对于逻辑备份,我们建议采用后者,就是mysqldump -T的方式 1、mysqldump备份的时候 阅读全文
posted @ 2019-07-29 19:49 Tech_Shrimp 阅读(533) 评论(0) 推荐(0) 编辑
摘要: 1、开始写redo log往xtrabackup_log文件里(显示为 log scan up to) 2、复制ibd,ibdata 1、不加锁,不断往xtrabackup_log文件里写日志 3、对所有innodb和myisam加读锁,可能会hang住,会出现show tps=0、行锁超时等信息 阅读全文
posted @ 2019-07-29 19:48 Tech_Shrimp 阅读(310) 评论(0) 推荐(0) 编辑
摘要: 1、拷贝数据页 2、myisam表来说,通过锁来实现数据的一致性 3、innodb表来说,使用redolog来实现数据的一致性 4、备份期间的redolog、applylog(备份完成以后马上可以进行applylog)、rollback 5、物理备份需要能够读懂各种info文件 6、备份速度快、恢复 阅读全文
posted @ 2019-07-29 19:33 Tech_Shrimp 阅读(710) 评论(0) 推荐(0) 编辑
摘要: 阅读全文
posted @ 2019-07-29 19:25 Tech_Shrimp 阅读(87) 评论(0) 推荐(0) 编辑
摘要: 1、数据类型要合理 1、对于数字和日期类型,一般不要采用varchar类型,这个陷阱很容易被接受 1、容易带来隐式类型转换,导致索引失效,例如 where a=123; a是varchar列,实际存储数字类型值 2、容易带来数据质量的下降,例如日期类型 '2019-01-23'、'2019-23-0 阅读全文
posted @ 2019-07-29 19:14 Tech_Shrimp 阅读(369) 评论(0) 推荐(0) 编辑
摘要: 1、确认找到my.cnf,一般位于/etc/my.cnf,对于tar安装的情况,可能没有位于/etc/目录下面,可以找一下/usr/local以及参照公司目录规划 2、cat /etc/my.cnf这个文件 1、basedir,确认MySQL软件位于什么位置,cd进入相关的位置,看一下里面目录和文件 阅读全文
posted @ 2019-07-29 19:12 Tech_Shrimp 阅读(170) 评论(0) 推荐(0) 编辑
摘要: 重做日志(redo log)用来保证事务的持久性。实际上它可以分为以下两种类型:物理Redo日志、逻辑Redo日志;在InnoDB存储引擎中,大部分情况下Redo是物理日志,记录的是数据页的物理变化。而逻辑Redo日志,不是记录页面的实际修改,而是记录修改页面的一类操作,比如新建数据页时,需要记录逻 阅读全文
posted @ 2019-07-29 19:10 Tech_Shrimp 阅读(540) 评论(0) 推荐(0) 编辑
摘要: 1、rollback 1、一个事务开始,生成一个事务id(找事务counter) 2、读取系统事务表,找到一个回滚段(找相对空闲的),读取回滚段的段头块(段头里面有很多行,找到其中空闲的行,把事务id写进去,写进去之后一个事务就开始了,一个事务槽盛放一个事务id,也就是说一个事务开始了需要找到事务槽 阅读全文
posted @ 2019-07-29 19:08 Tech_Shrimp 阅读(639) 评论(0) 推荐(0) 编辑