点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！ - 可以对表、索引、视图、序列进行迁移，平台新增数据校验模块暂未进行测试。
- ora2pg：第三方迁移工具，用于将Oracle数据库迁移到PostgreSQL数据库支持TABLE with constraints, VIEW, FUNCTION, PROCEDURE等类型的对象迁移到pg库。ora2pg通过配置参数，连接Oracle数据库，选择要导入的类型，扫描它自动提取其结构或数据，然后生成SQL可以加载到PostgreSQL数据库中的脚本。最后执行脚本导入到pg库。但是没有可视化的界面，配置较为繁琐。
1）mtk工具bug，web端显示的数据与真实迁移执行情况有偏差，表名带有$都无法参加mtk的同步任务，发布新版本后修复。2）用户之间可能存在依赖。mtk会在执行迁移任务中报错。梳理依赖关系重新执行迁移任务解决。3）涉及antdb保留字段的表，无法通过mtk进行同步。修改了oracle库有关字段名，规避了这个问题。4）mtk执行迁移任务时默认将源库对象名转化为小写，当存在某个对象名与表名相同但是大小写不同时，可能会导致表迁移失败。5）ora2pg的迁移中建议每次只执行一种对象的迁移。提前梳理对象之间的依赖关系，可以避免缺少依赖引起的导入失败。1）自带迁移工具不完善，不成熟，导致迁移效率低、问题多；整个数据迁移工作繁琐工作量大；整个迁移方案不够完整，考虑不够周全。导致在数据迁移时返工一次。影响效率。建议原厂进一步完善相关工具。2）没有完善自动迁移工具和给出详细的方案时慎重在生产库上实施。
应业务方需求在凌晨更改系统及数据库参数，在更改完参数重启集群时无法启动，后集群主备自动发生切换后，老主库依旧无法启动。1）首先检查数据库服务是否运行正常，磁盘是否正常，主机间互信是否正常，业务日志有无明显报错。2）检查cm_server、cm_agent等CM服务是否正常运行。3）发现集群内omm互访后出现read only等未识别命令，这个会影响集群命令的执行，后面经过排查发现是系统检测设置的/etc/bash_profile内容脚本导致的，经过在/home/omm/.bash_profile中注释掉全局.bash_profile生效语句规避此问题。4）放弃用cm命令启动数据库，用gs_ctl命令启动单节点查看具体报错，发现数据库主配置文件postgresql.conf文件内有未识别参数，遂定位位置，发现文件内出现了三处语法语句错误，导致数据库无法识别。5）屏蔽掉错误参数，并用gs_ctl启动数据库，数据库成功启动并恢复服务。1）建立错误排查记录文档，在出现故障后可以先寻找以往案例快速定位。2）在暂时无法找到具体问题情况下优先恢复业务，老主库随后再排查。3）在对数据库做改动前做好相关备份，保证回退方案。
1）patroni数据库集群主节点正常，从节点丢失（并未丢失数据）。4）用patronictl 查看集群状态Leader节点时有时无查看postgresql日志时有报错ERROR: unrecognized configuration parameter "primary_info"。经过分析etcd日志，明显的看到集群时间出错，用date查看集群时间发现ntp时间同步失败，导致集群节点时间不一致，最终导致集群崩溃，从而对外界造成集群的不可用。修复时间服务器，并配置时间同步，保证时间同步一致。严格按照官方集成建议进行集成，确保各节点时间一致。
三台mongo服务组成集群模式，其中1台CPU告警，发现仅cpu的us值负载高，其他值都很低，通过监控发现，高峰期比较规律，一般为每小时的前20分钟，之后峰值就自动下去恢复到正常状态，期间执行任何命令都很流畅。1）使用top和atop命令查看全部CPU使用情况，显示cpu的us值都有好几个cpu的us值100%，sy值却很低。进程依然看不到高负载。2）使用pidstat命令：pidstat ｜grep -E “PID｜mongo”，发现mongo进程的是us使用率很高。3）登录同集群的其他主机，执行相同的命令进行对比。4）对比结果可以明显看到正常主机的user值仅有0.1-1.3，而异常主机达到20000左右。收集和分析CPU、内存信息，比较不同时间段的数据，寻找规律，建议业务组调整计划任务时间、优化语句或扩容。
F5会话分布保持方式配置导致负载分配不均导致的业务影响。1）业务属性为redis中间件，微服务组件自搭建组件化服务，共6个服务节点；2）排查出现问题负载现配置策略情况；负载策略为轮询，会话保持方式主用cookie，候选为源地址；3）故障发生时只有单个业务员受到影响，其他用到组件间的都无此异常；4）问题出现时观察F5会话分配情况，组件化单节点会话分配特别高；1）此负载策略建立、使用2年，出现故障业务系统使用组件化1年左右，随着业务增长导致原存在隐患造成业务故障；2）在新创建负载时需了解负载的业务使用场景，建议选择最优的负载配置方式；3）后期注意负载使用的监控，及时发现隐患，及时解决。
某业务数据库有一套DG环境，主库做读写操作，备库做只读操作，业务的一个web功能连接的是备库，各地势人员在从页面进行查询时页面的响应速度特别慢，业务开发厂商拿执行的语句到主库执行发现速度很快，认为DG备库出现问题，需DBA解决。1）拿到业务给的SQL在主库执行，执行时间为0.8s。2）在DG备库检查正在执行的SQL，执行时间1000多秒，还未执行完，并且有100个左右的同类会话正在执行。3）检查主库和备库上的执行计划，发现执行计划有一处变化，使用的索引不一样，在主库上，其中一个表的索引使用“市”进行过滤，索引过滤6万行，在备库上这个表虽然也走索引，但是使用的是“省”这个条件，索引过滤63万行。这条SQL是用户在页面上进行条件筛选后执行，省和市都是其中的筛选条件，还有一些其他条件，并不固定，但省、市以及另外两个条件是常用的，省、市是必须的。在备库的执行计划中显示的city这个条件发生了隐式转换。此条件涉及的表有几千万行数据。4）检查备库执行的SQL发现，其中city的条件是city=城市编号，而该表中city列是varchar2类型，而业务给的SQL（在主库上执行的），city='城市编号'，是加了引号的。所以主库上执行索引选择了城市，而备库执行时由于隐式转换无法选择城市这个索引，选择了省份这个索引。5）前面说过，当一个索引不合适时，它扫描了更多的数据块，回表过滤了更多的行，可能产生较大的物理读，导致执行时间过长，同时，如果shared pool和db cache 不足，相互转换可能加剧物理读和SQL解析的问题，这套DG库也发生了内存抖动的问题，不过主要是由于这条SQL导致的，该SQL并发量多，导致过多的回表访问，读取了大量数据块。6）正确的SQL并不是没有问题，“城市”也并不是一个选择性很好的列，只不过相对于“省份”来说，要好很多，在主库执行时仅执行1次，也并没有其他会话同时执行造成的争用。前面说过，where条件中总共有4个条件是经常用到的，省和市是必选的，那么就可以通过联合索引的方式让数据尽量在索引中被过滤出来，减少回表次数，减少物理读，减少争用。原先的索引是省和市上各有一个单列索引，即使使用了市作为索引，也会造成多次回表过滤的情况。1）本次故障主要是由于存储底层迁移导致的，新旧存储的磁盘扇区大小不一致造成的，这就要求存储工程师在划分LUN的时候要严格检查旧盘的配置，而对于DBA来说，其实不好发现这种问题，因为迁移的过程中和迁移后，虽然磁盘扇区变化了，但是数据库并没有发生异常，也没有任何日志记录了这种变化，只有发生集群重启时才报错。但是当发生问题后，必须要通过现象找到方向。2）传统的磁盘扇区是512字节，每个扇区之间不是直接相连的，存在一定的空间，这些空间用于分隔扇区、同步、地址标志和ECC区域（用于数据修复和还原），随着硬盘技术的发展，单盘容量不断增加，这种扇区结构就会导致浪费大量的磁盘空间，同时故障修复的时间也会增加，硬盘厂商自2010年左右，推出了可以支持更高效率的4096字节扇区的硬盘，同时，为了和以前的硬件和操作系统兼容，设置了512字节的逻辑扇区。硬盘的格式有三种，物理和逻辑扇区均为512字节（512n)，物理扇区4096字节，逻辑扇区512字节（512e），以及物理和逻辑扇区均为4096字节（4kn）。
某业务系统两节点11204版本RAC数据库活动会话数达到800以上，业务卡顿，数据库主机负载较高，CPU使用率90%以上，前端应用基本无法使用。很多查询语句执行时间较长，存在阻塞，kill掉这些SQL后，业务恢复，但很快活动会话数又会升高。1）数据库主机只运行oracle数据库，无其他程序。2）分析执行的SQL，发现基本上等待全是gc相关的，连接串使用的SCAN。3）检查两个节点之间的私网使用情况，心跳网卡存在丢包、错包的情况。4）根据对CPU使用率的排查，物理CPU为两个，逻辑CPU为32个。每个网卡有8个队列，请求逻辑CPU，当出现业务卡顿，活动会话数升高的时候，部分逻辑CPU被跑满，无法处理私网网卡发起的中断请求。CPU的用户态使用率在40%左右，内核态使用率在40%-50%，可能与严重的gc等待有一定的关系。初步判断私网之间硬件有问题导致数据块传输慢。5）网卡绑定模式为mode0,轮询模式，一个包走1卡，下一个包走2卡，oracle只推荐主备，不推荐其他模式。轮询可能造成数据包经过不同的设备无序到达后重组的问题，可能造成性能下降。为保证业务连续性，先停止2节点的数据库集群，避免负载均衡造成的gc问题。
更换交换机的光模块，光纤线，增加网卡队列大小，MTU值等方法，消除了私网丢包、错包的问题。
此时，1个节点运行，业务没有问题，gc等待消失，但是1节点的CPU内核态使用率仍高达40%-50%，而一旦第2个节点的集群启动，活动会话数还是会缓慢升高，最终导致业务卡顿或完全无法访问，就是时间稍微长一些，也就是说有一点缓解，但是还不够。只使用一个节点无法满足高可用，甲方的领导也不接受使用VIP并且不使用负载均衡的方案。
网卡绑定模式无法更改，机房的架构导致的，一部分是mode0，一部分是mode2（基于hash策略的负载均衡）。
- 通过对一些运行时间长的SQL进行分析，发现其中有一些执行频率较高的SQL执行计划还可以优化、提升性能。
- 数据库使用的是自动内存管理，即SGA组件均设置为0，由oracle按需分配，而近期，shared_pool和db cache size之间存在严重的转换，当db cache size减小时，必然导致一部分冷端数据被换出内存，那么当SQL申请的数据块越多，节点间传输数据块的代价越大，因为产生的物理读会变多，要不断的把数据块读入内存。而当db cache size 变大时，shared pool减小又会对SQL解析产生影响。应避免这种内存抖动。
- 修改参数，根据目前shared_pool和db cache size的最大值，增大SGA的值，并为shared_pool 和db cache size设置最小值，最小值要满足当前已经达到过的最大值。对执行频次高，但执行计划有问题的SQL进行优化，主要是对不合适的索引进行调整，之前有一些SQL使用单列索引，造成回表过滤的次数过多，回表多必然造成访问的数据块数量增多，访问的数据块数量增多导致读入内存的数据块变多，一是会影响db cache size，可能导致数据块被换出，同时也造成节点间传输数据量变大。主要的优化方式是使用合适的联合索引，尽量在索引中过滤数据，减少回表过滤的次数。
- 修改完参数，并优化了10几条高频次SQL后，在两个节点同时使用的情况下，活动会话数基本正常了，业务量高峰偶尔会达到100多个，过一会儿就会下降到正常数量，业务反应基本没有卡顿出现。但CPU使用率的问题还没有得到解决，用户态使用率下降到20%左右，内核态使用率仍旧达到40%以上。
- gc等待涉及到对数据块资源的申请、加latch、传输等操作，同时还涉及内存管理，可能造成内核态使用率增加。但是在优化SQL后，对用户态的使用有了一些下降，但对内核态的使用没有明显改善，这可能还涉及到一些内核参数优化的问题。
- 透明大页没有被关闭。透明大页是动态分配内存，可能影响性能，oracle是建议关闭的，使用预先分配的大页。
- 信号量参数以前改过，检查了当前信号量使用情况后，发现默认值完全能满足，修改回默认值。
- 启用反向路由松散检查，即只要反向路由的源地址能从任意网卡返回就不丢弃包，否则丢弃。
在进行了上述优化后，CPU使用率变化不大，内核态使用率仍旧达到40以上。- 在进行网络、系统、数据库、SQL等优化后，虽然业务访问正常了，但CPU内核态使用率还是居高不下，在与甲方沟通后发现这套集群主机是运行超过5年的超期服役机器，怀疑是硬件性能已经达到了瓶颈，无法支撑不断增长的业务量，建议迁移到新的服务器。
- 硬件厂商部署了两个新机器，物理CPU还是两个，逻辑CPU数量达到104个，通过xtts方式进行迁移之后，新主机上未出现内核态使用率高的情况，CPU使用率恢复正常。内核态使用率下降到3%左右，用户态下降到10%左右。
通过这次故障处理的过程，可以发现，其实运维是一个综合性很强的工作，主机、数据库、网络、应用甚至硬件都需要有一定的了解，特别是对于数据库的运维，如果仅仅掌握数据库运维的知识，只能从数据库本身的角度去看问题，局限性很大，比如本次故障，如果不了解CPU中断、网卡分列请求等知识，就无法定位到网卡对应的逻辑CPU被跑满的情况，如果不熟悉SQL优化，就可能认为走了索引的SQL没有问题，如果不了解主机、系统优化的知识，就无法做到通过优化参数来提升系统性能，所以作为DBA，要不断的去学习，提升自己各个方面的能力。
底层交换机故障切换引起的网络波动导致应用连接redis出现超时问题，出现用户app和维护web后台使用异常，报错redis连接超时异常。1）通过LTS日志服务查看redis timed out报错信息。2）通知排查redis集群（proxy集群）故障原因，集群显示正常后，日志中仍有redis连接超时的报错。- 反馈底层接入交换机故障，备机切换到主机过程中，部分流量转发异常，切换时间耗时 25 秒，导致负载到该接入设备的业务访问出现异常。
- 开发人员排查客户端长链接出现断连后，redis集群恢复后，应用与redis之间仍存在异常链接，无法获取redis数据，出现间断性的业务异常，业务未完全恢复
- 针对断连存在异常问题，给出的建议是使用jedis替换lettuce连接池，原因是Lettuce异常的连接无法通过命令进行探测，使用异常连接发起请求会造成业务超时，重试后重建连接恢复。Jedis连接池可以通过配置借用前连接探测，屏蔽异常连接对于业务的影响。
- 由于spring boot2.0默认redis连接池采用lettuce，Lettuce客户端基于Netty的NIO框架实现，性能较较好，因此，开发人员对lettuce连接池进行二次封装，增加对redis服务探活，保证连接池的连接可用性。
1）加强监控角度，对主流程服务添加 error，timed out的关键字日志监控2）对redis的实例的命令延迟和慢日志等加入日常巡检项，定时大key分析。
某业务有一套Kubeadm部署的Kubernetes集群，Kubernetes版本为1.15，CNI网络插件为Calico，使用的IPIP模式。故障现象：用户使用平台时会出现无响应、响应超时现象，在集群中部分主机curl接口正常，部分主机无响应。1）首先检查服务是否运行正常，磁盘使用率是否正常（磁盘使用率较高会导致kubernetes主动驱逐pod），业务日志有无明显报错。2）检查calico、coredns是否正常运行。3）curl服务接口，在node节点上和容器内抓包，抓包发现有大量重传现象，遂怀疑主机网络有问题。联系甲方核实是否有网络变更，甲方回复没有任何网络变更，突然之间就是不能用了。部署业务的主机由甲方提供，且主机、网络等由甲方维护。4）查看甲方反馈出问题时间点的kubernetes组件日志、系统日志、业务日志，逐个重启服务，重新抓包分析。怀疑是mtu值设置不合理导致重传和丢包较多，检查主机网卡和calico mtu值配置均未发现改动。联系我方网络侧同事帮助分析，也怀疑是mtu值设置不合理导致，遂将初步结论反馈甲方并再次核实是否有网络变更，甲方反馈底层物理机修改过mtu值。5）calico使用的ipip模式，容器发出的包是由tunl0设备转发的，tunl0设备是一个ip隧道设备，ip包进入ip隧道设备后会被封装一层外部ip报头（20字节）。甲方的虚拟化系统中虚拟机之间互相通信使用的是vxlan模式，会对转发的包再封装50字节的报头，容器的虚拟网卡mtu值为1440，这样加在一起就是1510，超过了最大值1500，所以导致用户反馈的现象。网络是任何系统或平台离不开的技术，在故障处理过程中需要充分考虑。运维是一门经验可行，通过不断踩坑才能积累经验，而通过大的维护厂商踩过的坑的经验，就能尽量避免他人再次踩坑。GOLDENDB因为运维人员误连接到DN的一个分片，对一个分区表新增分区，导致业务人员通过CN节点无法查询到新增的分区。在原分片中，删除新增的分区，然后通过CN连接数据库，新增分区。1）分布式数据库运维过程中，切勿连接其中一个分片进行相关操作。2）平时运维过程中，养成使用CN连接数据库的习惯，尽量避免通过DN连接数据库3）国产数据库本身的容错机制需要进一步加强，对于直接操作DN的变更，需要进行提示。
