点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
- 磐维分布式数据库不支持自定义dcs组件数据目录问题分析
- MYSQL数据库排序规则报错 ERROR 1267问题分析
- MYSQL数据库mysql主库的服务器由于硬件问题导致服务器宕机重启问题分析
集群上有条长会话僵死在主节点上无法进行kill正常清理会话。2）使用函数pg_terminate_backend(pid);进行会话清理,无法清理3）使用cm_ctl stop 停止cm_ctl start重启数据库1）集群有长会话无法正常清理时，应首先尝试使用数据库内部提供的工具或函数进行清理如果这些方法无效，再考虑更激进的操作，如重启数据库服务。在本案例中，我们未能成功使用pg_terminate_backend(pid)函数清理僵死会话，这提醒我们在日常运维中需要更加熟悉和掌握数据库的各种工具和函数，以便在出现问题时能够迅速找到有效的解决方案。2）在处理僵死会话时，应尽量避免在操作系统层面上直接清理会话这是因为操作系统层面的操作可能会破坏数据库的内部状态，导致数据库崩溃或数据丢失。在本案例中，我们选择了与业务团队沟通并安排重启数据库服务来清理僵死会话，这是出于对数据库稳定性和安全性的考虑。然而，这也提醒我们在未来的运维工作中需要更加谨慎地处理类似问题，避免不必要的风险。3）优化SQL查询和事务处理逻辑，减少长会话的发生这可以通过对SQL查询进行性能调优、优化数据库索引、减少锁等待等方法来实现。同时，对于复杂的事务处理，可以考虑将其拆分为多个小事务来执行，以降低事务失败和僵死的风险。4）建立完善的监控和报警机制，及时发现并处理长会话问题这可以通过配置数据库监控工具来实现，如设置SQL执行时间阈值报警、会话状态监控等。一旦发现长会话问题，可以立即通知相关人员进行处理，避免问题进一步恶化。磐维数据库安装后检查各组件服务，发现dcs组件默认的数据目录在/var/lib/etcd，占用根分区空间，由于根分区容量太小，需要将dcs数据库目录指定到其它容量大的磁盘。1）尝试使用以下两种方式自定义修改etcd数据目录- 方式二：etcdctl backup/snapshot 备份数据导入至新数据目录
后经原厂内部确认得知(目前未测试过这个场景），当前磐维最新版本V2.0-S3.0.2_B02 还不支持自定义dcs组件数据目录。本次事件暴露出我们在资源规划方面的不足，在接收和使用一级云提供的资源时，我们未能充分考虑到用户数据增长的情况，导致根分区容量在初期就显得捉襟见肘。这提醒我们在未来的资源规划中，需要更加谨慎地评估分区容量，并预留足够的空间以应对未来的数据增长。此外，我们还发现监控与预警机制的缺失也是导致此次问题的一个重要原因。如果能够提前监测到根分区的空间使用情况，并设置相应的预警阈值，我们就可以在问题发生前采取措施，避免服务中断的风险。因此，加强监控与预警机制的建设，将是我们未来工作的一个重要方向。同时原厂也反馈会在后续的新版本考虑dcs组件自定义数据目录的问题。在生产环境中运行了一个基于 Kubernetes 的微服务应用，其中某个系统关键服务是 payment-service。某天开发团队发现 payment-service 的 Pod 状态始终为 CrashLoopBackOff，导致无法处理支付请求。通过 kubectl describe pod 查看 Pod 的描述信息，发现环境变量 DB_HOST 被配置为 localhost。使用 kubectl get svc 查看数据库服务的暴露情况:kubectl get svc -n production数据库服务 payment-db 正常运行，说明问题出在 Pod 配置上。查看 Deployment 文件，确认 DB_HOST 配置错误，应改为 payment-db。更新 Deployment 的环境变量，验证修复等待 Pod 重启后，状态恢复正常。严格遵循配置管理规范，利用 Kubernetes 提供的 ConfigMap 和 Secret 等工具集中管理应用配置，避免因手动配置错误导致服务不可用。在应用部署或更新前，验证所有依赖的配置和服务是否正确并可用，避免因配置错误或服务依赖问题引发故障。微服务设计中应考虑配置错误或依赖服务不可用的场景，提供适当的降级处理机制（如使用默认值或返回错误信息），确保系统的部分功能能继续运行。借助 Kubernetes 提供的工具（如 kubectl describe pod、kubectl get svc 等），快速定位问题来源，并形成系统化的故障排查流程，提高解决问题的效率。某业务系统telepg数据库业务执行批量操作，网络流量突增，导致gateway和zk之间心跳超时，vip切换引起程序连接出现报错。收到某业务系统数据库连接数过多，达到1979，产生了告警，业务反馈程序不可用。业务紧急切换到灰度环境，连接数陆续下降，业务逐渐恢复正常。查看数据库资源和主机资源历史情况，确定问题时间点。查看gateway日志发现gateway与zk连接中断的报错，有gateway关闭vip和启动vip的操作，在vip切换完成后，由于应用不能重连，连接池不释放导致业务不可用，重启业务后才恢复正常。查看问题时间点慢sql的情况，发现在问题时间点前，存在使用存储过程进行大表批量操作。在业务高峰期，严格控制批量操作（如大表更新、存储过程执行等），以免因资源竞争导致数据库或网络瓶颈，引发不可用情况。设定合理的数据库连接数限制，优化连接池管理机制，确保应用能够正确处理连接中断和VIP切换等情况，避免因连接池不释放导致的资源占用。应用应具备自动重连能力和容错机制，以应对VIP切换等故障场景，避免需要人工干预才能恢复。针对关键资源（如网络流量、数据库连接数、主机性能等）设置实时监控和预警，及时发现异常并采取措施。针对批量操作，建议分批次执行，控制单次操作的规模，并合理配置事务提交策略，减少对资源的瞬时占用。can't connect to client，备份过程中提示无法连接客户端，不过有时候也会执行备份成功。./bp.kill_all；./bp.start_all
bptestbpcd -client hn-gx-crm-kvm-esop-core-3 -verbose)
在其中某个media上测试发现连通性有问题，并测试端口发现不通，通过任务的详细对比终于发现问题，原来是由于客户端到部分media的1556端口不通所致。在进行备份任务时，确保对所有目标主机（如 Media 服务器）进行全面的网络连通性测试，而非随机选择。特别是对于端口和防火墙设置，必须验证客户端与所有 Media 主机的通信通畅。定期检查备份系统的配置和相关进程状态，确保配置正确且服务处于正常运行状态。出现连接问题时，及时重启相关进程，并进行详细的日志分析。当涉及到多个 Media 资源池时，确保在资源池内的所有节点都能稳定连接客户端。针对每个节点的通信问题进行独立排查，避免单点故障导致备份失败。MYSQL数据库排序规则报错 ERROR 1267
ERROR 1267 (HY000): Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='
发现涉及到的俩张表的字符集排序规则不同，创建视图时 MySQL 会自动使用 convert 函数转换字符集，mysql8.0 utf8mb4默认排序规则为utf8mb4_0900_ai_ci。default_collation_for_utf8mb4改为utf8mb4_general_ci后执行还是报错。发现元数据信息中 utf8mb4 字符集默认排序规则是 utf8mb4_0900_ai_ci ，show collation/show character 输出的都是 utf8mb4_general_ci。可见convert 使用的是 INFORMATION_SCHEMA.COLLATIONS 的排序规则，而不是 default_collation_for_utf8mb4 指定的 utf8mb4_general_ci。default_collation_for_utf8mb4 修改后影响 SHOW COLLATION and SHOW CHARACTER SET 的查询结果，并不会改变字符集的默认排序规则。4）将convert 函数指定为 t1.name1 字段的排序规则后，sql 执行正常select * from t1,t2 where`t1`.`name1` = convert(`t2`.`name2`using utf8mb4) collate utf8mb4_general_ci;
- character_set_database（默认值：utf8mb4）；
- character_set_server（默认值：utf8mb4）
2）需要创建非默认字符集 database table 时，需要在 sql 中明确指定字符集和排序规则 3）在进行MySQL5.7迁移至MySQL8.0时，需要注意- MySQL5.7 utf8mb4 默认排序规则是 utf8mb4_general_ci；
- MySQL8.0 utf8mb4 默认排序规则是 utf8mb4_0900_ai_ci。
mysql主库的服务器由于硬件问题导致服务器宕机重启
MYSQL数据库mysql主库的服务器由于硬件问题导致服务器宕机重启，主从切换后，复制报错：Could not execute update_rows eventontable hc_utio_lb3;
Can't find record in hc_utio_lb3,Error_Code: 1032; handlererror HA_ERR_KEY_NOT_FOUND;...
1）查看高可用组件日志，主从切换的GTID一致，并未丢数2）在从库执行show slave status\G发现从库比主库多了一个GTID，用mysqlbinlog解析这个gtid，发现这个事务涉及的表和报错表是同一张。通过解析并查看该表结构发现该表是内存表，新从库重启后数据库自身做了一个清空内存表的操作。而此时新主库对该表进行了更新操作，在新从库中无法找到相关的行记录，进而中断复制抛出错误：/* generated by server, implicitly emptying in-memory table */
该表的数据不大，和业务确认后，在新从库跳过该表的复制，并启动复制进程追平数据，然后在新主库导出数据并导入新从库中。然后在新从库取消跳过该表复制的操作，后续应用将表改为 InnoDB 事务表。1）本次故障的一个重要教训是，在生产环境中应尽量避免使用非事务表（如MEMORY表）内存表虽然具有访问速度快、不占用磁盘空间等优点，但其数据在数据库重启时会丢失，这可能导致复制中断、数据不一致等严重问题。因此，在生产环境中应优先考虑使用事务表（如InnoDB表），以确保数据的一致性和可靠性。为了从源头上避免非事务表的使用，可以在数据库层面加以限制。例如：- 可以通过修改sql_mode参数来禁用MEMORY存储引擎的使用；
- 或者通过设置disabled_storage_engines参数来明确指定不允许使用的存储引擎。
这些措施可以在一定程度上减少因误用非事务表而导致的潜在风险。另外，本次故障也暴露出数据库监控与报警机制的重要性。如果能够在主从切换或数据库重启后及时检测到复制状态的变化，并采取相应的应对措施，那么可能会更早地发现并解决问题，从而减少对业务的影响。因此，建议加强数据库的监控与报警机制，包括但不限于对复制状态、错误日志、性能指标等进行实时监控和报警。同时，还应建立完善的故障排查和应急响应流程，以确保在发生故障时能够迅速定位问题并采取有效的解决措施。此外，定期备份数据库数据并进行数据恢复演练也是非常重要的。通过定期备份可以确保在数据丢失或损坏时能够及时恢复；而通过数据恢复演练可以提高团队在应对数据丢失等紧急情况时的应对能力和效率。建议制定完善的备份策略和数据恢复计划，并定期进行演练和评估。某省XX系统Weblogic控制台弱密码修改后，应用加载不结束，实例启动异常问题处理。某省XX系统Weblogic弱口令改造，控制台密码改造完成后，被管server启动异常，业务异常。- 使用${JAVA_HOME}/bin/java -classpath ${WL_HOME}/server/lib/weblogic.jar weblogic.security.utils.AdminAccount ${NewAdminUserName} ${NewAdminPassword} . 命令进行重置密码处理。
核查被管Server启动日志，密码校验已通过，但是应用工程加载一直不结束。怀疑是控制台密码修改对服务启动有影响，于是将控制台密码还原，排除可能因当晚操作导致Server启动异常的可能性，发现重启应用加载依旧不结束。- 重新搭了一个domain域关联业务应用，启动新domain域Server还是一样的问题应用工程加载一直不结束，无法正常启动实例。
- 拉应用侧开发人员一起分析，查看业务日志，分析业务调用逻辑，没有找到问题原因。
- 最后通过jstack导出被管Server的线程dump进行分析，发现部分线程在执行连接zk的相关方法卡住了，怀疑连接zk连接不上导致应用工程无法加载完成。
反馈业务侧核查连接的zk集群状态，发现机器已下线配置未变更，主机侧将下线重新启动，并拉起zk服务。再次重启Weblogic被管Server，应用加载成功，被管启动状态正常，业务恢复正常。1）在本次故障处理过程中，未能对修改的domain域进行全域备份，导致在问题排查和恢复过程中面临一定困难因此，强烈建议在执行任何可能影响系统稳定性的操作前，对关键域进行全域备份。这有助于在出现问题时快速恢复系统至稳定状态，减少业务中断时间。2）在处理服务启动异常时，我们曾误认为由于服务未正常启动，导出线程dump无法获取有用信息然而，实际上通过线程dump分析，我们最终定位了问题的关键点——zk连接问题。因此，无论服务是否启动成功，当出现性能异常或启动失败时，都应立即导出线程dump进行分析。这有助于快速定位问题根源，提高故障处理效率。在密码修改后，系统未能及时发出异常预警，导致问题发现滞后。因此，建议加强系统监控和预警机制，确保在关键操作后能够实时监测系统状态，及时发现并处理潜在问题。2）20：10经过排查，发现update语句耗时6.62s，其中lock_sql_wait耗时5.57s，询问厂家，反馈这条SQL是新的业务变更发现该类语句在未改造前，正常情况下耗时2秒多，其中lock_sql_map耗时1.6s左右。经向业务咨询，业务近期做了变更，该语句变更为下图语句，该语句耗时6.6s，逻辑读变多导致产生更多的行锁，进而导致维护锁等待日志代价变大，具体表现在lock_sql_map耗时边长为5.5s。4）分析lock_sql_map耗时，锁等待日志的内部原理为了实现打印blk_sql的功能，需要在每一次行锁变更期间同步维护一个 [从行锁到SQL语句的映射信息表]， 以标记每一个事务的每一把行锁是被哪一个SQL语句申请的（由于行锁申请在先、锁冲突在后，为了应对随时可能发生的锁冲突，所有事务的任何一个行锁变更都需要先维护映射关系），我们把这个从行锁到SQL语句映射表内部标识为lock_sql_map。在锁等待发生之后，我们只需要根据当前行锁阻塞的记录位置生成key值（表空间id、数据页id、记录号heap_no、锁模式lock mode、事务号trx_id），然后到lock_sql_map里查询已经该行锁的SQL语句、并作为blk_sql打印即可。当然，虽然打印锁等待的过程只有1个查询lock_sql_map的过程，但是维护起来却比较麻烦，因为行锁的变动实在太过频繁、场景也比较复杂，行锁的所有变动都需要同步维护lock_sql_map。虽然原厂版本上针对锁系统已经做了优化，但是lock_sql_map维护工作还是相对热点的，在高并发DML（尤其是x86高核、海光、ARM）等场景下这里的spin_lock可能会成为瓶颈，影响整体性能、也可能导致CPU产生额外消耗冲高的情况。1）锁等待日志开关打开会增加系统开销，导致cpu消耗增大，sql耗时增长，关闭开关，可以一定程度减少系统开销。数据库国产化后，我们面临了一些与以往不同的系统功能逻辑。在这次问题中，由于对国产化数据库的一些特性了解不够深入，我们没有及时准确地分析出问题所在。在开启锁等待日志的情况下，系统需要额外维护lock_sql_map映射表，这在高并发场景下可能会成为性能瓶颈。因此，在未来的系统配置和优化中，我们需要更加谨慎地考虑锁等待日志的开启与否。这次问题还暴露出我们在业务压测方面的不足。在业务变更后，新的SQL语句执行频率变高且执行速度变慢，加上锁等待日志的影响，导致CPU消耗显著增加。如果我们能在上线前对这些SQL语句进行充分的测试和优化，或许能够避免这次问题的发生。业务sql使用connect by 生成序列导致执行计划不能下推dn，gbase8c端执行13分钟。优化后执行8秒。查看执行计划，执行计划不能下推到dn，基表数据从dn顺序扫描到cn进行计算。执行效率相比较fqs和stream低。修改connect by 语句 SELECT ROWNUM rn FROM dual CONNECT BY ROWNUM <= 24 为select rn from generate_series(1,24) rn。新执行计划走Stream计划sql查询只需要8秒。在将Oracle等关系型数据库迁移到GBase 8C等分布式数据库系统时，由于底层架构和执行引擎的差异，原有的SQL语句可能无法直接获得最优的执行计划。因此，在迁移过程中，我们需要对SQL语句进行充分的测试和优化，以确保其在新系统中的性能表现。2）对于使用CONNECT BY等特定语法生成序列的SQL语句，我们需要特别注意其在分布式数据库系统中的执行效率如果执行计划无法被正确地下推到数据节点进行计算，那么就需要考虑使用其他函数或方法来替代这些语法。在本例中，我们使用generate_series函数替代了CONNECT BY语句，从而显著提升了执行效率。新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
