张裕 发表于 2024-8-6 15:01:22

在业务高峰期拔掉服务器电源是一种怎样的体验?

/usr/local/mysql/bin/mysqld/usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x4d8)
/lib64/libc.so.6(__libc_start_main+0xfd)
/usr/local/mysql/bin/mysqldThe manual page at
http://dev.mysql.com/doc/mysql/en/crashing.html containsinformation that should help you find out
what is causing the crash.161108 23:36:46 mysqld_safe mysqld from pid file
/usr/local/mysql/var/VM_241_49_centos.pid
ended------------------------------------------------------------------------------
主库问题分析

从日记中可以看出是innodb引擎出了问题。日记里提示到 http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html查看强制规复的方法。在mysql的设置文件my.cnf里找到 字段下,添加 innodb_force_recovery=1:
innodb_force_recovery = 1
假如innodb_force_recovery = 1不生效,则可实行2——6几个数字
然后重启mysql,重启乐成。然后利用mysqldump或 pma 导出数据,执行修复操作等。修复完成后,把该参数注释掉,还原默认值0。
设置文件的参数:innodb_force_recovery
innodb_force_recovery影响整个InnoDB存储引擎的规复状态。默认为0,表现当需要规复时执行所有的规复操作(即校验数据页/purge undo/insert buffer merge/rolling back&forward),当不能进行有用的规复操作时,mysql有可能无法启动,并记载错误日记;
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update大概delete这类操作是不允许的。


[*] (SRV_FORCE_IGNORE_CORRUPT):忽略查抄到的corrupt页。
[*] (SRV_FORCE_NO_BACKGROUND):制止主线程的运行,如主线程需要执行full purge操作,会导致crash。
[*] (SRV_FORCE_NO_TRX_UNDO):不执行事件回滚操作。
[*] (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
[*] (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日记,InnoDB存储引擎会将未提交的事件视为已提交。
[*] (SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
主库解决方案

一般修复方法参考:
第一种方法
创建一张新表:
create table demo_bak #和原表布局一样,只是把INNODB改成了MYISAM。
把数据导进去
insert into demo_bak select * from demo;
删除掉原表:
drop table demo;
注释掉 innodb_force_recovery 之后,重启。
重定名:
rename table demo_bak to demo;
最后改回存储引擎:
alter table demo engine = innodb
第二种方法
另一个方法是利用mysqldump将表格导出,然后再导回到InnoDB表中。这两种方法的结果是雷同的。
备份导出(包括布局和数据):
mysqldump -uroot -p123 test > test.sql
还原方法1:
use test;source test.sql
还原方法2(系统命令行):
mysql -uroot -p123 test < test.sql;
注意,CHECK TABLE命令在InnoDB数据库中根本上是没有用的。
第三种方法
(1)设置my.cnf
设置innodb_force_recovery = 1或2——6几个数字,重启MySQL
(2)导出数据脚本
mysqldump -uroot -p123 test > test.sql
导出SQL脚本。大概用Navicat将所有数据库/表导入到其他服务器的数据库中。
注意:这里的数据肯定要备份乐成。然后删除原数据库中的数据。
(3)删除ib_logfile0、ib_logfile1、ibdata1
备份MySQL数据目录下的ib_logfile0、ib_logfile1、ibdata1三个文件,然后将这三个文件删除
(4)设置my.cnf
将my.cnf中innodb_force_recovery = 1或2——6几个数字这行设置删除大概设置为innodb_force_recovery = 0,重启MySQL服务
(5)将数据导入MySQL数据库
mysql -uroot -p123 test < test.sql; 大概用Navicat将备份的数据导入到数据库中。
此种方法下要注意的问题:


[*] ib_logfile0、ib_logfile1、ibdata1这三个文件肯定要先备份后删除;
[*] 肯定要确认原数据导出乐成了
[*] 当数据导出乐成后,删除原数据库中的数据时,假如提示不能删除,可在命令行进入MySQL的数据目录,手动删除相关数据库的文件夹大概数据库文件夹下的数据表文件,条件是数据肯定导出或备份乐成。
这里,我利用的是第三种方法规复了主数据库的数据。
接下来,我们再来看看从数据库数据的规复。
解决从库问题
主从复制原理

这里,我就简朴的说下MySQL数据库的主从复制原理。
MySQL主从复制原理,也称为A/B原理。
(1) Master 将数据改变记载到二进制日记(binary log)中,也就是设置文件 log-bin 指定的文件, 这些记载叫做二进制日记事件(binary log events);
(2) Slave 通过 I/O 线程读取 Master 中的 binary log events 并写入到它的中继日记(relay log);
(3) Slave 重做中继日记中的事件,把中继日记中的事件信息一条一条的在本地执行一次,完 成数据在本地的存储,从而实现将改变反映到它本身的数据(数据重放)。
https://img-blog.csdnimg.cn/20210302192724956.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0,size_16,color_FFFFFF,t_70#pic_center
复制过滤可以让你只复制服务器中的一部分数据,有两种复制过滤:
(1) 在 Master 上过滤二进制日记中的事件;
(2) 在 Slave 上过滤中继日记中的事件。如下:
https://img-blog.csdnimg.cn/2021030219273920.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0,size_16,color_FFFFFF,t_70#pic_center
relay_log设置中继日记,log_slave_updates表现slave将复制事件 写进本身的二进制日记.当设置log_slave_updates时,你可以让slave饰演其它slave的master.此时,slave把sql线程执行的事件写进本身的二进制日记(binary log)然后,它的slave可以获取这些事件并执行它。如下图所示(发送复制事件到其它的Slave):
https://img-blog.csdnimg.cn/2021030219274925.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0,size_16,color_FFFFFF,t_70#pic_center
从库问题重现

规复主库的数据后,向主库中插入了一批测试数据,大概有1000条,但是插入数据后,从库迟迟没有将数据同步过来。于是我先登录主库,执行如下命令。
mysql>show processlist;
查看下进程是否Sleep太多。发现很正常。
再查看下主库的状态。
show master status;
也正常。
mysql> show master status;
±------------------±---------±-------------±------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
±------------------±---------±-------------±------------------------------+
| mysqld-bin.000001 | 3260 | | mysql,test,information_schema |
±------------------±---------±-------------±------------------------------+
1 row in set (0.00 sec)
再到从库上查看从库的状态。
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
发现是Slave差别步了。这里,假如主从数据库版本一致或不一致又会存在两种解决方案。
主从版本一致解决方案

下面先容两种解决方法
方法一:忽略错误后,继承同步
该方法适用于主从库数据相差不大,大概要求数据可以不完全统一的情况,数据要求不严格的情况
解决:
stop slave;
#表现跳过一步错误,后面的数字可变
set global sql_slave_skip_counter =1;
start slave;
之后再用mysql> show slave status\G 查看
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
ok,现在主从同步状态正常了。。。
方式二:重新做主从,完全同步
该方法适用于主从库数据相差较大,大概要求数据完全统一的情况
解决步骤如下:
(1)先辈入主库,进行锁表,防止数据写入
利用命令:
mysql> flush tables with read lock;
注意:该处是锁定为只读状态,语句不区分巨细写
(2)进行数据备份
#把数据备份到mysql.bak.sql文件
mysqldump -uroot -p -hlocalhost > mysql.bak.sql
总结

机会是留给有准备的人,各人在求职之前应该要明确本身的态度,熟悉求职流程,做好充分的准备,把一些可预见的事故做好。
对于应届结业生来说,校招更得当你们,因为绝大部分都不会有工作经验,企业也不会有工作经验的需求。同时,你也不需要伪造高大上的实战经验,以此让本身的简历可以大概脱颖而出,反倒会让面试官有所怀疑。
你在大学时期应该明确本身的发展方向,假如你在大一就确定你以后想成为Java工程师,那就不要花太多的时间去学习其他的技术语言,高数之类的,不如好好想着怎样夯实Java底子。下图涵盖了应届生乃至转行过来的小白要学习的Java内容:
请转发本文支持一下
https://img-blog.csdnimg.cn/img_convert/807720532b162722a4976f859316e82f.webp?x-oss-process=image/format,png
https://img-blog.csdnimg.cn/img_convert/367038f6c5fe7c690ad3156867dee9d3.webp?x-oss-process=image/format,png
s with read lock;
注意:该处是锁定为只读状态,语句不区分巨细写
(2)进行数据备份
#把数据备份到mysql.bak.sql文件
mysqldump -uroot -p -hlocalhost > mysql.bak.sql
总结

机会是留给有准备的人,各人在求职之前应该要明确本身的态度,熟悉求职流程,做好充分的准备,把一些可预见的事故做好。
对于应届结业生来说,校招更得当你们,因为绝大部分都不会有工作经验,企业也不会有工作经验的需求。同时,你也不需要伪造高大上的实战经验,以此让本身的简历可以大概脱颖而出,反倒会让面试官有所怀疑。
你在大学时期应该明确本身的发展方向,假如你在大一就确定你以后想成为Java工程师,那就不要花太多的时间去学习其他的技术语言,高数之类的,不如好好想着怎样夯实Java底子。下图涵盖了应届生乃至转行过来的小白要学习的Java内容:
请转发本文支持一下
[外链图片转存中…(img-fYL1GNAj-1721835837322)]
[外链图片转存中…(img-7FiNFjnT-1721835837323)]

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: 在业务高峰期拔掉服务器电源是一种怎样的体验?