首页 文章 精选 留言 我的

精选列表

搜索[智能问数]，共10011篇文章
优秀的个人博客,低调大师

《叶问》第1期

2018年6月10日，周日 MySQL主从复制什么原因会造成不一致，如何预防及解决？ 一、导致主从不一致的原因主要有： 1、人为原因导致从库与主库数据不一致（从库写入）2、主从复制过程中，主库异常宕机3、设置了ignore/do/rewrite等replication等规则4、binlog非row格式5、异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。 但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。6、从库中断很久，binlog应用不连续，监控并及时修复主从7、从库启用了诸如存储过程，从库禁用存储过程等8、数据库大小版本/分支版本导致数据不一致？，主从版本统一9、备份的时候没有指定参数 例如mysqldump --master-data=2 等10、主从sql_mode 不一致11、一主二从环境，二从的server id一致12、MySQL自增列 主从不一致13、主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点14、采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致，要看binlog是否传到了从库15、启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复制 二、预防和解决的方案有： 1、master:innodb_flush_log_at_trx_commit=1&sync_binlog=12 、slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=13 、设置从库库为只读模式4 、可以使用5.7增强半同步避免数据丢失等5 、binlog row格式6 、必须引定期的数据校验机制7 、当使用延迟复制的时候，此时主从数据也是不一致的（计划内），但在切换中，不要把延迟从提升为主库哦~8 、mha在主从切换的过程中，因主库系统宕机，可能造成主从不一致（mha本身机制导致这个问题） 2018年6月11日，周一 你为什么会决定进行分库分表，分库分表过程中遇到什么难题，如何解决的？ 一、为什么决定进行分库分表？ 1 、根据业务类型，和业务容量的评估，来选择和判断是否使用分库分表2 、当前数据库本事具有的能力，压力的评估3 、数据库的物理隔离，例如减少锁的争用、资源的消耗和隔离等4 、热点表较多,并且数据量大，可能会导致锁争抢，性能下降5 、数据库的高并发，数据库的读写压力过大，可能会导致数据库或系统宕机6 、数据库（MySQL5.7以下）连接数过高，会增加系统压力7 、单表数据量大，如SQL使用不当，会导致io随机读写比例高。查询慢（大表上的B+树太大，扫描太慢，甚至可能需要4层B+树）8 、备份和恢复时间比较长 二、都遇到什么问题? 1 、全局pk（主键和唯一索引）的冲突检测不准确，全局的自增主键支持不够好2 、分片键的选择。如没有选择好，可能会影响SQL执行效率3 、分布式事务，中间价产品对分布式事务的支持力度4 、对于开发来说，需要进行业务的拆分5 、对于开发来说，部分SQL不兼容则需要代码重构，工作量的评估6 、对于开发来说，跨库join，跨库查询 三、如何解决? 1 、使用全局分号器。或者使用全局唯一id，（应用生成顺序唯一int类型做为全局主键）2 、应用层来判断唯一索引3 、配合应用选择合适的分片键，并加上索引4 、配合应用，配合开发，对不兼容SQL的进行整改 2018年6月12日，周二 MySQL高可用架构应该考虑什么? 你认为应该如何设计？ 一、MySQL高可用架构应该考虑什么？ 1 、对业务的了解，需要考虑业务对数据库一致性要求的敏感程度，切换过程中是否有事务会丢失2 、对于基础设施的了解，需要了解基础设施的高可用的架构。例如 单网线，单电源等情况 3 、对于数据库故障时间掌握，业务方最多能容忍时间范围，因为高可用切换导致的应用不可用时间4 、需要了解主流的高可用的优缺点：例如 MHA/PXC/MGR 等。5 、考虑多IDC多副本分布，支持IDC级别节点全部掉线后，业务可以切到另一个机房 二、你认为应该如何设计? 1 、基础层 和基础运维部门配合，了解和避免网络/ 硬盘/ 电源等是否会出现单点故障 2、应用层 和应用开发同学配合，在关键业务中记录SQL日志，可以做到即使切换，出现丢事务的情况，也可以通过手工补的方式保证数据一致性，例如：交易型的业务引入状态机，事务状态，应对数据库切换后事务重做 3、业务层 了解自己的应用，根据不同的应用制定合理的高可用策略。 4 、单机多实例 环境及基于虚拟机或容器的设计不能分布在同一台物理机上。 5 、最终大招 在数据库不可用 ，可以把已提及的事务先存储到队列或者其他位置，等数据库恢复，重新应用 2018年6月13日，周三 MySQL备份，使用xtrabackup备份全实例数据时，会造成锁等待吗？那么如果使用mysqldump进行备份呢？ 一、xtrabackup和mysqldump会造成锁等待吗？ 1 、xtrabackup会，它在备份时会产生短暂的全局读锁FTWL(flush table with read lock)，用于拷贝frm/MYD/MYI等文件，以及记录binlog信息。如果MyISAM表的数据量非常大，则拷贝时间就越长，加锁的时间也越长2、mysqldump有可能会。如果只是添加 --single-transacton 选项用于保证备份数据一致性，这时就不会产生FTWL锁了。但通常我们为了让备份文件和binlog保持一致，通常也会设置 --master-data 选项用于获得当前binlog信息，这种情况也会短暂加锁3 、数据量特别大的话，建议优先用 xtrabackup，提高备份/恢复速度。而如果数据量不是太大或者想备份单表，则建议用mysqldump了，方便逻辑恢复。各有利弊，注意其适用场景 二、xtrabackup冷知识 1 、基于MySQL 5.6版本开发的xtrabackup，会在备份过程中生成内部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，备份结束后文件删除，默认文件位置 /tmp/xtrabackup_suspended 2 、如果在备份过程中，修改了 /tmp 的访问权限或该文件的权限，则两个程序间直接不能通信，会造成 xtrabackup hang 住，正在备份的表不能正常释放锁，会造成锁等待，此时需要强制 kill 掉 xtrabackup 进程 2018年6月15日，周五 MySQL 5.7开始支持JSON，那还有必要使用MongoDB存JSON吗？请列出你的观点/理由。 一、观点A：支持MySQL存储JSON 1 、MongoDB不支持事务，而MySQL支持事务2 、MySQL相对MongoDB而言，MySQL的稳定性要优于MongoDB3 、MySQL支持多种存储引擎 二、观点B:支持MongoDB存储JSON 1 、从性能的角度考虑，对于JSON读写效率MongoDB要优于MySQL2 、MongoDB相对MySQL而言，MongoDB的扩展性要优于MySQL3 、MongoDB支持更多的JSON函数 三、总结 1 、如果应用程序无事务要求，存储数据表结构复杂并且经常被修改， 例如游戏中装备等场景用MongoDB比较适合2 、如果应用程序有事务要求，存储数据的"表"之间相互有关联，例如有订单系统等场景用MySQL比较合适3 、整体来看相对看好MySQL的JSON功能，在未来官方的努力下MySQL的JSON功能有机会反超MongoDB 2018年6月17日，周日 当数据被误删除/误操作后造成数据丢失。你尝试过用什么手段来挽救数据/损失？ 一、前提 1 、当数据被误删除/误操作后，第一时间要关闭数据库。业务方需要紧急挂停机公告，避免数据二次污染，用于保护数据的一致性2 、BINLOG格式为ROW格式，不讨论其他格式的BINLOG 二、数据被误操作(update/delete/drop)造成数据丢失，可以用哪些手段来恢复？ 1 、BINLOG恢复：可以使用逆向解析BINLOG工具来恢复。例如：binlog2SQL等2 、延迟从库: 可以通过解除延迟从库，并指定BINLOG结束位置点，可以实现数据恢复 三、数据被误删除(rm/物理文件损坏)造成数据丢失，可以用哪些手段来恢复？ 1 、如果有备份，可以通过备份恢复 mysqldump/xtrabackup + binlog 来实现全量+增量恢复2 、如果无备份但是有从库，可以通过主从切换，提升从库为主库，从而实现数据恢复3 、如果无备份并且无从库，但MySQL没有重启，可以通过拷贝/proc/$pid/fd中的文件，来进行尝试恢复4 、如果无备份并且无从库，但MySQL有重启，可以通过extundelete或undrop-for-innodb来恢复 2018年6月19日，周二 MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中，该如何选择？ 一、生产环境中： 几种复制场景都有存在的价值。下面分别描述一下： 1 、从成熟度上来选择，推荐：异步复制(GTID+ROW)2 、从数据安全及更高性能上选择：增强半同步 （在这个结构下也可以把innodb_flush_log_trx_commit调整到非1， 从而获得更好的性能)3、对于主从切换控制觉的不好管理，又对数据一致性要求特别高的场景，可以使用MGR 二、理由： 1 、异步复制，相对来讲非常成熟，对于环境运维也比较容易上手 2 、增强半同步复制，可以安全的保证数据传输到从库上，对于单节点的配置上不用要求太严格，特别从库上也可以更宽松一点，而且在一致性和性能有较高的提升，但对运维上有一定的要求3 、MGR组复制。相对增强半同步复制，MGR更能确保数据的一致性，事务的提交，必须经过组内大多数节点（n/2+1）决议并通过，才能得以提交。MGR架构对运维难度要更高，不过它也更完美 总的来讲，从技术实现上来看：MGR> 增强半同步>异步复制。 未来可能见到更多的MGR在生产中使用，对于MySQL的运维的要求也会更上一层楼。
2018-11-28
优秀的个人博客,低调大师

《叶问》第6期

2018年7月26日，周四 专访黄炎:MySQL中间件的性能测试和常规业务性能测试相比有什么不同？ 1、性能测试的方法论基本都一样, 以“观察-分析-改进-再观察”这个循环进行。2、常规业务由于业务交互复杂、技术栈庞杂、性能瓶颈通常集中于业务, 性能测试使用的分析方法比较简单, 通过诊断业务通常可以低成本地找到性能瓶颈。3、MySQL中间件的应用场景比较简单、技术栈稳定、性能瓶颈通常集中于架构和环境, 性能测试使用的分析方法比较多, 对性能瓶颈的分析通常成本比较高. 另外在这一方面的现有知识积累并不很成体系, 也是成本较高的原因之一。 2018年8月2日，周四 《全方位认识SYS系统库》公开课精彩互动问答： 1、为什么我用root用户调用call ps_setup_enable_instrument('wait');报错说存储过程不存在？ 1、答：sys schema是从MySQL 5.7之后才默认支持，请确保你的数据库版本正确，且先使用use语句切换默认数据库，否则请带上 sys.库名称限定前缀。 2、myisam锁如何查询？ 1、答：MyISAM 不支持事务，所以不存在事务锁，但可以查询表级锁（例如：MDL锁），通常表级锁是Server层添加的锁，与具体的存储引擎无关，所以与InnoDB存储引擎查询方法一致，建议多多尝试即可得出答案。 3、为什么我查询session系统表，当前正在执行SQL的会话的progress为 NULL 呢？ 1、答：对于progress信息，仅支持stages事件（performance_schema.setup_instruments表的name字段以stages开头的采集项），其他事件类型不支持，且就算是stages类型事件，也不是所有的采集项都支持，可以通过观察performance_schema.events_stages_current表的WORK_COMPLETED和WORK_ESTIMATED字段，需要不为NULL值，progress信息就是根据这些不为NULL的值进行计算的 注意：要成功采集stages性能数据，必须打开stages事件相关的instruments和consumers如果不满足以上条件，session视图查询到的progress字段就会显示NULL。 4、线上数据库，开启ps和关闭ps功能，mysqld使用的内存会相差20G，可以判断ps会用到很多主机内存。怎么判断ps功能回来多少内存？怎么进行优化ps对内存的使用？ 1、答：ps的整体功能无法动态开关，必须在数据库启动之前就设置好，能够动态开关的只是ps的具体的instruments采集项和consumers存储表，对于查询ps使用的内存总量，可以使用语句 select sys.format_bytes(sum(current_alloc)) from sys.x$memory_global_by_current_bytes where event_name like 'memory/performance_schema%'; 查询，对于ps内存使用的优化，MySQL 提供了一系列performance_schema打头的系统变量来进行灵活配置，请根据需要自行调整，默认情况下不建议调整，除非你真的需求，否则就会浪费内存空间。 2018年8月7日，周二 在MySQL中如果发现乱码的情况该如何判断原因及应对？ 1、直接修改法. alter或者pt-osc等其他工具直接对数据进行修改。2、备份修改法. 利用mysqldump或者其他逻辑备份进行备份，备份的结果集再利用iconv进行转换3、跳过字符集备份.利用mysqldump备份的时候跳过字符集-t --skip-set-charset。在恢复的时候指定表的字符集。 那么应该如何避免乱码呢？ 1、首先要从应用端到MySQL，采用统一编码格式。2、在MySQL的配置中,指定编码格式。3、在上线或者导入SQL的时候，要注意本地的编码集。
2018-11-28
优秀的个人博客,低调大师

《叶问》第5期

2018年7月17日，周二 MongoDB高并发写场景开启读写分离读从库为何阻塞? 我们该如何处理? 1、按业务拆分逻辑降低读写并发度2、添加分片均衡读写 3、升级至即将到来的4.0通过读snapshot解决从库读阻塞 2018年7月19日，周四 MongoDB 4.0有哪些新特性，你最期待的有哪些，为什么？ 1、多文档事务的支持，解决了多文档操作的原子性问题2、snapshot读相关支持，使得可在某个timestamp点上读到一个一致性的快照3、Change Streams 支持实例及库级别粒度为业务提供了更多实时捕获变更的选择4、聚合框架支持类型转换及字符前后空格截断操作5、加入对SCRAM-SHA-256认证策略以支持更强的认证加密验证6、提供通过简单的命令开启免费监控功能7、更多的操作支持w:majority 比如对集合进行分片，创建删除集合等8、listCollections 可以指定nameOnly:true 而不加锁9、增加 rollbackTimeLimitSecs参数控制节点回滚的最大时间限制10、支持直接在mongos路由节点直接kill具体操作无需按分片进行11、使用WiredTiger引擎不允许关闭journal日志 2018年7月24日，周二 Redis如何获取所有的key，不阻塞？ 1、在slave上执行Save命令，拷贝rdb文件到其他redis实例上用于统计key。 2、可以利用scan命令，来遍历当前数据库中的数据库键。、 2018年7月26日，周四 MySQL中间件的性能测试和常规业务性能测试相比有什么不同？ 1、性能测试的方法论基本都一样，以观察-分析-改进-再观察这个循环进行。2、常规业务由于业务交互复杂、技术栈庞杂、性能瓶颈通常集中于业务, 性能测试使用的分析方法比较简单, 通过诊断业务通常可以低成本地找到性能瓶颈。3、MySQL中间件的应用场景比较简单、技术栈稳定、性能瓶颈通常集中于架构和环境, 性能测试使用的分析方法比较多, 对性能瓶颈的分析通常成本比较高。另外在这一方面的现有知识积累并不很成体系, 也是成本较高的原因之一。
2018-11-28

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-19 大小: 189MB 下载: 8次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册