二十个不可不知的 TSM 知识点(二)

9TSM存储介质中存储池和库有什么区别呢?

库在TSM里的物理对应就是机械手

池是个逻辑概念,可以由不同的介质类型构成,比如文件、lto等等。可以通过设备类指定。

存储池再和副本组中的dest参数关联。对应到不同的策略域

这样就形成闭环了。

10、使用TSM备份Oracle,怎么设置通道会比较好?

通道数越多,对数据库业务影响越大,对数据库的并发读性能要求越高,但如果通道数越多而通过单个通道内备份的data file越少、数据量越小,反而会降低备份效率。备份最终是要落入磁带库的,对于磁带机而言,连续且大量的数据写入效率是最高的。至于怎么平衡,取决于备份管理员对这个系统数据库和备份的理解了。

下面是ORACLE备份通道与消重效率的心得分享:

不管是哪一款备份软件,对备份数据备份流程的控制尤其重要,特别是采用消重技术的备份。对备份数据的控制效用将直接影响消重性能。消重技术以变长、定长两种为例,顾名思义变长是可以根据数据长度动态调整切片长度(如EMC DataDomain),定长仅仅是以固定长度对数据进行切片。切片完成后,片(piece)的命中率直接决定消重性能。piece的命中率越高,消重越明显。因此如何控制备份片(backup piece)单一度且相似度成为重点。

我们知道Oracle的Rman脚本里,有一个fileperset参数来控制每一个backup piece里会包含多少个data file。设想一下,如果fileperset越高,那每个backup piece就会包含更多的data file,backup piece的杂糅度就会越高(data file会被混乱随机的组成一个backup piece,并不是每次都按照同一个顺序拟成),那么消重切片后piece的重复率必然低。综合分析,一个合理的fileperset值将有效提升消重效率,fileperset越小越好,理论为1最好(如果没有多路复用的情况,一个流会话会占用一个备份设备)。

接下来关注备份通道数,Oracle的备份效率与数据结构类型、数据大小以及备份配置等息息相关。如何合理规划备份通道数?关于此问题,我们需要了解一个概念——多路复用(multiplexing)。这个功能能够让多个oracle channel的备份流写入一个磁带机,如rman里分配了四个通道,但备份只有一个磁带机在跑。对于单个磁带机来讲,连续、大量的数据流具有更高的写入效率,如果单个backup piece数据量偏小就需要适当提高multiplexing的复用效率:允许x个会话同时写入该设备(此操作提高数据杂糅度会降低后端消重效率)。对于Oracle而言,如果数据库性能允许,更多的channel会带来更高的数据读取效率,备份速度越快。然而考虑到备份对业务的影响以及并发性能的限制,最佳的通道数需要多次调整尝试。

除此之外若是oracle的消重备份,如果设置rman读取datafile时的读取块大小以及备份软件写数据的块大小以及设备消重的最小长度呈倍数关系,在消重效率和备份速率上都会有一定提升。

11TSM备份和恢复在Oracle Rac下的具体操作是怎样的?两个节点都有问题的恢复吗?

TSM for oracle的模块所起的作用,简单理解仅仅是提供了备份恢复的通道而已。所以在处理这个问题的时候先不要被tsm迷惑,仅从单纯的oracle rman角度去考虑即可。

实践上,rac环境的备份恢复仅在一个节点做就可以了,操作步骤基本上和单机环境没什么区别。

唯一需要考虑的一点就是rac环境下两边日志是存储在共享存储还是两边各是个的,要确保备份恢复的动作可以同时获取两个节点的归档信息,其他就没啥区别了。

12TSM备份失败可能的原因?如何处理?

备份软件的日志一般是第一手判断问题的重点。多数成熟的备份软件都会有详细的日志来说明相关的错误。

其次就是确认备份的环境、网络、系统状态、备份服务这些。

很多原因都会导致tsm备份失败,查找原因需要看日志——

查看一小时以前的所有日志:

query actlog

如查看昨天8点以后的所有日志

query actlog begindate=today-1 begintime=08:00:00

查看日志中有关nc_ora节点的相关信息,可以加上search参数

query actlog search=nc_ora

查看TSM服务器中的日志信息:

query actlog originator=server

数据库:api的log,tsmserver的log

文件:ba的log,tsmserver的log

RC 106,一般是日志权限的问题,找到需要的日志,加上权限。

RC 12,介质mount不可用,一般是TSM调用带库的时候出现问题,查查驱动器和path,看看存储池的最大可用scratch数值;如果是磁盘,看看磁盘的文件系统权限。

第一次启动调度的时候,如果调度进程未启动,可能是因为password生成参数没设置好,或者没有手动的登录一下客户端。

ANS0102W,语言包的问题导致dsmc登录不了,将/opt/tivoli/tsm/client/lang/en_US目录内所有内容,拷贝到/opt/tivoli/tsm/client/ba/bin目录下试试。

ORA-19554,动态链接库的问题可能大些。

如果日志表述无法直接定位问题,那么需要分析该问题是服务器端还是client端的问题,如果其他备份作业成功完成,那么备份服务器基本判断可用;之后看存储池,发起测试备份写入该存储池,如果可行则存储介质基本判断可用,带库路径驱动器路径可用;如果是数据库备份,则尝试发起文件备份,如果文件备份成功,那么基本判断是该节点的数据库备份问题,那么可以尝试重新执行配置,和检查配置文件的方式,判断问题。

阅读更多

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

今天在使用冷备份文件重做从库时遇到一个报错,值得研究一下。

版本:MySQL5.6.27

一、报错现象

dba:(none)> start slave;

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

这个时候查看error.log:

2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log ‘./tjtx-96-67-relay-bin.017814’ (relay_log_pos 172582079).

2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file ‘./tjtx135-1-95-relay-bin.index’ during relay log initialization.

2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure

2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.

2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events

2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections.

Version: ‘5.6.27-log’  socket: ‘/tmp/mysql.sock’  port: 3306  MySQL Community Server (GPL)

2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872

从报错上看,意思是启动slave时,使用repository中信息初始化relay log结构失败。为什么失败?原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里,答案就很清楚,由于我使用的是冷备份文件恢复的实例,在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息,所以导致启动slave报错。

那如何解决呢?先来简单的解MySQL Relay log的基础知识:

二、MySQL Relay log介绍

在MySQL复制结构下,Slave服务器会产生三种日志文件,用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。

1、relay log 文件:由IO thread线程从主库读取的二进制日志事件组成,该日志被Slave上的SQL thread线程执行,从而实现数据的复制。

2、master info log:该文件保存slave连接master的状态以及配置信息,如用户名,密码,日志执行的位置等。在5.6版本之前,都是使用master.info文件,从5.6开始,通过在my.cnf  中配置 –master-info-repository=TABLE。这些信息会被写入mysql.slave_master_info 表中,代替原来的master.info文件。

3、relay log info log:该文件保存slave上relay log的执行位置。在5.6版本之前,都是使用relay-log.info文件,从5.6开始,通过在my.cnf中配置 –relay-log-info-repository=TABLE,使用mysql.slave_relay_log_info表代替原来的文件。每次当slave上执行start slave时,就会读取该表中的位置信息。

新版本使用表来代替原来的文件,主要为crash-safe replication,从而大大提高从库的可靠性。为保证意外情况下从库的可靠性,mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表,从5.6.6起,这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎,可用下面语句进行转换:

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;

ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;

【注意】不要试图手工的更新、插入、删除以上两个表的内容,以免出现意料不到的问题。

三、问题解决

通过上面的报错以及relay log介绍,很容易知道由于mysql.slave_relay_log_info表中保留以前的复制信息,导致新从库启动时无法找到对应文件,那么我们清理掉该表中的记录不就可以。再次提醒,不要手动删该表数据,MySQL已经提供工具给我们:reset slave:

reset slave干的那些事:

1、删除slave_master_info ,slave_relay_log_info两个表中数据;

2、删除所有relay log文件,并重新创建新的relay log文件;

3、不会改变gtid_executed 或者 gtid_purged的值

下面解决问题:

dba:(none)> reset slave;

Query OK, 0 rows affected (0.00 sec)

dba:(none)> change master to ……

 

dba:(none)> start slave;

Query OK, 0 rows affected (0.00 sec)

到这里问题解决。

【经验】:以后用冷备份恢复实例后,在启动slave前,先进行reset slave清空下以前的旧信息。