MySQL

前言 此前一直在使用 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 连接长时间后丢失。 以及一些其他的问题。

项目地址 https://github.com/long2ice/synch mysql2ch mysql2ch 从二月份开始到现在已经接近四个月，项目起初是源于公司的需求，同步 MySQL 的数据到 ClickHouse 进行分析与统计。当时调研了一圈，发现并没有符合需求的项目，只找到一个勉强可用的，于是在该项目之上进行开发与完善。 synch mysql2ch 项目改名为 synch，其主要原因在于 mysql2ch 支持了 postgres 的同步，再取名为 mysql2ch 就有些不合适了，遂改名为 synch，意思是同步到 ClickHouse，其项目目标是同步其它类型的数据库到 ClickHouse 中。 当前架构 设计与实现 最开始的版本非常简陋，只是实现了监听 mysql binlog 然后直接插入到 ClickHouse。在后续的开发与迭代中，逐渐实现了以下功能，以及引入了中间件。 命令行 命令行对于一个独立程序是有必要的。命令行程序可以接受自定义的参数，通过在程序指定不同的参数，可以使用其不同的功能，对于那些需要每次启动都可能会不同的参数，将其放在命令行参数中是有必要的。 配置文件 丰富的配置项可以将程序的自定义配置暴露出来，以满足个性化的运行需求，增强程序的自定义性。 模块分离 该项目分为三个模块，除了源数据库与目标数据库，也就是 ClickHouse 之外，包含生产端、消息队列、消费端。模块的分离是为了解耦，各个模块专注于自身的功能实现以及可靠性。以及借助于消息队列，实现分布式消费。 消息队列 消息队列的引入是为了增加程序的健壮性以及增加生产与消费的性能。通过引入消息队列，将 binlog 先缓冲到消息队列中而不是直接插入到 ClickHouse，避免了当程序崩溃时内存数据的丢失。并且借助于消息队列的 ack 机制，可以保证消息的可靠消费；以及借助消息队列的高吞吐量，将消费者与生产者分离，生产者与消费者之间互不影响，异步工作。 另外一点考虑到 binlog 的有序性，消息队列的选型也是需要考虑的，目前选择了 kafka 和 redis。redis5.0 提供了原生的消息队列并且具有所有消息队列该有的功能，并且消息是有序的，其轻量的特性在并发量不那么大的时候是一个很好的选择；而选择 kafka 是因为其强大的吞吐量，并且单个 topic 的单个分区也是有序的，可以很好的对应需要同步的数据库与数据库表。 redis redis 的引入其一是为了缓存 MySQL 的 binlog，因为 MySQL 的 binlog 是不断在变化的，当程序崩溃或重启时，需要记录当前的 binlog，然后下次启动时需要从上次的位置继续监听；其二是作为消息队列，相比 kafka 而且因为本身既作为缓存组件也作为消息队列，组件依赖较少。 ...

介绍 mysql2ch 是一个用于同步 MySQL 到 ClickHouse 的工具，支持全量同步与增量同步。 特性 支持全量同步与增量同步。 支持 DDL 与 DML，当前支持 DDL 字段新增与删除与重命名，支持所有的 DML。 支持 redis 和 kafka 作为消息队列。 依赖 kafka，缓冲 MySQL binlog 的消息队列，当使用 kafka 作为消息队列时需要。 redis，缓存 MySQL binlog position 与 file。 安装 pip install mysql2ch 使用 配置文件 [core] # 当前支持kafka和redis作为消息队列 broker_type = kafka mysql_server_id = 1 # redis stream最大长度，多出的消息会按照FIFO删除 queue_max_len = 200000 init_binlog_file = binlog.000024 init_binlog_pos = 252563 # 跳过删除的表，多个以逗号分开 skip_delete_tables = # 跳过更新的表，多个以逗号分开 skip_update_tables = # 跳过的DML，多个以逗号分开 skip_dmls = # 每多少条消息同步一次，生产环境推荐20000 insert_num = 1 # 每多少秒同步一次，生成环境推荐60秒 insert_interval = 1 [sentry] # sentry environment environment = development # sentry dsn dsn = https://xxxxxxxx@sentry.test.com/1 [redis] host = 127.0.0.1 port = 6379 password = db = 0 prefix = mysql2ch # 启用哨兵模式 sentinel = false # 哨兵地址 sentinel_hosts = 127.0.0.1:5000,127.0.0.1:5001,127.0.0.1:5002 sentinel_master = master [mysql] host = 127.0.0.1 port = 3306 user = root password = 123456 # 需要同步的数据库 [mysql.test] # 需要同步的表 tables = test # 指定kafka分区 kafka_partition = 0 [clickhouse] host = 127.0.0.1 port = 9000 user = default password = # need when broker_type=kafka [kafka] # kafka servers,multiple separated with comma servers = 127.0.0.1:9092 topic = mysql2ch 全量同步 你可能需要在开始增量同步之前进行一次全量导入，或者使用--renew重新全量导入，该操作会删除目标表并重新同步。 ...