专栏首页杨建荣的学习笔记最近处理的几个小问题_20160311 (r8笔记第35天)

最近处理的几个小问题_20160311 (r8笔记第35天)

最近处理的小问题很多,我就拿出来几个,简单和大家说一说。我就分为三个方面,硬件问题,Oracle表空间迁移,MySQL断电恢复 首先是硬件问题。 如果看到下面的系统日志,就会发现早在2014年就出现了一些警告和问题,随后看似已经修复了部分,但是实际情况是这台服务器的电源已经坏了一个,另外一 个已经快扛不住了。但是通过这些信息就很难读到之前的问题,因为问题已经过去了好久,一直没有问题,应该就是没有问题吧,或者之前的人已经处理了吧,如果 这样想,是一种乐观的方式。 最好还是做一些确认,我就是那么想的,然后在某一天一台备库的服务器就突然殉职了。究其原因就是电源问题。

打开系统的ILO界面,才突然发现只识别了一个电源,而且已经无法正常开启电源了。 对于这类问题,还有一个想法就是,机器过就过老,更新换代如此频繁,还是有好的硬件配置就用上,很多时候都是感觉舍不得,动不得,如果你要迁移某个服务 器,去和各个部门协调,总会有这个不能动,那个不能改的顾虑,但是服务器可不会讲这些情面,有时候**还是有道理的,这些问题也能够反应出来我们对待问题 的态度,都是被动接受,而不是主动改进。出了问题之后发现这些必须得动,必须得改,感觉那个时候就有些匆忙,仓促了。 然后第二个问题,是一个表空间的迁移问题。 之前帮助开发的同事处理了一个表空间无法扩展的小case,然后建议他们后续进行硬盘扩容,从根本上解决这个问题,开发同事还真听进去了,申请了一块较大的硬盘,但是还是希望我来帮助他们来迁移这个表空间,这个问题其实很简单。 可以使用常规的方法即可,唯一的不同在于这个表空间是个bigfile tablespace,所以心里还是存在一点小小的顾虑,是否对于能够100%成功。 因为这个表空间的设置,里面只有一个数据文件,新的磁盘分区在/data下面。 在迁移的时候,开发的同事还是希望能够在线迁移,从我的大量实践来说,这些也都不是大的问题,然后使用了下面的脚本。 alter tablespace CYTJ_DATA offline; !cp '/home/oracle/tablespace/cytj_data.dbf' '/data/cytj/datafile/cytj_data.dbf'; alter tablespace CYTJ_DATA rename datafile '/home/oracle/tablespace/cytj_data.dbf' to '/data/cytj/datafile/cytj_data.dbf'; alter tablespace CYTJ_DATA online; 当然拷贝大的文件,第二步花费了一些时间,其它步骤都是秒级完成。 迁移完了,还是有一些后续的补充工作的。 首先要删除原有的文件,再三确认之后,就可以删除了。 但是使用df -h发现,空间却压根没有释放,应该能够释放50多G才对。 #df -h Filesystem Size Used Avail Use% Mounted on /dev/sda5 4.0G 359M 3.4G 10% / /dev/sda11 106G 96G 5.5G 95% /home /dev/sdb1 551G 61G 463G 12% /data 对于这个问题,解决方法也比较简单,就是查看句柄的使用情况。 通过下面的命令可以看到迁移前和迁移后都存在一些句柄关联,哪些迁移前的文件已然被标示为deleted #lsof |grep cytj_data.dbf oracle 1536 oracle 263u REG 8,11 64424517632 2490413 /home/oracle/tablespace/cytj_data.dbf (deleted) oracle 5427 oracle 262uW REG 8,17 64424517632 31719427 /data/cytj/datafile/cytj_data.dbf oracle 5431 oracle 262u REG 8,17 64424517632 31719427 /data/cytj/datafile/cytj_data.dbf oracle 5433 oracle 260u REG 8,17 64424517632 31719427 /data/cytj/datafile/cytj_data.dbf oracle 6393 oracle 257u REG 8,17 64424517632 31719427 /data/cytj/datafile/cytj_data.dbf oracle 8729 oracle 257u REG 8,11 64424517632 2490413 /home/oracle/tablespace/cytj_data.dbf (deleted) oracle 8971 oracle 256u REG 8,11 64424517632 2490413 /home/oracle/tablespace/cytj_data.dbf (deleted) oracle 9358 oracle 256u REG 8,11 64424517632 2490413 /home/oracle/tablespace/cytj_data.dbf (deleted) 以其中的一个进程为例,发现是一个应用连接。 #ps -ef|grep 1536 oracle 1536 1 0 18:07 ? 00:00:00 oraclecytj (LOCAL=NO) root 6321 5715 0 22:48 pts/0 00:00:00 grep 1536 所以这些session还是对这个迁移造成了潜移默化的影响,我们需要释放这些句柄来,就可以kill掉了。 清理掉这些进程之后,再次查看就没有问题了。 #df -h Filesystem Size Used Avail Use% Mounted on /dev/sda11 106G 52G 50G 52% /home /dev/sdb1 551G 61G 463G 12% /data 问题解决完了,还需要注意什么呢,需要设置这个数据文件的maxsize,这个分区目前有500G左右,所以大可以放心把它置为500G以内。原来的maxsize值是50G,差的还很远呢。 第三个问题是关于MySQL的从库问题。 因为之前有一台服务器因为硬件问题掉电,在补充了新的电源之后又开始正常工作了,但是查看从库的状态发现显示为: > show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.127.0.91 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000226 Read_Master_Log_Pos: 506545322 Relay_Log_File: mysql-relay.000023 Relay_Log_Pos: 884805415 Relay_Master_Log_File: mysql-bin.000225 Slave_IO_Running: Yes Slave_SQL_Running: No Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's Skip_Counter: 0 Exec_Master_Log_Pos: 884805205 Relay_Log_Space: 1580224534 Last_SQL_Errno: 1594 Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's Master_Server_Id: 200 Master_UUID: 170281bc-1957-11e4-ad6e-842b2b4841e9 Master_Info_File: /U01/app/mysql_3306/master.info Slave_SQL_Running_State: Master_Retry_Count: 86400 对于这个问题,stop slave,start slave是不会自动修复的。 可以使用change master来修复。 > stop slave; Query OK, 0 rows affected (0.02 sec) 如果以前修复可以手工对应下标和日志来指定修复,但是在gtid的场景里,还是不需要这样了。 > change master to Master_Log_File='mysql-bin.000226', Master_Log_Pos=884805205; ERROR 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active. > change master to master_host='10.127.0.xxx',master_port =3306,master_user='repl',master_password='xxxx',master_auto_position=1; Query OK, 0 rows affected, 2 warnings (0.51 sec) 然后再次查看发现就开始缩小了日志差距,大概等了十几分钟之后,就追平了日志gap. 同一件事情总是会碰到这样许许多多的小问题,总是让人很操心,不过不总结不会进步啊。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:杨建荣

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-03-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 看似诡异的tablespace online问题(r5笔记第95天)

    今天在做一些演示的时候,在虚拟机上装了两套数据库软件,10g和11g的。还是在演示普通数据文件迁移的时候还是碰到了一些意料之外的问题,从当时的情况来看感觉还是比...

    jeanron100
  • MySQL修复表的简单分析(r11笔记第19天)

    今天有个同事问我一个数据库的问题,如果开始他就把环境细节全都告诉我,可能我就知难而退了。等我大体明白了问题之后,发现好像背景比我想的要复杂多了。这是一个远程云主...

    jeanron100
  • dataguard添加临时数据文件的bug(r7笔记第27天)

    有一个环境是10gR2,一主两备,因为10g的备库还不是active,所以有一些查询的需求的时候,我们还是会打开相应的窗口时间。 开发的同学需要做一个大查询,数...

    jeanron100
  • Python:base64图像数据处理

    弄啥嘞
  • R语言与生信系列①(R入门与临床三线表绘制)

    首次分享课讲的是TCGA数据分析,探究某一因素与肿瘤临床数据之间的关系,并自动生成可以用于SCI发表的三线表,如下图所示:

    用户1359560
  • Python中的相关分析correlation analysis

    相关分析(correlation analysis) 研究两个或两个以上随机变量之间相互依存关系的方向和密切程度的方法。 线性相关关系主要采用皮尔逊(Pears...

    Erin
  • 如何使用LVM快照将MySQL数据库备份到腾讯云COS

    定期数据库备份是防止意外数据丢失事件的关键步骤。设计有效的备份和恢复策略通常需要通过恢复速度,数据完整性和备份覆盖来权衡性能影响,实施成本和数据存储成本。最佳解...

    灬半痴
  • python中pandas库中DataFrame对行和列的操作使用方法示例

    最近处理数据时发现当pd.read_csv()数据时有时候会有读取到未命名的列,且该列也用不到,一般是索引列被换掉后导致的,有强迫症的看着难受,这时候dataf...

    砸漏
  • 原 如何在windows下手动初始化PostgreSQL数据库

    王果壳
  • 使用Python爬取COVID-19疫情数据

    新型冠状病毒感染的肺炎疫情爆发后,对人们的生活产生很大的影响。当前感染人数依然在不断变化。每天国家卫健委和各大新闻媒体都会公布疫情的数据,包括累计确诊人数、现有...

    数据酷客

扫码关注云+社区

领取腾讯云代金券