多丽丝是什么？近实时分布式OLAP数据库目前有哪些场景？

随着信息技术的快速发展，数据库已成为重要业务数据的存储和管理中心。作为运营商，确保数据库的安全性和可靠性至关重要。然而，手动备份和恢复数据库不仅费时费力，而且容易出现疏忽和错误。

自动数据库备份脚本是一个用于执行自动数据库备份、清理过期备份和恢复数据库的工具。它以脚本代替手动操作，从而提高效率，减少人为错误，保证数据的可靠性和一致性。

应用场景

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。文档 打开Dori官网的第一印象就是对中国用户太友好了。或许因为是中国公司贡献给Apache的项目，所以中文文档写得非常仔细，相比英文版的文档，还看不出阉割的痕迹（对比CK的文档）。而且，不像一些伪中文文档，只有几句无伤大雅的句子被翻译成中文，其余的仍然是英文，就像一个笑话。另外，文档的结构和布局非常好。所有内容可以完整地展示在一页上。如果你想看想找哪一个，直接找到对应的顶级目录即可。然而，CK的情况却并非如此。我在之前的文章中也抱怨过CK。文档的目录结构比较乱。例如，文档的主页不提供对表引擎的输入。如果你想看到它，你必须手动搜索它。 1。当前场景 Doris 是一个近实时的分布式 OLAP 数据库，具有与 CK 类似的功能。从简介和文档整体内容就可以大致看出：至于简介中提到的“海量查询数据亚秒级返回”，显然是一个宣扬牛逼的广告。只要是数据库，就谈不上慢。至于能多快投入生产，就看你写的数据量有多少，以及用户级别是否高。其实和它用了多少“黑科技”没有关系。也就是说，无论多么神奇的黑科技，如果使用不当，都是一样的。它会像蜗牛一样缓慢。官方提供了如下用例图： 它把自己定位在实时数据仓库的位置，说可以支持后续的报表分析、即席查询、联邦搜索、机器学习等。其实任何人都可以明眼人都知道，这个位置并不是 Doris 独有的，很多数据库都支持这些功能以及相同的生态系统。只能说它是众多优秀的近实时OLAP数据库中的另一个选择，但它并不是这种类似场景的唯一选择（当然，Doris肯定希望你这么认为）。 2。技术架构 如果说CK是一个“以表为单位”构建的分布式数据库，那么Doris就是一个典型的传统分布式，主从架构清晰，主从角色清晰。数据库。然而，它看起来并没有那么传统，因为该架构与通常的主/从架构有些不同： Master： 正如您所看到的，它的master可以有多个实例。不同机构的组成和所扮演的角色略有不同。虽然是大师，但与其他大师不同的是，这个大师的子簇数量是可以横向扩展的。对于这个master，Doris给它起了一个特别的名字，叫做Frontend，简称FE。主要负责访问用户请求、调度查询解析、元数据管理、节点管理相关工作，与大多数分布式系统的master相关。尽管如此，他们还是做管理工作。不过这个master的组织结构与其他分布式系统不同的是，其内部的分工和角色与zookeepers特别相似。通过理解官方文档描述，我明白了三者。角色大致总结如下： 从属： 子节点就不多说了。他们一向尽职尽责地做好工作。分工很简单，就是存储数据，然后执行数据的查询和计算需求。只是有一点特别的是，这部分的实现代码语言和大师的Java不同。为了最终的计算效率，它是用C++实现的。同样，多丽丝也给奴隶起了一个新名字，Backend，简称BE。更何况，这种master和slave用不同编程语言实现的技术架构我还是第一次见到。这是一次很棒的经历。 3。安装部署 正如之前CK文章中提到的，对于一个成熟且流行的服务器软件，通常会提供多种发行方案来满足不同人群的需求。从Doris官方文档提供的分发方式来看，相比CK，它更多地支持K8s分发，但缺少yum安装和rpm安装这两个选项。 这里的默认分发其实指的是解压压缩包的方法，这也是我用的最多的方法。那么接下来我们来部署这一套东西。既然是发行版，我们就会面临版本选择的问题。如何选择版本？ 选择版本时的注意事项：前面说过，在选择软件的时候，我总是尽量选择最新版本，但这个选择的前提是，除了最新版本之外，还可以使用人少，相关信息就在网上。除此之外，其他的，比如生态兼容性，都还可以。之前实现CK的时候，在官方文档中找不到兼容组件的说明，但是这次Doris里有说明，比如与其密切相关的计算引擎的Spark版本，以及运行的版本操作系统和 JDK 要求如下： Spark 版本兼容性： 当然还有可能与 Flink 等其他生态组件的兼容性说明他们。这就是您要安装的内容。 Dori 选择的版本提供了另一个重要依据。因为我当前集群中的spark是3.2版本，所以我可以大胆选择Doris 1.0或更高版本。这里我选择了 Doris 1.2.3 版本，不过选择的时候可要擦亮眼睛，一不小心就可能选错： 有趣的是，文档中明确指的是 Doris 1.0 或更高版本。它兼容spark的三个版本：3.2、3.1和2.3，但是当我下载了FE，解压安装的时候，居然发现lib目录下的spark版本都是2.4.6 。 emmm...也就是说，虽然是官方文件，但也不一定100%可靠。你必须亲自验证一切。 Doris的软件架构不仅是主从分离的，而且其部署的软件包也分为FE（主）部分和BE（从）部分。我们知道，对于master来说，Doris允许其部署多台机器的主要原因之一就是为了满足高可用性。如果只是满足集群运行的基本条件，那绝对够了。 主控分发： 将下载的FE压缩包放入目标主机目录下并解压。按照正常操作，打开解压后的FE目录。目录结构如下： bin目录：服务控制目录，目前只有启动和关闭两个； conf目录：核心配置是fe.conf，配置你的Java环境、元数据存储位置、日志位置、IP地址等； lib目录：依赖或者可能需要信任的各种jar包； doris-meta：主节点默认的数据目录，即存储元数据的地方。一般建议改为磁盘目录下的data； log：录音业务默认日志目录，建议切换到统一的日志目录； webroot：提供主节点访问页面所需的相关信息； spark-dpp：这个里面有一个spark相关的jar包。目前还不清楚它的用途。我们稍后再研究；其他目录：目前看来并不重要。验证上面目录的内容，直接在bin目录下运行start_fe.sh脚本。从机分发：同样将BE安装包放入从机目录行并解压。启动服务之前，还看一下软件包的目录结构：

bin：启动和停止服务的脚本目录； conf：配置文件目录，主要关注关键配置be.conf，其中数据存储位置、jdk位置、IP地址、日志位置等需要更改； log ：从机端默认日志目录，建议更改为统一的日志目录； storage：默认存储数据目录，建议更改为统一数据目录； www：应该是从机端提供Web服务的Directory；同样的，很自然的，应该通过运行bin目录下的start-be.sh来启动服务。不过主要有两个坑： 坑一：目前默认的BE安装包有些欠缺。当修改be.conf配置文件，添加一些jdk、MySQL连接器环境等环境时，启动服务时会出现错误。作为大数据开发人员，您应该这样做。敏感的可以发现这个错误：缺少jar包。 这一点其实官网上并没有解释清楚。虽然说要添加UDF依赖，但是并没有说清楚是哪个依赖。 而它提到的依赖在这里： 你需要下载并解压这个压缩包，然后将udf包放入BE主目录下的lib目录中： 重新启动，这个错误就消失了。 坑2：严格来说，这并不是一个坑，因为官网其实预测到了这种可能的错误，即当前服务器默认的打开文件句柄数不够，需要多一些待补充。否则BE服务仍然无法启动。 这个问题不仅仅存在于Doris，很多其他数据库都有这个需求。通常我们会事先更改这个参数。 Master和Slave建立连接： 之前因为Master和Slave是分开启动的，所以彼此还没有关联，也就是还没有人认识，那怎么办呢？通过master的客户端添加一个slave，这样master就可以认识他的弟弟了。这里有趣的一点是，Doris客户端可以复用MySQL客户端，其使用完全符合MySQL的使用习惯。这样就可以大大降低开发者使用Doris的门槛。这是一个非常聪明的方法。具体方法是实现一条操作语句：4。总结一下因为Dori的中文文档支持非常好，而且文档布局也很友好，目录结构清晰，让人感觉很舒服。读起来令人耳目一新，这是一篇很好的评论。其次，Doris的整个部署非常简单。有一些小陷阱，几乎没有大陷阱，所以人们第一次接触它时不会感到沮丧。当然，它也提供了直观的图形界面供人们使用。可以大致了解整个系统，这也是一个优点。 2022-01-01 12:00:00')
if __name__ == '__main__': main()

脚本中数据库的自动备份起着重要作用。简化数据库备份和恢复的操作流程，提高效率和准确性，保证数据安全。无论是公司的数据库管理，还是云服务商的数据库运维，使用此类脚本都可以显着提高运维效率，降低风险，保证业务持续稳定运行。