程序天地

前言 此前一直在使用 mysqlshell 来备份部署在 k8s 上的 MySQL，虽然这个工具比起 mysqlpump 来说要快很多，支持多线程、可以直接备份到远程 s3 等，但是后面使用过程中也陆陆续续发现了一些问题： CPU 占用过高 由于开启了多个核来并行执行提升速度，所以每次执行备份的时候 CPU 只能在凌晨时间，这样极端情况下可能会导致丢失一天的数据。 无法增量备份 每次备份的时候都是全量备份，这样也会导致备份的数据占用空间过大。 恢复数据慢 由于 mysqlshell 备份的数据是逻辑备份，所以恢复数据的时候会很慢。如果另外两个问题还是可以忍受的话，这个问题是无法忍受的。比如在进行服务器迁移的时候，系统恢复的时间就会很长。 使用 xtrabackup 之前也曾调研过 xtrabackup，xtrabackup，强大的 MySQL 备份工具，但是由于 k8s 下的 MySQL 是使用的 PVC，所以无法直接使用 xtrabackup 来备份。后面实在忍受不了 mysqlshell 的问题，所以又重新研究了一下，最终找到了一个比较完美的解决方案。 打包一个基础镜像 Dockerfile 这个 Dockerfile 里面安装了 xtrabackup 和 rclone，rclone 是一个支持多种对象存储的命令行工具，可以用来将备份的数据上传到对象存储等。然后启动的时候会执行 entrypoint.sh，这个脚本会启动一个 cron 定时任务，每小时执行一次 backup.sh，这个脚本会根据是否存在全量备份来执行全量备份或者增量备份，然后将备份的数据上传到对象存储。 FROM ubuntu RUN apt update && \ apt install -y wget cron lsb-release curl gnupg2 zstd unzip && \ wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb && \ dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb && \ apt update && \ percona-release enable-only tools release && \ apt update && \ apt install percona-xtrabackup-80 -y && \ rm -rf percona-release_latest.$(lsb_release -sc)_all.deb RUN curl https://rclone.org/install.sh | bash COPY backup.sh /backup.sh COPY entrypoint.sh /entrypoint.sh RUN chmod +x /backup.sh && chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] backup.sh 这个脚本执行了实际的备份操作，备份的数据会存放在 /backup 目录下，然后会将备份的数据同步到 s3 上。 ...

前言 一直在寻找一个最适合自己的 MySQL 备份方案，毕竟数据无价，来来去去也使用了很多种方案，在此记录一下。 使用云数据库 这是最省心的方案了，云数据库比如阿里云的 RDS，腾讯云的云数据库都自带了备份功能，完全不用自己操心，但是这种方案的缺点也很明显，就是价格太贵了，对于个人开发者来说，成本还是太高了，同配置的云数据库比服务器要贵很多。 之前也用了腾讯云最低配置的云数据库，一个月要一百多，放弃了。 自建 MySQL 主从 之前也尝试了在阿里云买了两台轻量服务器组了主从数据库，也用了一段时间，虽然很便宜，但是实际用起来还是有一些问题。 阿里云轻量服务器的磁盘性能很低，不适合搭建数据库，所以我组了主从并且搭配 proxysql 来做读写分离。 阿里云轻量服务器的磁盘太小，后面数据量多了之后，磁盘空间就不够用了，而升级更高配置的话成本又变高了。 使用廉价 VPS 加 mysqlpump 有很多小的 VPS 商家卖的 VPS 比起大厂的更便宜，而且性能更高，但是缺点就是没有大厂稳定，而且有丢失数据的风险，所以定时备份数据就很重要。 之前我使用的是 mysqlpump 加定时任务的方式，为此我还专门写了个项目 https://github.com/long2ice/databack，将备份的数据上传到对象存储，但是后面发现这个方案也有问题，就是数据量大了以后不论是备份或者上传到对象存储花费的时间都很长，更不用说恢复数据的时间了，完全没办法使用在生产环境。 使用廉价 VPS 加 xtrabackup 这是我最终使用的方案，使用 xtrabackup 备份数据，然后上传到对象存储。xtrabackup 备份数据非常快，它是基于物理备份的，并且备份的时候不会影响到线上数据库。同时它也支持增量备份，这样除了第一次上传全量备份的时候会花费一些时间，后面的备份都会很快。 贴一下使用的脚本： #!/bin/bash # 备份函数 function backup() { cp /etc/mysql/mysql.conf.d/mysqld.cnf ./ # 检查备份目录是否存在 if [ ! -d "./backups" ]; then mkdir ./backups fi # 检查是否存在全量备份 if [ -z "$(ls -A ./backups)" ]; then # 执行全量备份命令 xtrabackup --backup --compress=zstd --target-dir=./backups/base echo "全量备份完成。" else # 执行增量备份命令 xtrabackup --backup --compress=zstd --target-dir=./backups/inc-$(date '+%Y-%m-%d_%H:%M:%S') --incremental-basedir=$(ls -d ./backups/* | tail -n 1) echo "增量备份完成。" fi rclone sync /root/backup/mysql greencloud:/backup/mysql/prod } # 恢复函数 function restore() { # 遍历备份目录解压缩 for d in backups/*/; do xtrabackup --decompress --target-dir=$d done # 准备恢复 for d in backups/*/; do if [ $d == "backups/base/" ]; then xtrabackup --prepare --apply-log-only --target-dir=$d else # if is last dir if [ $d == $(ls -d backups/*/ | tail -n 1) ]; then xtrabackup --prepare --target-dir=./backups/base --incremental-dir=$d else xtrabackup --prepare --apply-log-only --target-dir=./backups/base --incremental-dir=$d fi fi done # 执行恢复 xtrabackup --copy-back --target-dir=./backups/base echo "恢复完成。" } case "$1" in backup) backup ;; restore) restore ;; *) echo "Usage: $0 {backup|restore}" ;; esac 完事之后直接 crontab 挂一个定时任务就 OK 了。 ...

前言 在我的个人项目中很多地方都使用到了 meilisearch，之前也写了一篇博客介绍了一下 meilisearch 的使用，可以参考一下：MeiliSearch，一个轻量级搜索引擎。 之前的话就简单粗暴地其了一个定时任务，每隔一段时间就从数据库中同步一次数据到 meilisearch，这样的话就会有一些问题： 数据不实时。 每次都是全量同步，效率很低。 所以希望能有一个能实时增量同步数据库，类似 MySQL 的，到 meilisearch 的工具。在 GitHub 上搜了一圈，发现没有什么好用的，于是打算自己写一个。 项目地址 https://github.com/long2ice/meilisync, 命令行版本。 https://github.com/long2ice/meilisync-admin，在命令行版本的基础上，增加了一个 web 管理界面，可以动态添加同步任务，查看同步状态等。 预览 技术栈 前端：React + daisyui 后端：FastAPI + TortoiseORM + MySQL 架构 目前支持三种数据库： MySQL，使用 binlog 来实现。 PostgreSQL，使用 logical replication 来实现。 MongoDB，使用 change stream 来实现。 最初的版本只是实现了命令行的功能，通过加载配置文件，然后启动一个进程，然后通过 binlog 类似的技术来实现实时地增量同步。 更进一步 命令行版本可以满足基本的需求，但是还是有一些不足的地方： 修改配置需要重启。 无法动态添加同步任务。 只支持单实例。 于是在命令行版本的基础上，增加了一个 web 管理界面，可以动态添加同步任务，查看同步状态，以及增加了登录功能。 遇到的问题 遇到错误如实例连不上，重启进程之类的会丢失数据。 全量刷新数据的实时不能影响线上业务。 MySQL binlog 连接长时间后丢失。 以及一些其他的问题。

起因 因为有存储图片的需求，所以一直在寻找一种可靠的自建图床的方式，也尝试了很多种方案。 使用 Minio + 大盘鸡自建 优点：免费，开源。 缺点：需要自己维护，如果经常迁移服务器很不方便，另外如果需要存储大量图片的话，需要大硬盘机器。目前能找到最便宜的是 1TB 硬盘的机器，价格是 5 刀一个月。 使用 Wasabi 日本区域 优点：7 刀一个月，1TB 存储空间和 1TB 流量，速度还可以。 缺点：感觉还是有点贵。 使用 Vultr 对象存储新加坡区域 优点：5 刀一个月，1TB 存储空间和 1TB 流量。 缺点：新加坡国内访问还是有点慢。 B2 云存储 没尝试，也是 5 刀一个月，1TB 存储空间和 1TB 流量，不过没有国内访问速度好点的节点。 方案选择 不考虑国内对象存储+CDN 的方式一个是价格太贵，另一个是有很多被 DDOS 然后产生天价账单的案例。 刚好最近迁移到了腾讯云香港轻量，老实说，尝试了各种商家的 VPS，各个地区包括美西、日本，最后还是选择了更稳定的大厂。 然后腾讯云香港轻量内网访问同区域 COS 是不收费的，另外直接暴露 COS 有被刷流量风险，所以最终选择通过轻量服务器中转的方式。 目前轻量上行限制 30M，暂时也够用了。 费用 COS 的存储费用还是很低的，请求费用也比较低，贵的是流量费用，所以通过轻量服务器中转的方式也比较便宜。 后续看需求吧，如果费用太高的话，也会考虑买一台香港大盘鸡进行自建。 中转方案 因为目前服务器使用的是 Caddy，使用 https://github.com/lindenlab/caddy-s3-proxy 这个插件可以直接代理 S3，而 COS 也兼容 S3。 后续更新 发现腾讯云香港轻量稳定倒是很稳定，但是磁盘 IO 太拉了，动不动 100% 然后机器都 ssh 不上去，果断退款了。目前继续使用 Minio 自建。 ...

如果您在使用过程中有问题请留言或发邮件我。 邮箱地址：long2ice@gmail.com 谢谢! If you have any questions, please leave a message or send me an email. Email：long2ice@gmail.com Thank you!