09 2024 档案
摘要:今年秋招,面试官隔着电脑屏幕看着简历上“熟悉搭建过mysql集群,能排错”
对你说:在mysql集群中,一般是一主多从的方式,即一台mysql机器做公司业务的读,其他机器留给客户查询做负载均衡。
hr问你:“老板开了一家金融公司,他要求客户在频繁资金流动下,时刻要保证拿到最新数据,你也知道,mysql数据库是存在延迟的:主库更新后,从库数据要等一段时间才会改动,如果是你,你该怎么满足客户需求”
阅读全文
摘要:文章介绍了两种主备切换方式,并讨论了主库宕机后,备库接手,从库在binlog从哪里开始同步备库:一种基于位点的主备切换,一种基于GTID的切换
这篇文章最为重要的是介绍了一种业务突发情况
就是x库有了(1,1),x是y库的从库,y现在插入了(1,1),括号内左边的1是主键,这个时候系统报主键错误,你要怎么解决?
你要做的是找到Y插入(1,1)的GTID
命令:
show master status\G
或
show binlog events in 'mysql-bin.0000**';
接下来执行
set gtid_next='GTID编号';
begin;
commit;
set gtid_next=automatic;
start slave;
简直不要太完美
阅读全文
摘要:Docker 容器数据卷 三 挂载容器卷 后台示例 docker run -d -it --name web1 -v /data/web/:/usr/share/nginx/html/ -p 8080:80 nginx 前台示例 docker run -it --name myu -v /tmp/m
阅读全文
摘要:docker:镜像构建、仓库、压缩、导入 二 构建镜像:(无需网络) docker commit -m="描述" -a="作者" 容器id 镜像名:版本号 镜像仓库与推送镜像到仓库 docker push 镜像名:[tags] 压缩镜像: docker save 镜像名:版本号 #更推荐: dock
阅读全文
摘要:docker小白基础命令整理一 设置开机启动: systemctl enable docker 查看 docker 状态: systemctl status docker 列出本机所有的镜像: docker images 下载镜像: docker pull 镜像名 删除镜像: docker rmi
阅读全文
摘要:这篇文章分析备库延迟的原因:执行日志的速度持续低于主库生成日志的速度
分析了很多版本备库并行复制的策略,就是为了5.7版本做铺垫,只要知道5.7.22并行复制的三个策略COMMIT_ORDER(只有在多线程模式下,prepare后即可并发。无单线程优势),WRITESET(计算事务每行hash 值,组成集合 没操作相同的行,就并行。单线程优势),WRITESET_SESSION(在前面writest多了一个约束,使主备执行顺序相同,单线程压力模式下退化成单线程复制,感觉只有特定情况才用它)
阅读全文
摘要:为了让各位更好的了解文章,我归纳了下面几点最重要的:
1、MySQL 高可用系统的可用性,是依赖于主备延迟的。延迟的时间越小,主库故障的时候,服务恢复需要的时间就越短,可用性就越高。
2、主备延迟原因:备库用的机子不行(IOPS是和主库相同的,不要轻视备库)、备库压力太大,查询消耗了大量cpu(因为主库直接影响业务,大家用的克制,懂的都懂)、大事务(要是一个事务在主库执行10分钟,在备库那也得执行个10来分钟,这延迟不就来了)
3、主库备库切换策略有两个:可靠性(在切换中,主库备库将处于readonly状态,事务写不进去),可用性(直接主库备库秒切,但十分容易数据错乱,建议binglog用row格式)
哦,还有一个最重要的参数
命令:show slave status
你要看seconds_behind_master 的值,他是主备库的延迟时间,地位在高可用里面相当的重要
阅读全文
摘要:第二十三讲:MySQL是怎么保证主备一致的? 简概 开篇 在前面的文章中,我不止一次地和你提到了 binlog,大家知道 binlog 可以用来归档,也可以用来做主备同步,但它的内容是什么样的呢?为什么备库执行了 binlog 就可以跟主库保持一致了呢?今天我就正式地和你介绍一下它。 毫不夸张地
阅读全文
摘要:第二十二讲:MySQL是怎么保证数据不丢的? 简概 开篇 今天这篇文章,我会继续和你介绍在业务高峰期临时提升性能的方法。从文章标题“MySQL 是怎么保证数据不丢的?”,你就可以看出来,今天我和你介绍的方法,跟数据的可靠性有关。 在专栏前面文章和答疑篇中,我都着重介绍了 WAL 机制(你可以再回
阅读全文
摘要:文章提出了数据库在高并发高请求的情况下出现的一些性能问题,这里警示DB人员饮鸩止渴提高性能操作:应对短连接风暴,切掉空闲进程(部分事务回滚),max connect参数(过高有损性能),还有SQL语句本身原因,正如之前讨论过的索引:没设计、选错了、有,但没用上,以及应对QPS(单位时间查询)过高必须下掉功能时:白名单,用户删除,语句重写(要分环境,看公司运维规范程度)
阅读全文
摘要:该文章深刻揭示了一点:加索引=行锁+间隙锁=(next-key lock),分析了加锁的规则:对主键(唯一索引),普通非唯一索引进行等值与范围查询的加锁。这篇文章我认为收获最大的是让我们知道“明明对一行加了锁,为什么在他相邻部分,或是相相邻部分无法插入数据(这根主键类型,是单个还是范围查询有关,就算他的逻辑是一样的)”,值的一提的是事务的for update更新与delete加锁规则是一样的,这意味着在你在大量插入的业务下删除数据可能会导致“数据insert失败”,解决方式是加limit,减少间隙锁的范围。
阅读全文
摘要:文章以幻读起手,以假设的方式钻“加锁”的空子,引出“间隙锁”(也就是现在的mysql锁机制),但就算这样,在可重复读的隔离级别下也会发生死锁,即使对行锁有准确的认识,也可能会因为间隙锁翻车,像两个session同时占用一个主键(注意:与行锁不同,他没有锁之间的冲突)插入操作时都会被对方的间隙锁挡住(虽然很行锁很相似,但他们的加锁位置不同)
阅读全文
摘要:和上篇文章不同,文章探讨了我们正常执行sql语句慢的原因:第一:其他进程正在DML写锁,需要kill或等待,第二flush刷盘flush在关闭session途中被别的命令堵住了,进一步堵住select查询,如sleep,第三,在引擎层面update存在且不提交写锁也会被堵住(这边还介绍了kill query与kill的去别,十分实用),第四:查询慢还可以是索引:走主键顺序扫描(可以在慢查询日志里找),第五:就算只扫描一行,但还是慢,还可以是事务一直没提交,造成undolog回滚日志特别长,如果没有加“lock in share mode”,那读取数据得先回滚到上一个版本再读取。
阅读全文
摘要:该文章中,提出了”有很多看上去逻辑相同,但性能却差异巨大的 SQL 语句”提出索引树罢工的现象分析了三个原因:where后面函数操作,多表查询字段类型冲突,utf-8字符编码冲突(俗称隐式类型转换),正因如此索引就会罢工(explain中key显示NULL),这边还顺便介绍了驱动表(多表查询from后面的是被驱动表),最后要强调的是select * from table where id + 1 = 10000 这个 SQL 语句与select * from table where id = 10000-1(这道题体现文章核心思想) 两者间查询效率相差极大
阅读全文
摘要:
该文章承接上一篇order by排序,进一步提出随机挑选数据的问题,站在大量数据查询的情况下:提出select word from words order by rand() limit 3;这种我们经常使用的查询语句的弊端:既要建立临时表排序(这里优化器使用的rowid排序)而且如果表中有一万条数据,那么扫描行数高达2万零三条(虽然sort_buffer排序不涉及表操作,不扫描表,这里需要注意临时表,上一张没细讲,就是因为使用另一个引擎,先后从memory到innodb引擎读了1万条数据),此外,拓宽了上一张rowid主键的范围(也可以是系统建的默认递增主键),还有优先队列排序法也挺有意思(与归并排序算法区分下),为了解决上面随机查询的弊端,我们提出了随机排序算法(这里要注意数据空洞,不能用大小比较)利用变量,字符串拼接,预处理语句十分有意思
阅读全文

摘要:该文章简述了order by排序的两种策略,一个是全字段排序:将字段全部放到sort__buffer里面,在内存内部排序(内存要求高),另一个是rowid排序:将order后面的指定字段与ID一起扔到内存排序,但因为如果查询有其他字段,他会再次回到表进行一次主键索引(因此相对而言内存消耗更小),之后为了更加快速,我们想到了前面的覆盖索引(这样可以避免创建临时表,前面的两个策略都创建了临时表),大概就是建立联合索引将我们所要查询的字段全部包涵进去,而且这还免去的排序,快的一批,但这样会加重后续索引维护,各有利弊
阅读全文
摘要:第十四讲:答疑文章(一):日志和索引相关问题 简概: 到目前为止,我已经收集了 47 个问题,很难通过今天这一篇文章全部展开。所以,我就先从中找了几个联系非常紧密的问题,串了起来,希望可以帮你解决关于日志和索引的一些疑惑。而其他问题,我们就留着后面慢慢展开吧。 我在第 2 篇文章《日志系统:
阅读全文
摘要:第十三讲:count(*)这么慢,我该怎么办? 简概: count(*) 的实现方式 你首先要明确的是,在不同的 MySQL 引擎中,count() 有不同的实现方式。 MyISAM 引擎把一个表的总行数存在了磁盘上,因此执行 count() 的时候会直接返回这个数,效率很高; 而 InnoDB
阅读全文
摘要:第十二讲: 为什么表数据删掉一半,表文件大小不变? 简概: 问题:表删掉了一半的数据,表文件的大小还是没变? 经常会有同学来问我,我的数据库占用空间太大,我把一个最大的表删掉了一半的数据,怎么表文件的大小还是没变? InnoDB 的表回收 那么今天,我就和你聊聊数据库表的空间回收,看看如何解
阅读全文
摘要:目录第十讲:为什么我的MySQL会“抖”一下?图概:提出现实问题: SQL 执行的时候特别快,有时变得特别慢原因:为什么有时会“flush”呢?第一种场景,粉板满了,记不下了。第二种场景,要记住的事情太多,自己快记不住了,找账本把这笔账先加进去。第三种场景是,生意不忙,打烊之后柜台没事,掌柜闲着也是
阅读全文
摘要:欢迎来到我的友链小屋 所有友情站点,排列不分先后 友链信息 博客名称:guixiang博客网址:http://www.guixiang.fun博客头像:https://pic.cnblogs.com/avatar/1273193/20190806180831.png博客介绍:大道至简,知易行难。 j
阅读全文
摘要:第十讲:怎么给字符串字段加索引? 现在,几乎所有的系统都支持邮箱登录,如何在邮箱这样的字段上建立合理的索引,是我们今天要讨论的问题。 总概 类似邮箱登录系统的长表索引 假设,你现在维护一个支持邮箱登录的系统,用户表是这么定义的: mysql> create table SUser( ID big
阅读全文
阅读目录(Content)
此页目录为空