信息技术的快速发展，数据库成为了企业重要数据的存储和管理中心。作为运维工程师，确保数据库的安全性和可靠性是至关重要的任务之一。然而，手动进行数据库备份和恢复操作不仅费时费力，还容易出现疏忽和错误。
自动化数据库备份脚本是一种用于自动执行数据库备份、清理过期备份和恢复数据库的工具。它通过编写脚本来代替手动操作，从而提高效率、减少人为错误，并确保数据的可靠性和一致性。
应用场景
1、简化运维工作：
脚本自动执行数据库备份和恢复操作，省去了手动操作的繁琐和复杂性。运维工程师只需编写脚本并进行配置，脚本将自动完成数据库备份和恢复任务，大大减少了运维工作的工作量和时间成本。
2、提高效率和准确性：
自动化脚本执行备份和恢复任务的速度远快于人工操作，大大提高了运维工作的效率。此外，脚本的执行准确无误，避免了人为因素导致的错误，确保了备份和恢复的可靠性。
3、保障数据安全：
通过定期备份和清理过期备份，脚本确保了数据库数据的安全性。即使在数据库发生故障或数据丢失的情况下，运维工程师可以通过脚本执行恢复操作，将数据库恢复到最近的可用备份点，最大程度地减少数据丢失和业务中断的风险。
4、灵活配置和扩展性：
脚本具有灵活的配置选项，可以根据具体需求进行调整。例如，可以设置备份周期、保留备份的时间范围、备份存储位置等。脚本还可以与其他自动化工具或任务调度系统集成，实现更复杂的自动化运维流程。
脚本示例
import datetimeimport osimport subprocess# 数据库备份目录BACKUP_DIR = '/path/to/backup'# 备份文件保留周期（天）RETENTION_PERIOD = 7# 备份数据库def backup_database():current_time = datetime.datetime.now()backup_file = f"backup_{current_time.strftime('%Y%m%d%H%M%S')}.sql"backup_path = os.path.join(BACKUP_DIR, backup_file)# 使用 subprocess 模块执行数据库备份命令backup_command = ['mysqldump','-u','username','-p','password','--all-databases']with open(backup_path, 'w') as backup_file:subprocess.run(backup_command, stdout=backup_file)print(f"数据库备份已完成，备份文件保存为: {backup_path}")# 清理过期备份文件def cleanup_backup():current_time = datetime.datetime.now()cutoff_time = current_time - datetime.timedelta(days=RETENTION_PERIOD)for file in os.listdir(BACKUP_DIR):file_path = os.path.join(BACKUP_DIR, file)if os.path.isfile(file_path):file_time = datetime.datetime.fromtimestamp(os.path.getmtime(file_path))if file_time < cutoff_time:os.remove(file_path)print(f"过期备份文件已删除: {file_path}")# 恢复数据库def restore_database(backup_file, restore_time):backup_path = os.path.join(BACKUP_DIR, backup_file)# 使用 subprocess 模块执行数据库恢复命令restore_command = ['mysql','-u','username','-p','password']with open(backup_path, 'r') as backup_file:subprocess.run(restore_command, stdin=backup_file)print(f"数据库已成功恢复到时间点: {restore_time}")# 主函数def main():# 执行数据库备份backup_database()# 清理过期备份文件cleanup_backup()# 恢复数据库到指定时间点restore_database('backup_20220101120000.sql', '
马不停蹄的试用Doris，你不能说我喜新厌旧，主要是应球友们的邀约，盛情难却，想对它跟CK来一番对比，看看它在各个方面的表现，孰优孰劣。0. 文档 打开Doris官网的第一感觉就是，对中文用户实在是太友好了，可能由于是中国公司贡献到Apache的项目，因此它的中文文档写的非常用心，相对于英文版的文档，暂时没有看出有阉割的痕迹(对比CK的文档)。 而且，也不像一些伪中文文档那样，只有少数几个不痛不痒的句子被翻译成了汉语，其他还是英文，跟闹着玩似的。 另外，还有一个就是文档的结构布局非常好，所有的内容都在一个页面能全部显示完全，想看哪个直接找到对应的顶级目录就可以找到，但是CK则不是，之前文章也吐槽过CK的文档目录结构，乱七八糟，比如文档首页是没有提供表引擎这个入口的，想要查看，必须要手动搜索。 1. 适用场景 Doris是一款其实跟CK功能差不多的，近实时分布式OLAP数据库，这个从它的介绍，以及文档中的总体内容就可以大概看出来：
至于介绍中说的“亚秒级返回海量查询数据”，很明显是催牛逼的广告，现在只要是个数据库，就没有说自己慢的，至于在生产中能有多快，那就要看你写入了多少数据量，以及使用者水平高不高了，跟它用了多少“黑科技”关系其实并不是特别大，或者说，再牛逼的黑科技，如果使用的不当，一样会慢的像蜗牛。 官方给了如下这个使用场景说明图：
它把自己放到一个实时数据仓库的地位，说可以支持后面的报表分析、即席查询、联邦查询、机器学习等，其实明眼人都知道，这个位置并不是Doris的专属，很多数据库都支持这些功能，以及相同的生态。 只能说它是当下众多优秀的，近实时OLAP数据库的又一个新选择，而并不是这类似场景中，非它莫属(当然，Doris肯定希望你这么认为)。 2. 技术架构 如果说CK是一款“以表为单位”构建起来的分布式数据库，那么Doris就是一款主从架构分明，master/slaver角色明确的，典型的传统分布式数据库。 只不过，它好像也没有那么传统，因为它的架构跟普通的master/slaver架构又有些不一样：
Master： 可以看到，它的master可以有由多个实例组成，而且不同的实例扮演的角色又有细微的区别，虽然是master，跟一般其他的master不一样的是，这个master的子集群数量是可以横向扩展的。 而这个master，Doris给它起了个专门的名字，叫Frontend，简称FE，主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作，跟大部分分布式系统的master一样，干的都是管理类的活。 只不过，这个master的组织架构跟其他分布式系统不太一样的地方在于，它内部的分工和角色特别像zookeeper，通过对官方文档描述的理解，我对他们3个的角色大致总结如下：
Slaver： 子节点就没什么好说的了，历来就是专门干活的，分工特简单，就是存储数据，然后执行数据的查询计算要求，只不过有点特殊的是，该部分的实现代码语言跟master的Java不一样，为了极致的数据处理效率，它是用C++实现的。 同样，Doris也给它的slaver起了个新名字，叫Backend，简称BE。 别说，这种master跟slaver用不同的编程语言实现的技术架构，我还是头一次见，算是长见识了。 3. 安装部署 之前在聊CK的文章里说到，对于一个成熟的，且流行度高的服务器软件来说，一般都会提供多种部署方案，以满足不同的人群需求。 从Doris官方文档提供的部署方式来看，相比于CK，它多了个K8s部署的支持，但是却少了yum安装，和rpm安装这两个选择。
它这里的标准部署，其实指的是压缩包解压的方式，也是我最常用的一种方式。 那么接下来，就把这套玩意给部署起来，既然是部署，那就会面临版本选择的问题，那选个版本呢？ 版本选择的考量： 之前说过，对于软件的选择我都是尽量选择次新版本，但是这个选择的前提是，除了最新版本可能因为用的人少，网络上的相关资料会比较少外，其他一切，比如生态的兼容性都是OK的。 之前在部署CK的时候，在官方文档里因为没有找到对应兼容组件的说明，但是这次在Doris里却有，比如跟他紧密相连的计算引擎Spark版本，还有操作系统的版本，以及对应的JDK版本等。 对操作系统，以及JDK的要求如下：
spark版本的兼容情况：
当然，此外还有Flink等其他可能与之直接关联的生态组件的兼容性说明，这个就为你要安装的Doris版本选择提供了另一个重要依据。 因为我当前集群的spark是3.2的版本，因此就可以大胆选择Doris1.0以上的版本了。 这里我选择了Doris的1.2.3版本，不过在选择时，你可要擦亮眼睛看清楚，一不下心可能会选错：
有意思的是，文档明明说的是1.0以上版本的Doris兼容的是spark的3.2、3.1和2.3这3个版本，但是当我下载完它的FE，在解压安装时居然发现它的lib目录中spark的版本都是2.4.6的。
emmm... 说明就算是官方文档，也不一定就100%靠谱，凡事还得自己亲自动手实践验证。 不仅Doris的软件架构是master/slaver分离的，其部署的软件包也是一样，分为FE(master)部分和BE(slaver)部分。 我们知道，对于master来说，Doris之所以让它能部署多台，核心原因之一在于满足高可用，如果只是满足集群运行的基本条件，肯定一个也就够了。 master部署： 将下载的FE压缩包放到目标master机器的目录下并解压，根据常规操作，打开解压后的FE目录，目录结构如下：
bin目录：服务控制目录，目前就启动和关闭两个； conf目录：核心配置就是fe.conf，配置你的Java环境，元数据存储位置，日志位置，ip地址等； lib目录：依赖的，或者可能需要依赖的各种jar包； doris-meta：默认主节点的数据目录，也就是保存元数据的，一般建议修改到数据盘目录下； log：默认记录服务的日志目录，也是建议改为统一的日志目录下； webroot：提供主节点的访问页面需要的相关信息； spark-dpp：这个里面有个跟spark相关的jar包，目前不清楚干啥的，后续再研究； 其他的目录：目前看来并不重要。 确认好以上目录的内容，直接启动bin目录下的start_fe.sh脚本就可以了。 slaver部署： 同样，将BE的安装包放到slaver机器的目录行并解压，在启动服务前，也是来看一下软件包的目录结构：
bin：启动和停止服务的脚本目录； conf：配置文件目录，主要关注关键配置be.conf，要修改其中数据的存储位置，jdk位置，IP地址，日志位置等等; log：slaver端的默认日志目录，建议更改为统一的日志目录； storage：默认的存储数据目录，建议更改为统一的数据目录； www：应该是提供slaver端web服务的目录； 同样，按理说应该通过执行bin目录下的start-be.sh就能服务启动起来了，但是，这里面主要有有2个坑： 坑1： 当前默认的BE安装包是缺少东西的，当你修改be.conf配置文件，添加一些诸如jdk的环境，以及MySQL connector环境后，启动该服务会有个报错，作为一个大数据开发人员，应该可以从这个报错中敏感的发现：它缺jar包。 而这一点，在官网中其实是没有交代清楚的，虽然它有说要添加UDF依赖，但是没有说清楚是哪个依赖啊。
而它说的这个依赖，在这里：
要把这个压缩包下载下来解压，然后把里面的udf包放到BE家目录下的lib目录中：
再启动，这个错误才消失。 坑2： 严格来说，这个谈不上是坑，因为官网其实已经预知了这个可能的错误，那就是当前服务器的默认打开的文件句柄数是不够的，需要增加一些，否则BE服务还是启动不起来。
这个问题不仅针对Doris，其他很多数据库都有这个要求，一般我们都会提前修改这个参数。 master和slaver建立连接： 之前因为master和slaver都是各自启动的，彼此之间暂时还没有进行关联，也就是谁都还不认识谁，那怎么办呢？ 通过master的客户端添加slaver，从而让master认识自己的小弟。 这里有个有意思的点就是，Doris的客户端可以复用MySQL的客户端，它的使用方式也完全遵从MySQL的使用习惯，这样一来，就能大大降低开发者对Doris的使用门槛，是一种非常聪明的做法。 具体做法，则是通过执行一条操作语句来实现：
4. 总结一下 因为Doris的中文文档支持的非常好，且文档编排方式也非常友好，目录结构清晰，让人读起来比较清爽，好评。 其次，整个Doris的部署还是挺简单的，小坑有一点，大坑几乎没有，不至于让人在刚开始接触它时就会受挫，而且还天然提供了一个直观的图形界面，让人通过它大致可以窥探系统的全貌，这个也是优点。2022-01-01 12:00:00') if __name__ == '__main__': main()
自动化数据库备份脚本在运维工程师的工作中发挥着重要作用。它简化了数据库备份和恢复的操作流程，提高了效率和准确性，保障了数据的安全性。无论是在企业内部的数据库管理还是云服务提供商的数据库运维，使用这样的脚本都能极大地提升运维效率，降低风险，确保业务的持续稳定运行。
