关于随机恢复,最近做了一些改进和整理,发现有些细节的工作比想象中要复杂得多,原本我提出了成功率达到1个9,这个目标相对容易,但是要达到2个9就很难了,假设每天随机测试10次,那么连续10天只要失败1...次,那么就到了2个9的边缘了。...所以我重新梳理了下随机恢复的流程,如下: ? 通过完整的流程梳理,结合当前知道的一些问题。我发现了如下的问题,也做了修正。 ?...各大平台都可以找到我 微信公众号:杨建荣的学习笔记 Github:@jeanron100 CSDN:@jeanron100 知乎:@jeanron100 头条号:@杨建荣的学习笔记 网易号:@杨建荣的数据库笔记...大鱼号:@杨建荣的数据库笔记 腾讯云+社区:@杨建荣的学习笔记
当出现线上case后,团队需要组织故障复盘,故障复盘不要搞成批斗会,复盘的目的是想着改进,并将焦点聚焦如何从故障中提升和改进。 第一,故障根因到底什么?...然后不断反复的重复三个问题,直至团队成员认为找到了改进的措施。 当然,还有 5Why 分析法,就是针对故障至少问 5 个为什么。通常也可以找到比较深层次的原因,或许不是根因,但它比较有针对性。...业务优先还是稳定优先 从运维、SRE 或基础平台的同事的角度看,稳定一定是优先的,任何时候都不能放弃稳定,但是从业务同事的角度看,业务发展肯定是第一位的,没有发展,光有稳定会有什么用呢。...这个过程中也会遇到大大小小的故障,但面临一个取舍问题:到底是减缓业务开发的节奏,投入一定的时间和人力,针对一个个故障作分析、改进,做好定责和绩效绑定,还是保障业务继续往前冲,提高容忍度?...耽误的业务发展收益怎么算?管理不好,对员工的积极性有打击,为竞争对手培养了人才,又怎么办? 还有某个广告业务,虽然跟游戏比算不上最大的印钞机,但是也很赚钱。
此问题已在MySQL 8.0.21中修复。 首先,让我们了解可用于防止UNDO表空间过大的两种方法。 隐式截断 默认情况下,隐式方法在MySQL 8.0中为ON。...8.0.21的改进 在一个非常繁忙的系统上,我们注意到实际的截断会导致性能下降,因为它会将UNDO表空间中的所有页面从缓冲池中清除出来。...改进的另一部分是新的UNDO表空间进行了完整的重做日志,这意味着作为截断操作的一部分,UNDO表空间的最初129页不必刷新到磁盘。...这些改进缓解了QA小组在UNDO截断处于活动状态时,在极为繁忙的服务器上的遇到的周期性停顿。 InnoDB对单个UNDO表空间使用512个唯一表空间ID范围。...因此,为避免这种情况,InnoDB不再允许在两个检查点之间发生超过64个相同的撤消表空间的截断。 这种小小的性能改进是InnoDB不断提高的另一种方式。
关于发号器的使用,其实有一个大背景,那就是关于主键的一些设计问题,在MySQL中如果一张表没有主键,实际的数据处理就有点麻烦了。...自增列的问题很多,有些几句话还说不清楚,大体有如下的一些问题 自增列没有业务含义 过度依赖自增列 自增列和状态值主键并存,反而影响业务逻辑和性能 MySQL历史遗留bug,在MySQL 8.0该问题才修复...id的初始化: replace into test_inc(flag) values('1'); 数据结果为: mysql> select *from test_inc; +------+------+...假设从库的id当前值为1002,在从库切换后,会提升为主库,即可以实现读写,那么在新主库上执行replace into语句结果就会让人奇怪,完整的模拟过程如下: mysql> select * from...mysql> insert into sequence values(last_insert_id()); Query OK, 1 row affected (0.01 sec) 接下来需要做两类场景的测试
昨天帮一个朋友看了MySQL数据清理的问题,感觉比较有意思,具体的实施这位朋友还在做,已经差不多了,我就发出来大家一起参考借鉴下。...rename table,这是MySQL归档数据的一大利器,在其他商业数据库里很难实现。 但是为了保险起见,我说还是得看看表结构再说。结果看到表结构,我发现这个问题和我预想的完全不一样。...mysql> select max(Id) from test_data; +---------+ | max(Id) | +---------+ | 1603474 | +---------+ 1 row...mysql> select round(sum(data_length+index_length)/1024/1024) as total_mb, -> round(sum(data_length...mysql> select current_date-'20171001'; +-------------------------+ | current_date-'20171001' | +----
另外一类情况更偏于主观,做任务的人感觉一切都妥当了,但是验收的时候,发现不是设计理念的问题就是任务的精细度上面比较粗糙,如果本着差不多就行的态度其实也能过去,但是显然以后的事情谁能说的了,真要用到的时候...所以在这件事情上面,我发现以前对自己,对团队成员的要求有些松散,以至于稍微带点要求和质量标准,就会感到大家有些吃力,其实对于职业发展来说是有害的,从0到1的构建主要为了效率和快速迭代,可能在一些质量标准上面可以打折扣...,过度要求会有些刻薄,但是守江山更难,技术维护也是,都希望时间的边际成本能够越来越低,在已有的基础上构建和改进,那得下真功夫。...MySQL 8.0已经推出了几年,也在内部做了一些测试和总结,而且早期我们直接入主MySQL 5.7版本,也算是积累了3年多的经验,所以果断决定新业务都按照MySQL 8.0的基线来推广。...4)把原来文件夹的脚本结构重构为一个单一的脚本 5)修改前端的配置,去掉冗余无效的配置项,修改调用逻辑 6)团队内部做了简单演示,团队提了一些改进建议,修正后发布 这些工作经过了很多的测试和整理之后
Redis MySQL发展历史 MySQL的单机时代 ? 90年代这时候,一个网站的访问量不算太大,单个数据库就足够了。 而且更多的是静态网页,服务器没有太大的压力。...这种情况下,整个服务架构的瓶颈是: 1、数据量太大一个机器放不下 2、访问量(读写混合),一个服务器承受不了 Memcached(缓存)+MySQL+垂直拆分(读写分离) 网站80%的情况都是读数据,每次都要查询数据库的话就十分麻烦...发展过程:优化数据结构和索引(数据本身)->文件缓存(IO)->Memcached 分库分表+水平拆分+MySQL集群 ?...如今 如今数据类型和数据量暴增,比如定位,音乐,热榜都是数据类型,MySQL等关系型数据库已经不够用了。...如果用MySQL存储博客,图片等数据,数据库表很大,效率比较低,要有一种专门的数据库来存储这些数据。NoSQL数据库就是专门存储这些数据的。 目前的一个互联网项目架构 ?
,比如其他的10张表在实时复制,而新增的表会产生新的GTID,在数据没有应用过来之前,会有一系列的GTID无法自动修复。...如果把这个图画的更全面一些,其实是这样的结构,默认是有数据的容灾节点的,中间节点是直接从主库进行数据复制的。...要解决现在的这个问题,导出导入5个小时显然是不合理的,而相对来说理想的方式便是基于物理数据的处理模式。...一种是传输表空间,直接把ibd文件拷贝到中间节点,然后修复数据的差异,这个时候有两种修复差值的模式,一种是基于表中的增量时间来处理,相对不够通用,第二种则是更严谨的模式,则是修改数据的复制链路,基于从库级联复制即可...综上,数据复制是一个很好的数据开关,能够灵活的适配和处理很多偏向于业务需求的数据逻辑,在这个过程中,基于系统层,物理的处理模式要远比逻辑处理要高效的多。
通过I_S获取MySQL的一些元数据信息 获取表的数据文件、索引文件的大小、碎片情况、表行数、自增列增长情况等 获取正在运行的事务有那些,是否有阻塞等 获取当前mysql的连接processlist等等...mysql8.0 之前的查询方式 会在查询information_schema 某个表时创建临时表 来自文件的元数据,扫描文件系统获取FRM文件的表定义 存储引擎的详细信息,例如动态表统计信息 来自MySQL...时创建的临时表 扫描文件系统目录以查找FRM文件 改进 利用MySQL优化器的全部功能,使用数据字典表上的索引来更好的查询 mysql5.7中表文件 ll test* Jul 10 10:52 testse.frm...mysql占用的内存暴涨,出现OOM) mysql8.0 中I_S中tables表以视图的形式存在(查询该视图,不会创建临时表,会使用到视图中表的索引) mysql5.7中获取表大小情况 SELECT...访问I_S.tables不会创建临时表,这减少了内存暴涨的可能,但访问I_S.tables的qps大约是mysql5.7.22的1/5,访问速度没有mysql5.7.22的快 mysql8.0 访问I_S.tables
---- 一、UNION 的作用: UNION 可以将多个 SELECT 查询语句的结果合并成一个结果集,在 MySQL 8.0 中又增添了一些新的功能,我们一起来看下。...举例如下: // 新增 table 语句的使用,由于取的是全表,对于单一字段的去重就不便使用了 mysql> table t1 union select * from t2; +------+-----...8.0 和 5.7 对 union 的处理 在 MySQL 8.0 中,对 SELECT 和 UNION 的解析器规则被重构进而变得更加一致,且减少了重复。...与 MySQL 5.7 相比,某些语句可能需要重写: 对比标准 SQL ,NATURAL JOIN 允许一个可选的 INNER 关键字(NATURAL INNER JOIN)。...,支持标准化上线流程,原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
NLP发展到Transformer相关及改进模型 0. NLP 0.1 发展 https://www.jianshu.com/p/d35a2fd593eb 0.2 训练流程 1....RNN和LSTM 单词的先后顺序会影响句子的意思,RNN擅长捕捉序列关系,不过对于翻译来说,句子间的单词数量不是一一对应的。...通过计算Q与K之间的相关性,得出不同的K对输出的重要程度,再与对应的V相乘求和,就得到了Q的输出。...Transformer的每个参数是动态变化的;而CNN学习参数一旦学习完后就固定了fixed。Transformer对每张图的参数都是不一样的、随时变化的,就可以有无限的参数空间来做一件事。...优点 提高训练速度 改进效果(模拟真实环境下噪声情况,让模型鲁棒性更强) NCE(噪声对比估计):通过学习数据样本分布和噪声样本分布的区别,从而发现样本的特性。
MySQL8.0里引入了不少关于权限的改动,从这些改动可以看出来,权限管理更加的规范和遍历了,这和我们之前为rds mysql增加了大量权限管理很类似,想来Oracle也是通过这些改动为其云业务服务的吧...当前版本为8.0.16 Atomic ACL Statement 由于实现了新的数据词典表,所有的权限相关的信息都存储在innodb mysql tablespace里。...其中restrictions_list存储在mysql.user表中,主要是引入Partial revoke, 可以revoke部分库上的权限,例如mysql库,这实际上对于云业务而言是非常重要的功能:...另外最近也修复了一个有趣的bug#94394,当mysql.user表损坏时,实例启动时仅仅打印了一条错误信息,并以skip-grant-tables的方式启动了。...从MySQL8.0.14开始了增加了一个新的权限位session_variables_admin, wl#12217列出了一些需要该权限位的变量: The following vairables need
重要改进 MySQL8.0 的死锁日志可以看到事务1持有的锁信息了: 这对我们分析死锁无疑是个很好的帮助,而在 MySQL5.7 是没有这个信息的,一直饱受诟病: 注意事项 但是这在某些情况下可能会产生一些误会...X locks rec but not gap; session1 插入时,发生唯一键冲突,需要对 c2 索引 10 这一记录加 S Lock,带 gap 属性,即锁的范围为 (4,10]。...但是由于 session2 已经对记录加了 X Lock,与 S Lock 互斥,所以必须等待 session 2 先释放锁,也就是死锁日志中的lock mode S waiting; session2...再次插入 9,在 (4,10] 范围内,这个位置有 session1 的 gap 锁(虽然还在锁队列中,没有加上),插入意向锁会被 gap 锁阻塞,即死锁日志中的 lock_mode X locks...session1 等待获取的锁 S Lock 阻塞了 session2 将要获取的锁,这在 MySQL8.0 中就会显示成 session1 持有的锁,同时也是 session1 等待的锁。就是这样。
在MySQL8.0中执行器部分代码发生了较大改变,新的执行器向经典的Iterator模型更接近了一步,我们暂时叫它iterator执行器。接下来我们分析一下这个新的执行器。...非常容易扩展为多进程、线程的并发执行。 目标 MySQL8.0执行器改进的目的是创建一个新的用于迭代访问记录的API,它足够通用,可以替换MySQL中所有原有的记录迭代器,并逐步替代掉原有的执行器。...可以认为,MySQL现有执行器的实现方式也限制了它的演进。...,MySQL就会回退到旧的执行器去执行。...未来展望 基于新的执行器,MySQL将支持更多代数查询操作,支持更丰富的功能。
DDL发展 DDL online DDL 工具化时代 1、DDL(锁表阶段) ALGORITHM=COPY ALGORITHM=inplace ALTER TABLE xxxx ADD xxx, ALGORITHM...LOCK=DEFAULT mysql自己去判断是否加锁,原则是是少加锁 LOCK=EXCLUSIVE 读写加锁 注意:8.0 ALGORITHM新增INSTANT,这里LOCK需要等于DEFAULT,...,默认128M 如何查看进度: 在MySQL 5.7需要先开启,然后才能查看 UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE...当对包含 instant 列的表进行 rebuild 时,所有的数据在 rebuild 的过程中重新以旧的数据格式(包含所有列的内容) 2....,binlog已经提交,但是redo还未commit,从而导致读到的数据和binlog已提交数据不符 最后,本篇文章更多是总结一些DDL的使用,更偏向于一些介绍,汇总,可以帮助开发同学来了解下DDL的发展以及工具使用
数据库练习题 七、MySQL数据库密码修改 ---- 一、数据库简介 数据库(Database,DB)是按照数据结构来组织,存储和管理数据的仓库。...主流的关系型数据库产品:Oracle(Oracle)、DB2(IBM)、SQL Server(MS)、MySQL(Oracle)。...二、MySQL数据类型(5.5版本) MySQL中除了字符串类型需要设置长度,其他类型都有默认长度....,权限n ON 数据库名.* FROM 用户名@IP; revoke select on mysql.* from Fox@localhost; -- 4.查看用户的权限:SHOW GRANTS FOR....ename,e2.ename FROM emp e1 LEFT JOIN emp e2 ON e1.mgr = e2.empno; 六、MySQL数据库练习题 单表练习 七、MySQL数据库密码修改
福哥答案2020-01-26: 2020-01-26:mysql8.0做了什么改进? 帐户管理增加了对角色的支持。 支持原子数据定义语句(atomic DDL)。 支持utf8mb4字符集。...MySQL 8.0的十大新特性 今天,让我们看一下MySQL8.0提升数据库管理员工作效率的十大改进。...7.原子DDL 8.更快、性能更好的Schema和Information Schema 9.角色管理 10.加密表空间中的REDO日志和UNDO日志都将被加密 1.临时表的改进 在MySQL5.7中,所有的临时表都被创建在一个叫...在MySQL8中,我们改进了磁盘格式来使得每个UNDO表有大量的UNDO段。 此外,现在默认为两个单独的UNDO表空间(而非InnoDB系统表空间(最小为2,大小动态变化))中创建UNDO段。...在MySQL 8.0中,我们通过为UNDO和REDO日志添加加密来完成此功能。 除此以外,还有很多改进我没有列完。 还有很多其他不错的功能。
一、虚拟列的发展 在早期的MySQL版本中,开发者通常需要为经常需要计算的字段创建额外的物理列,并在数据插入或更新时手动计算这些列的值。这种方法虽然可行,但它增加了数据冗余和应用程序的复杂性。...为了解决这个问题,MySQL 5.7版本引入了虚拟列(也称为生成列)的概念。虚拟列允许开发者在表中定义一个基于其他列的计算公式,而不需要实际存储这些计算的结果。...当查询虚拟列时,MySQL会根据公式动态计算其值。 在后续的版本中,MySQL进一步增强了虚拟列的功能,允许开发者选择是否将虚拟列的结果实际存储在磁盘上(即存储列),以提高查询性能。...总结 MySQL的虚拟列是一个强大而灵活的特性,它允许开发者在表中定义基于其他列的计算结果,而无需实际存储这些计算的值。...随着MySQL的不断发展,我们可以期待虚拟列在未来版本中继续得到增强和优化,为开发者提供更多便利和功能。在设计和优化数据库时,不要忘记考虑使用虚拟列来提高性能和简化应用程序逻辑。
广泛应用:PHP是广泛应用于Web开发的脚本语言。它可以与各种服务器软件(如Apache、Nginx等)以及大多数数据库(如MySQL、Oracle等)无缝集成,为构建动态网站提供了良好的支持。...良好的兼容性:PHP与各种操作系统(如Windows、Linux、Mac等)和数据库系统(如MySQL、PostgreSQL、SQLite等)兼容性良好。...通过采用安全编码实践,如输入验证、输出过滤和维护最新的PHP版本,可以确保PHP应用程序的安全性。PHP语言的发展趋势:更高的性能和卓越的扩展性: 近年来,PHP不断致力于提高性能和扩展性。...新的语法糖和语法改进:PHP 7引入了许多新的语法糖和语法改进,例如null合并运算符、太空船操作符、标量类型提示等。这些改进简化了开发人员的编码过程,并提供了更多的便利性和表达能力。...这些改进简化了开发人员的编码过程,提高了代码的可读性和表达能力。总结PHP语言的发展趋势是朝着更高的性能、更好的可扩展性、更强的类型支持和更好的安全性方向发展。
这是学习笔记的第 2228篇文章 读完需要 5 分钟 速读仅需3分钟 最近在改进一套环境的延迟问题,做了业务层的优化之后,问题得到了基本的解决,但是离我预想中的结果还是有距离,毕竟高峰期的延迟还是有20...于是乎,在最近的一次高可用改造中,我们借着这个机会对这套数据库进行了升级,原本是MySQL 5.7.16版本,通过复制的模式配置了MySQL 8.0.19的Slave....从第二天的数据来看,对于延迟的改进效果是很明显的,如下是近6天的数据延迟情况,我仅统计了数据处理中的延迟数据,最右边的是基于MySQL 8.0的writeset的模式,Slave的延迟情况。 ?...实际的数据都是1~4秒之内的延迟,而在前几天基于MySQL 5.7的模式基本延迟是在2~24秒之间。 当然抓取一天的数据进行分析,确实有些过急了,于是我又抓取了几天的数据。 ?...)如果需要回退到MySQL 5.7版本,是否有预案,预案如何设计?
领取专属 10元无门槛券
手把手带您无忧上云