当年悟空学艺于菩提祖师门下,老师遣他下山,悟空觉得自己蒙受师傅传授大恩,还没有报答。菩提祖师就说:不要提什么报答之恩,只要你日后闯出祸来不把为师说出来就行了。
我听说过挺多删库的事件,于是开玩笑的略改一下:“日后你删了库后,不要把师傅说出来就行了”,不知道那些删库的工程师们,其师傅有没有交代过这句话,emmm。。。
话说日后,孙悟空真的删过一个数据库里的记录,这就是:生死薄。
孙悟空寿命只有342岁,在大闹地府那天其实阳寿已尽,在原著中曾这样写道:
“悟空亲自检阅,直到那魂字一千三百五十号上,方注着孙悟空名字,乃天产石猴,该寿三百四十二岁,善终。”
孙悟空哪能受得了这个,拿起生死簿把自己的名字就划了,不仅如此,他也不能让自己的猴子猴孙也经历生老病死,便顺手把生死簿中所有的猴子都给划掉了。
所以问题来了:
生死簿,这个庞大的数据库系统,如果没有灾备,没有备份,只有当前态,其数据就被永久的改变了。无可挽回。
从表象来看,生死薄是一个平板文件的日志记录,但是事实上并非如此,这内部一定是一个庞大而复杂的数据库系统,其中:
要存储所有生灵的出生寿元; 要存储所有生灵的善恶功德; 要存储所有的前世今生循环; 要存储所有生灵的关系关联; 要高并发高吞吐全宇宙联网;
大家想想这个数据结构要怎么设计?
数据量实在太大,分库分表分布式,这是少不了的; 主键唯一如何规划? 前世今生生生不息,关系网实在复杂; 天灾人祸批量处理高并发; 前车之鉴,容灾备份高可用必须要有?
太复杂了,还是作为面试题,找几个人问问,或者招个标搞个方案吧!
投标应标咱不管了,可是删除了数据库怎么办?
等传票?拿护照?跑路去?nonono !以 MySQL 为例,这里对删库语句做下分类:
1. 使用 delete 语句误删数据行,通过闪回 +binlog 可以找回;
2. 使用 drop table/database 或者 truncate table 语句误删数据库/表,通过全量数据定期备份 +binlog 可以找回;
3. 使用 rm -rf 命令误删整个 MySQL 实例,只要还有备份节点就可以找回。
一分钟系列的文章,篇幅有限,这里只简单介绍下采取什么补救措施,不写详细内容,想看详细的文章,可以在下方或后台给我留言。
操作需谨慎,删库别跑路!