使用主流的监控工具 如zabbix和 Promethus 已经对部分数据库做了适配和兼容,不过整体监控内容不是很多,指标也不是那么全面。很多还是需要自定义脚本。如达梦、mog等
很多是支持单向迁移的,问题是否前期做好整体的评估。迁移的话场景基本上都是有工具和办法的,回来就不好说了。
很多数据库都是基于外围开源产品进行的定制或者二开,其原始支持的方式由于其生态没有成熟,导致后期的二开产品支持的备份场景也不是很成熟,尤其是和备份软件的兼容性,是个漫长的过程。
因为不涉及硬件的监控 ,OS+容器 prometheus 作为趋势和整体方案更为合理些。目前zabbix监控k8s成熟度还有待提高。
删除rmt0 ,重新识别一下,如果新识别到的sn 和磁带库的sn 一样的就OK,TSM里更新一下对应path,基本上就OK了
很难有最后的赢家,本来就是针对不同场景的解决方案。一个产品的出现不是为了替换一个产品,更多的弥补或者互补,均有各自的优缺点。 如果必须要说谁发展的更好,那就看是容器发展的市场大还是虚拟机或者其他的场景是否还存
copy pool 满了,或者空间紧张了。提示很明显。
监控的多,其实并不可怕,主要看还是遇到了什么问题,无外乎io,io还是io问题1. 调整架构,采样周期,主被动模式,缓存参数,超时参数,进程数量等等,2.其实很多时候有立竿见影效果的就是弄一块好的磁盘,一般企业来说监控数据不会存放太
最好运维的头等大事可以说是监控了,没有监控犹如人无双眼,那是不是说有监控就能万事大吉了呢,显示不是。大量的无效告警,重复告警,如果不能很好的设置规则,那么监控给你带来的烦恼也是问题诸多,反而会拖累整体运维工作。 不
我来把这个问题给总结一下,目前已经找到了问题。主要问题是因为这个参数引起的,有Linux经验的同学一看就知道是用于什么方面的。 vm.dirty_bytes 目前读可以到4个g,写在2-3个g左右,还是不错的。 多谢各位。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30