首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Linux 软件包下载加速工具:APT Proxy

Linux 软件包下载加速工具:APT Proxy

原创
作者头像
soulteary
发布于 2022-11-20 09:40:37
发布于 2022-11-20 09:40:37
4.7K0
举报

本篇文章将继续介绍这个仅有 2MB+ 身材大小的 Linux 软件包缓存和加速工具:APT Proxy。

相比老牌的 apt cacher ng 而言,除了尺寸更小、内存占用更低(10M以内)、它还拥有无需配置,开箱即用等特点。

写在前面

年中的时候,曾写过一篇文章《轻量小巧的零配置 APT 加速工具:APT Proxy》,当时介绍了我写的一款新工具 APT Proxy,2MB 的身材之下,可以为 UbuntuDebian 的软件下载提速。尤其是当你需要为多台设备更新和安装软件的时候,提升下载软件包的速度非常明显。

Apt Proxy 的概览页面
Apt Proxy 的概览页面

在文章和程序发布不久,群里有两位同学提出能否支持 CentOS 的下载加速,之后又有一位同学提出了能否支持 Alpine (容器世界亲儿子系统之一)。虽然口头答应了群友,但是因为最初设计只是为 Debian / Ubuntu 系统而写的,如果要支持其他系统,需要费一番功夫,加上事情比较多,这件事就搁置了下来。

临近年终,为了避免失信于人,我重构了 APT Proxy ,代码开源在 https://github.com/soulteary/apt-proxy,有需要的同学可以自取。(开源不易,欢迎一键三连。)

下面,我们来一起看看如何玩转 APT Proxy,来节约日常使用 Linux 下载软件包的时间。

基础使用

APT Proxy 支持两种方式运行,一种是直接运行“可执行文件”,另外一种是使用 Docker 来运行。至于使用哪一种,可以根据你的喜好,或者你要运行程序的机器状况而定。

我们先来聊聊第一种使用方式,因为关于 Docker 的使用方式,其实并没有什么不同。如果你是 Docker 爱好者,可以在阅读完本小节之后,移步文末“玩法五”。

你可以在 GitHub Release 页面 找到包含 32 位和 64 的 x86 或者 ARM 的可执行文件。我们根据设备的类型,下载好可执行文件之后,直接运行 ./apt-proxy 将能得到类似下面的日志:

代码语言:shell
AI代码解释
复制
2022/11/20 00:39:48 running apt-proxy 
2022/11/20 00:39:49 Start benchmarking mirrors
2022/11/20 00:39:49 Finished benchmarking mirrors
2022/11/20 00:39:49 using fastest Ubuntu mirror http://mirror.bjtu.edu.cn/ubuntu/
2022/11/20 00:39:49 Start benchmarking mirrors
2022/11/20 00:39:49 Finished benchmarking mirrors
2022/11/20 00:39:49 using fastest Debian mirror https://mirror.bjtu.edu.cn/debian/
2022/11/20 00:39:49 Start benchmarking mirrors
2022/11/20 00:39:49 Finished benchmarking mirrors
2022/11/20 00:39:49 using fastest CentOS mirror https://mirrors.bupt.edu.cn/centos/
2022/11/20 00:39:49 Start benchmarking mirrors
2022/11/20 00:39:49 Finished benchmarking mirrors
2022/11/20 00:39:49 using fastest Alpine mirror https://mirrors.tuna.tsinghua.edu.cn/alpine/
2022/11/20 00:39:49 proxy listening on 0.0.0.0:3142
2022/11/20 00:39:49 Program has been started 🚀

当我们看到 Program has been started 的字样时,说明程序已经正常运行起来了。从日志中可以看到,程序自动寻找了我们访问速度最快的各个操作系统的软件源。接下来,我们只需要在不同的操作系统中设置使用软件源为运行 APT Proxy 的这台设备的地址即可。

为了行文方便,我们暂定运行 APT Proxy 的这台设备 IP 为 10.11.12.90,如果你在上手试用,需要根据自己的实际情况,调整下文中的命令中的 IP 地址。

当然,如果我们想了解软件的运行状况,可以在浏览器中访问运行 APT Proxy 的设备的 IP + 3142 端口,比如: http://10.11.12.90:3142,就能够看到上文中的界面啦。

为 Ubuntu / Debian 进行缓存软件,加速 APT 下载

在不使用 APT Proxy 的时候,我们想要更新和安装软件(比如 vim),会使用下面的命令:

代码语言:shell
AI代码解释
复制
apt-get update
apt-get install vim -y

为了方便后边进行效果对比,我们在命令前添加一个 time 命令,来进行粗略的计时:

代码语言:shell
AI代码解释
复制
# time (apt-get update && apt-get install -y vim)

Get:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]
Get:3 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 Packages [522 kB]
Get:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [114 kB]
Get:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [99.8 kB]
...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...

real	0m20.639s
user	0m4.018s
sys	0m1.991s

在不对系统做任何调整(修改文件等)的前提下,我们可以通过简单改写命令,对系统下载的软件包的目标源进行自动替换,以及缓存下载过的软件包,加速这台和其他设备的软件包下载所需要使用的时间。

代码语言:shell
AI代码解释
复制
# `apt-get update` 改写
http_proxy=http://10.11.12.90:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true update 

# `apt-get install vim -y` 改写
http_proxy=http://10.11.12.90:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true install vim -y

在执行命令的时候,我们可以看到 Ubuntu / Debian 中的日志虽然展示数据下载地址还是“系统默认”的地址,但其实软件已经在后台自动将请求数据切换到了探测到的最快的下载镜像源上了,并对数据进行了缓存(为了方便对比速度提升,同样在命令开头添加一个 time 命令):

代码语言:shell
AI代码解释
复制
# time (http_proxy=http://10.11.12.90:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true update && http_proxy=http://10.11.12.90:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true install vim -y)
Get:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]
Get:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [114 kB]
Get:4 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 Packages [767 kB]
Get:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [99.8 kB]
...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...

real	0m22.596s
user	0m3.875s
sys	0m2.117s

这里因为软件会先将我们请求的数据进行缓存(磁盘写入)后,再提供给系统使用,所以首次使用的时候,在时间数据上有可能甚至会比直接在系统中执行软件包的下载安装要慢一些(比如这个例子中,要比原始请求慢 1~2s)。

在 APT Proxy 的日志中,我们能看到系统实际请求的外部资源,一旦程序发现资源在本地不存在(MISS)就会进行缓存,并根据资源类型设置不同时间的缓存有效期。

代码语言:shell
AI代码解释
复制
2022/11/20 14:07:58 rewrote "http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease" to "https://mirror.bjtu.edu.cn/ubuntu/dists/jammy/InRelease"
2022/11/20 14:07:58 rewrote "http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease" to "https://mirror.bjtu.edu.cn/ubuntu/dists/jammy-security/InRelease"
2022/11/20 14:07:58 10.11.12.90 "GET https://mirror.bjtu.edu.cn/ubuntu/dists/jammy-security/InRelease HTTP/1.1" (OK) 110337 MISS 88.932983ms
2022/11/20 14:07:58 rewrote "http://security.ubuntu.com/ubuntu/dists/jammy-security/universe/binary-amd64/by-hash/SHA256/332b5fd83a61f44ad15bc053370645ff347d7e29d6fbc12189602929bb25884c" to "https://mirror.bjtu.edu.cn/ubuntu/dists/jammy-security/universe/binary-amd64/by-hash/SHA256/332b5fd83a61f44ad15bc053370645ff347d7e29d6fbc12189602929bb25884c"
2022/11/20 14:07:59 10.11.12.90 "GET https://mirror.bjtu.edu.cn/ubuntu/dists/jammy/InRelease HTTP/1.1" (OK) 270087 MISS 203.295175ms
2022/11/20 14:07:59 rewrote "http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease" to "https://mirror.bjtu.edu.cn/ubuntu/dists/jammy-updates/InRelease"
...

重点来了,当我们为这台 Ubuntu 设备或者其他新设备执行相同命令的时候,如果软件的缓存没有过期,那么我们的下载速度将会得到质的提升(相比上文中,时间缩短到原本的 1/3,数据下载量越大,效果会越明显):

代码语言:shell
AI代码解释
复制
# time (http_proxy=http://10.11.12.90:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true update && http_proxy=http://10.11.12.90:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true install vim -y)
Get:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]
Get:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [114 kB]
...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...

real	0m6.485s
user	0m3.558s
sys	0m1.841s

Debian 系统和 Ubuntu 系统的使用方面基本没有区别,这里就不做重复展开啦。

目前,经过测试验证的操作系统有:Ubuntu 16.04、Ubuntu 18.04、Ubuntu 22.04、Debian 10(buster)、Debian 11(bullseye)。

为 CentOS 系统进行软件包下载加速

在这次的更新中,APT Proxy 支持了 CentOS 的软件包加速和缓存,分别支持 CentOS 7 和 CentOS 8。

在 CentOS 7 中,我们需要先使用下面的命令,对系统的软件源进行调整:

代码语言:shell
AI代码解释
复制
cat /etc/yum.repos.d/CentOS-Base.repo | sed -e s/mirrorlist.*$// | sed -e s/#baseurl/baseurl/ | sed -e s#http://mirror.centos.org#http://10.11.12.90:3142# | tee /etc/yum.repos.d/CentOS-Base.repo

而在 CentOS 8 中,命令需要调整为下面这样:

代码语言:shell
AI代码解释
复制
sed -i -e"s#mirror.centos.org#10.11.12.90:3142#g" /etc/yum.repos.d/CentOS-*
sed -i -e"s/#baseurl/baseurl/" /etc/yum.repos.d/CentOS-*
sed -i -e"s#\$releasever/#8-stream/#" /etc/yum.repos.d/CentOS-*

在完成软件源的调整后,我们执行 yum update && yum install -y vim 就可以享受自动选择最快的软件源,以及局域网中其他设备的软件包下载提速啦。

为 Alpine 系统进行软件包下载加速

在这次的 APT Proxy 软件版本更新中,也支持了 Alpine 的软件包加速和缓存,支持 Alpine 全系列的加速。

在 3.13 版本及以上,我们使用下面的命令,调整软件源对系统进行加速:

代码语言:shell
AI代码解释
复制
cat /etc/apk/repositories | sed -e s#https://.*.alpinelinux.org#http://10.11.12.90:3142# | tee /etc/apk/repositories

然后执行 apk add vim 即可完成软件的下载和缓存。

在 3.13 版本一以下的系统中,我们需要使用下面的命令调整软件源:

代码语言:shell
AI代码解释
复制
cat /etc/apk/repositories | sed -e s#http://.*.alpinelinux.org#http://10.11.12.90:3142# | tee /etc/apk/repositories

并在执行 apk add 之前,先执行 apk update 刷新系统的软件包索引文件,再执行 apk add vim 来完成我们想要安装的软件的下载。

聊过了基础使用,下面来聊聊日常开发、学习过程中,APT Proxy 的一些玩法。

玩法一:为本地容器中的 Linux 操作系统加速

日常进行软件开发的过程中,我会经常使用跑在容器里的 Linux 操作系统,比如上面提到的 Ubuntu、Debian、Alpine、CentOS,在构建产物镜像的时候(尤其是调试最小尺寸的 Docker 镜像时),经常会重复下载一些软件包,这个时候,使用 APT Proxy 就能够节约大量的时间

那么,如果我们是在主机上启动的 APT Proxy,在同一台主机运行的容器除了直接像上文一样,访问主机的物理 IP 之外,有没有什么更简单的访问方式呢?尤其是主机是笔记本这类在办公室和家里 IP 会变化的设备。

如果我们的容器是在 APT Proxy 所在的主机上运行的,可以通过访问 http://host.docker.internal:3142 这个 Docker 的“魔术地址”,来替换上文中的 10.11.12.90 这类或许会出现变化的地址。

比如,我们运行了某个基于 Linux 的应用镜像之后(docker run --rm -it ubuntu:22.04 bash),将上文中的命令替换为下面这样:

代码语言:shell
AI代码解释
复制
http_proxy=http://host.docker.internal:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true update && http_proxy=http://host.docker.internal:3142 apt-get -o pkgProblemResolver=true -o Acquire::http=true install vim -y

玩法二:为局域网中多台 Linux 设备加速

许多朋友和我一样,家里、公司都有许多设备(物理机、虚拟机云服务器),这些设备的日常维护中,有一项就是在设备上批量执行类似 apt update && apt upgrade -y 来升级系统。即时命令能够批量远程执行,但是机器数量一多,软件下载的时间成本也不低。

所以,如果我们在局域网其中的一台设备上运行了 APT Proxy,就可以和上文中一样,在其他的设备中通过调整软件源、或者改写软件包下载命令,来获得非常快速的重复的软件包的下载,节约维护设备软件包所需要的时间。

类似的思路,其实 WindowsMacOS 也都有,Linux 中这块做的比好的软件是 Nexus,我在早些时候,有分享过《使用 Docker 搭建私有软件仓库 Nexus 3》等内容,感兴趣的同学可以自行翻阅。不过,APT Proxy 在这个场景下,拥有绝对的优势,不需要 Nexus 几百 MB 的容器大小,以及运行起来大几百 MB 、甚至上 GB 的内存占用,只需要 2MB 的身材,以及最多十来 MB 的内存使用。

玩法三:自动寻找最快的软件源

在玩 Linux 的过程中,Ubuntu 、Alpine 的软件用户经常会羡慕 CentOS 用户,因为 CentOS 拥有一个神奇的插件:Fastest Mirror,会自动选择最快的软件源,来节约用户下载软件包的时间。

Ubuntu、Alpine 用户们,想要达到相同的效果,除了要收集可以用的软件源之外,还得挨着测试哪个软件源对自己来说性价比更高,着实麻烦。

APT Proxy 内置了各种操作系统中的官方的软件源,以及加上了国内常用,但可能没有被操作系统官方收录的软件源。在启动的时候会自动进行速度探测,然后进行选取。如果你像上文一样,将系统软件源切换到了 APT Proxy 的服务地址,那么软件下载的时候,将自动切换到最快的地址,避免了上面的“麻烦”的过程。

你可能会好奇,是否有自动选择软件源的必要,其实是有的。因为在不同的时间段,我们知道的软件源的实时负载是不同的,我们的网络运营商也可能会对我们的网络进行动态的线路调整,自动选择服务器能够让我们避开“排队”,以及少绕弯路,选择此时此刻对我们来说最佳的选择。

玩法四:指定自己想用的软件源

多数场景下,不对 APT Proxy 进行设置,让它使用自动选择出来的软件源就足够使用了。但是,如果你只信任某些软件源,也可以通过参数来进行手动干预,甚至相比一些软件,你可以手动分别定制 Ubuntu、Debian、CentOS、Alpine 的软件源:

代码语言:shell
AI代码解释
复制
./apt-proxy --ubuntu=cn:ustc --debian=cn:huaweicloud --centos=cn:aliyun --alpine=cn:tsinghua

在软件执行之后,我们可以看到类似下面的提示,告诉我们指定的软件源设置成功与否:

代码语言:shell
AI代码解释
复制
2022/11/20 16:02:34 running apt-proxy 
2022/11/20 16:02:34 using specify Ubuntu mirror http://mirrors.ustc.edu.cn/ubuntu/
2022/11/20 16:02:34 using specify Debian mirror http://mirrors.huaweicloud.com/debian/
2022/11/20 16:02:34 using specify CentOS mirror http://mirrors.aliyun.com/centos/
2022/11/20 16:02:34 using specify Alpine mirror http://mirrors.tuna.tsinghua.edu.cn/alpine/
2022/11/20 16:02:34 proxy listening on 0.0.0.0:3142
2022/11/20 16:02:34 Program has been started 🚀

当然,如果你发现某些软件源的访问质量不高,重新启动 APT Proxy,让它进行自动选择,或者你换一个指定的源头就好啦,反正也没有什么成本。

你可以在 soulteary/apt-proxy/tree/main/internal/define 中找到程序内置的官方认可或者国内比较知名的,相对稳定的软件源地址,它们的根域名名称,就是能够使用的“加速别名”,比如 mirrors.tuna.tsinghua.edu.cn 的别名就是去掉域名类型 edu.cntsinghua

玩法五:搭配容器做一个“干净又卫生”的临时加速器

APT Proxy 运行起来,默认会将缓存的文件保存在程序运行目录下的 .aptcache 目录,如果我们使用容器来运行它,不将这个目录进行“数据持久化”,以及在 Docker 运行容器的参数中添加上 --rm ,当我们停止或者重启容器的运行时,APT Proxy 的缓存也就被自动清理啦,不必担心经年累月在磁盘上残留的各种“过时”数据。

至于如何低成本定时清理数据,或许你可以参考上一篇分享的内容《使用 Docker 和 Traefik 搭建轻量美观的计划任务工具》中提到的工具。

代码语言:shell
AI代码解释
复制
# 建议始终执行命令,尝试下载更新软件新版本
docker pull soulteary/apt-proxy:latest
docker run --rm -d --name apt-proxy -p 3142:3142 soulteary/apt-proxy

如果你希望数据能够被持久化,那么可以调整命令,将数据目录挂载出来:

代码语言:shell
AI代码解释
复制
docker run --rm -d --name apt-proxy -p 3142:3142 -v `pwd`/.aptcache:/.aptcache soulteary/apt-proxy

使用方法和上文中提到的没有差别,就不再赘述啦。

最后

好啦,这篇文章就先写到这里。如果你在使用 APT Proxy 的过程中遇到了问题,欢迎反馈。

希望这个小工具,能够让你变的更“懒”一些。

--EOF



本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议,欢迎转载、或重新修改使用,但需要注明来源。 署名 4.0 国际 (CC BY 4.0)

本文作者: 苏洋

创建时间: 2022年11月20日

统计字数: 10463字

阅读时间: 21分钟阅读

本文链接: https://soulteary.com/2022/11/20/linux-package-download-acceleration-tool-apt-proxy.html

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
Mysql参数innodb_thread_concurrency
InnoDB使用操作系统线程来处理用户的事务请求。(在事务提交或回滚之前可能给InnoDB引擎带来很多的请求)。在现代化操作系统和多核处理器的服务器上,上下文切换是非常高效的,大多数工作负载运行没有任何并发线程数量的限制。在MySQL 5.5及以上版本中,MySQL做了可伸缩性的改进,它减少了这种在InnoDB内部限制并发执行线程数量的需要。
mingjie
2022/05/12
2.1K0
Mysql参数innodb_thread_concurrency
故障分析 | innodb_thread_concurrency 导致数据库异常的问题分析
作者通过分析源码定位数据库异常,梳理参数 innodb_thread_concurrency 设置的注意事项。
爱可生开源社区
2023/05/22
7110
Mysql重要参数说明
1)mysql double write buffer参数详解 什么是double write buffe?参数innodb_doublewrite=1打开 us_card_online_mysql [(none)] [15:03:01]> show global variables like '%innodb_doublewrite%'; +--------------------+-------+ | Variable_name | Value | +--------------------+
MySQL轻松学
2018/03/09
1.7K0
innodb核心配置总结---官方文档阅读笔记
-- 每个表单独文件和单独表空间,而不是放在系统表空间,每个表的文件表空间允许操作系统在表被截断或删除时回收磁盘空间。每表文件表空间还支持动态和压缩行格式以及相关功能
丿丶MySQL灬灬
2021/10/25
1.2K0
MySQL My.cnf参数梳理与延伸 (MYSQL 8 INNODB 类)
在MySQL8 innodb 参数中有一些需要在在重新梳理,发现一些新版本的添加的参数,更新知识,也将老的知识在重新唤醒。
AustinDatabases
2023/11/20
5480
MySQL My.cnf参数梳理与延伸 (MYSQL 8 INNODB 类)
MySQL 大量sleeping before entering InnoDB 故障诊断
某天下班回家开发给我打电话,反馈MySQL中的一张表被锁了,让我帮他解锁。我一想发生锁了,肯定是某个业务没有及时提交或者有人做了修改没提交。于是我让他把表名以及SQL发给我,我好排除
用户1278550
2019/03/15
1.6K0
mysql 谈谈innodb存储引擎
5.7版本引入了模式自动转换的功能,但该语法依然保留了。 另外一个有趣的点是,在5.7版本中,你可以通过设置session_track_transaction_info变量来跟踪事务的状态,这货主要用于官方的分布式套件(例如fabric),例如在一个负载均衡系统中,你需要知道哪些 statement 开启或处于一个事务中,哪些 statement 允许连接分配器调度到另外一个 connection。只读事务是一种特殊的事务状态,因此也需要记录到线程的Transaction_state_tracker中。 关于Session tracker,可以参阅官方WL#6631。 START TRANSACTION READ WRITE 和上述相反,该SQL用于开启读写事务,这也是默认的事务模式。但有一点不同的是,如果当前实例的 read_only 打开了且当前连接不是超级账户,则显示开启读写事务会报错。 同样的事务状态TX_READ_WRITE也要加入到Session Tracker中。另外包括上述几种显式开启的事务,其标记TX_EXPLICIT也加入到session tracker中。 读写事务并不意味着一定在引擎层就被认定为读写事务了,5.7版本InnoDB里总是默认一个事务开启时的状态为只读的。举个简单的例子,如果你事务的第一条SQL是只读查询,那么在InnoDB层,它的事务状态就是只读的,如果第二条SQL是更新操作,就将事务转换成读写模式。 START TRANSACTION WITH CONSISTENT SNAPSHOT 和上面几种方式不同的是,在开启事务时还会顺便创建一个视图(Read View),在InnoDB中,视图用于描述一个事务的可见性范围,也是多版本特性的重要组成部分。 这里会进入InnoDB层,调用函数innobase_start_trx_and_assign_read_view,注意只有你的隔离级别设置成REPEATABLE READ(可重复读)时,才会显式开启一个Read View,否则会抛出一个warning。 使用这种方式开启事务时,事务状态已经被设置成ACTIVE的。 状态变量TX_WITH_SNAPSHOT会加入到Session Tracker中。 AUTOCOMMIT = 0 当autocommit设置成0时,就无需显式开启事务,如果你执行多条SQL但不显式的调用COMMIT(或者执行会引起隐式提交的SQL)进行提交,事务将一直存在。通常我们不建议将该变量设置成0,因为很容易由于程序逻辑或使用习惯造成事务长时间不提交。而事务长时间不提交,在MySQL里简直就是噩梦,各种诡异的问题都会纷纷出现。一种典型的场景就是,你开启了一条查询,但由于未提交,导致后续对该表的DDL堵塞住,进而导致随后的所有SQL全部堵塞,简直就是灾难性的后果。 另外一种情况是,如果你长时间不提交一个已经构建Read View的事务,purge线程就无法清理一些已经提交的事务锁产生的undo日志,进而导致undo空间膨胀,具体的表现为ibdata文件疯狂膨胀。我们曾在线上观察到好几百G的Ibdata文件。 TIPS:所幸的是从5.7版本开始提供了可以在线truncate undo log的功能,前提是开启了独立的undo表空间,并保留了足够的 undo 回滚段配置(默认128个),至少需要35个回滚段。其truncate 原理也比较简单:当purge线程发现一个undo文件超过某个定义的阀值时,如果没有活跃事务引用这个undo文件,就将其设置成不可分配,并直接物理truncate文件。 事务提交 事务的提交分为两种方式,一种是隐式提交,一种是显式提交。 当你显式开启一个新的事务,或者执行一条非临时表的DDL语句时,就会隐式的将上一个事务提交掉。另外一种就是显式的执行“COMMIT” 语句来提交事务。 然而,在不同的场景下,MySQL在提交时进行的动作并不相同,这主要是因为 MySQL 是一种服务器层-引擎层的架构,并存在两套日志系统:Binary log及引擎事务日志。MySQL支持两种XA事务方式:隐式XA和显式XA;当然如果关闭binlog,并且仅使用一种事务引擎,就没有XA可言了。 关于隐式XA的控制对象,在实例启动时决定使用何种XA模式,如下代码段: if (total_ha_2pc > 1 || (1 == total_ha_2pc && opt_bin_log)) { if (opt_bin_log) tc_log= &mysql_bin_log; else tc_log= &tc_log_mmap; }
Java架构师历程
2018/09/26
1.8K0
mysql 谈谈innodb存储引擎
Mysql配置文件的理解
#[mysqld_multi] #mysqld=/usr/local/mysql/bin/mysqld_safe #mysqladmin=/usr/local/mysql/bin/mysqladmin #user=root #log=/data/mysqllog/multi.log [mysqld] explicit_defaults_for_timestamp=true #意思是为timestamp类型的列明确的注明default值。 # tmp for mysql load data infile,l
小俊丶Eternally
2018/05/11
8.7K2
Mysql配置文件的理解
Mysql升级及配置优化
[mysqld]下配置explicit_defaults_for_timestamp=true,这是相对于5.6需要添加的一个配置,具体参考https://www.jianshu.com/p/d7d364745173
kiki.
2022/09/29
1.1K0
Mysql升级及配置优化
性能优化-MySQL性能优化参数
对配置参数的说明: 配置参数的格式如下:(shell > mysqladmin -uroot -ppassword variables extended-status)
cwl_java
2020/02/13
7K0
Mysql优化
1 . 优化不总是对一个单纯的环境进行!还很可能是一个复杂的已投产的系统。优化手段本来就有很大的风险,只不过你没能力意识到和预见到!
iginkgo18
2021/06/21
1.6K0
资源丨MySQL故障排查思路方法PPT&视频&24问答
昨晚,墨天轮邀请到MySQL技术顾问崔虎龙做了题为《一小时掌握MySQL故障排查思路方法》的直播分享,引起了大家的广泛关注,直播后很多小伙伴来找小编询问PPT、思维导图、视频等,在这里小编火速整理了一下PPT和视频,并就24个典型问题请讲师做了解答,分享至此供大家参考学习。
数据和云
2020/06/09
8720
mysql innodb_trx参数详解
1、innodb_trx表提供了当前innodb引擎内每个事务的信息(只读事务除外),包括当一个事务启动,事务是否在等待一个锁,以及交易正在执行的语句(如果有的话)。查询语句:
用户14527
2022/03/24
4.3K0
mysql全配置解析
在本文中,我们将深入解析MySQL配置文件,以及每个配置项的作用和优化建议。从基本设置、连接设置、缓存设置、日志设置、InnoDB设置到其他设置,我们将逐一讨论如何通过调整这些参数来提升MySQL性能。
默 语
2024/11/20
2720
Mysql配置文件 innodb引擎(下)
在之前的版本里,如果一台高负荷的机器重启后,内存中大量的热数据被清空,此时就会重新从磁盘加载到Buffer_Pool缓冲池里,这样当高峰期间,性能就会变得很差,连接数就会很高。
陈不成i
2021/06/11
1.6K0
MySQL实战第二十九讲-如何判断一个数据库是不是出问题了?
在 第25 和 第27 篇文章中,和你介绍了主备切换流程。通过这些内容的讲解,你应该已经很清楚了:在一主一备的双 M 架构里,主备切换只需要把客户端流量切到备库;而在一主多从架构里,主备切换除了要把客户端流量切到备库外,还需要把从库接到新主库上。
越陌度阡
2022/05/06
4920
MySQL实战第二十九讲-如何判断一个数据库是不是出问题了?
Mysql优化系列(1)--Innodb引擎下mysql自身配置优化
1.简单介绍 InnoDB给MySQL提供了具有提交,回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要,因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中,你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来,甚至在同一个查询中也可以混合。 2.之所以选用innodb作为存储引擎的
洗尽了浮华
2018/01/23
2.6K0
MySQL CPU性能定位
墨墨导读:经常会看到看到cpu 使用率非常高的情况。在这种情况下,资源的使用监控分析才是性能故障分析的根本首要任务,通过这些分析,理解服务器如何运行,资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的。
数据和云
2020/07/03
1.4K0
MySQL性能调优 – 你必须了解的15个重要变量
1.DEFAULT_STORAGE_ENGINE 如果你已经在用MySQL 5.6或者5.7,并且你的数据表都是InnoDB,那么表示你已经设置好了。如果没有,确保把你的表转换为InnoDB并且设置default_storage_engine为InnoDB。 为什么?简而言之,因为InnoDB是MySQL(包括Percona Server和MariaDB)最好的存储引擎 – 它支持事务,高并发,有着非常好的性能表现(当配置正确时)。 2.INNODB_BUFFER_POOL_SIZE 这个是InnoDB最
老七Linux
2018/05/31
4.2K0
MySQL 5.7优化
MySQL 5.7 提供了众多参数用于优化数据库性能,具体优化取决于你的硬件资源、应用需求、查询模式以及数据规模。下面将从InnoDB存储引擎、查询缓存、连接管理、日志与事务、内存管理、并发控制等几个方面详细介绍可优化的参数及其推荐值。
九转成圣
2025/02/20
2510
推荐阅读
相关推荐
Mysql参数innodb_thread_concurrency
更多 >
LV.0
这个人很懒,什么都没有留下~
目录
  • 写在前面
  • 基础使用
    • 为 Ubuntu / Debian 进行缓存软件,加速 APT 下载
    • 为 CentOS 系统进行软件包下载加速
    • 为 Alpine 系统进行软件包下载加速
  • 玩法一:为本地容器中的 Linux 操作系统加速
  • 玩法二:为局域网中多台 Linux 设备加速
  • 玩法三:自动寻找最快的软件源
  • 玩法四:指定自己想用的软件源
  • 玩法五:搭配容器做一个“干净又卫生”的临时加速器
  • 最后
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档