怨行客

好问题！你想要，这是一个非常典型的，建议使用的方式实现，稳定高效。我来手把手教你配置，一次性搞定。

你这个思路是完全可行的！我们可以通过以下几个步骤在 Rocky Linux 9.5 上部署一个，并把镜像存储定向到本地的目录，实现便携式迁移。

特性软 RAID硬 RAID成本低（无需专用硬件）高（需要 RAID 控制器）性能依赖 CPU，适合轻到中负载硬件加速，适合高负载灵活性高，支持多种配置和操作系统较低，受控制器限制可靠性无专用缓存，断电风险较高有 BBU，数据保护更好管理需手动配置，依赖命令行工具提供专用工具，管理更简单迁移性硬件无关，易迁移厂商锁定，迁移复杂故障点无控制器故障风险控制器可能成为单点故障适用场景小型服务器、个人工作站、低预算环境企业级服务器、高性能/可靠性需求环境。

支持PB 级别的存储大小，可以被数千个客户端连接，相媲美ceph，除了对象存储没有。

打开之前下载的rook-ceph文件夹（前提是你的文件夹名字已经标注了版本）在 deploy/examples/cluster.yaml里有。

1、mon负责认证，mon一定要三个，要不一个坏了以后还咋认证。2、认证完才能对ceph增删改查。

应用案例：一个图片分享应用，用户可以上传、下载大量的图片文件，SeaweedFS 可以提供快速的图片存储和检索服务，并且能够轻松地扩展以应对不断增长的存储需求。

volume create: myvolume: failed: 目录 is already part of a volume。请注意，在执行这些命令之前，请确保您不再需要 GlusterFS 服务及其相关数据，因为这些操作将不可逆地删除这些文件和目录。2、gluster volume create myvolume replica 3 ip:目录 ip2:目录 ip3:目录。1、系统要相同，因为我用了centos7.9和rocky linux8，就不行。解决方法：删除目录，重新创建。

一致性哈希（Consistent Hashing）是一种用于解决分布式系统中数据分片和负载均衡问题的算法。在传统的哈希算法中，当节点数量发生变化时，需要重新分配大部分数据，这会导致系统出现大量的数据迁移。而一致性哈希算法通过引入虚拟节点的概念，减少了节点增减时数据迁移的开销。举个例子来说明一致性哈希的作用：假设有一个缓存集群，其中有多个节点，每个节点负责一部分数据。传统的哈希算法将数据根据键值进行哈希运算，然后将数据映射到不同的节点上。

Redis的数据过期策略包括两种机制：被动删除和主动删除。这种组合策略有助于保持Redis内存的使用效率，避免大量过期键占用内存，但同时也不会因为删除操作而造成服务器性能的显著下降。另外，当内存不足时，Redis还可以配置使用volatile-*或allkeys-*等淘汰策略来删除键，以释放内存，这些策略和键过期是分开的，但在管理内存方面发挥着互补作用。

渐进式rehash是Redis用来优化字典扩容或缩容过程中的性能的一种技术。在Redis中，字典是通过哈希表实现的，它是键值对的集合。随着键值对数量的增减，哈希表可能需要扩大或缩小来保持其性能。在不使用渐进式rehash的情况下，重新调整哈希表的大小会一次性重新计算所有键的哈希值，并将它们移动到新的哈希表中，这个过程可能会很慢，并且在这期间，数据库不能响应其他任何命令，这在处理大量数据时尤其成问题。为了解决这个问题，Redis使用了渐进式rehash。

主从复制（Master-Slave Replication）是一种在数据库中实现数据备份和高可用性的技术。它通过在主服务器（Master）和从服务器（Slave）之间建立数据同步关系，将主服务器上的数据实时复制到从服务器上，从而实现数据备份和高可用性。假设有一个主服务器（Master）和一个从服务器（Slave）。在主服务器上创建一个数据库，并在其中创建一些表和数据。在从服务器上也创建相同的数据库和表结构。在主服务器上配置二进制日志，并开启二进制日志记录功能。

数据库的事务是一个作为单个工作单位执行的一系列操作，这些操作要么完全地执行，要么完全不执行。

使用自增主键时，InnoDB表可以有效地避免页面分裂，因为新记录总是添加到索引的末尾。这就是为什么在InnoDB中推荐使用自增主键，特别是在插入密集型的应用程序中。在这样的情况下，InnoDB能够利用顺序I/O，而非随机I/O，后者通常更慢，因为它涉及更多的寻道时间（磁盘头移动到磁盘上的正确位置）。4 事务1、什么是数据库的事务？2、什么是事务的四大特性（ACID）？4、事务的并发问题？5、什么是脏读、幻读和不可重复度？6、事务的隔离级别有哪些？7、ACID 特性是如何实现的？

数据库设计的"三大范式"是指三个基本的规则，用来指导数据库表结构的设计，以减少数据的冗余和改善数据的逻辑结构。遵循这些范式可以帮助设计出既节省空间又能提高效率的数据库。在数据库设计中，“范式”（Normalization）和"反范式"（Denormalization）是两种不同的设计哲学，各有其适用场景和优缺点。范式化倾向于系统的逻辑完整性和减少冗余，而反范式化倾向于查询性能和简化查询设计。在实际应用中，数据库设计往往需要在范式化与反范式化之间权衡，取决于业务需求、查询频率、数据更新的复杂性等因素。

Ceph是一个开源的分布式存储系统，具有以下优势和特点：可扩展性：Ceph可以轻松地扩展到大规模的存储集群，支持数百或数千个节点，并能够处理PB级别的数据。弹性和高可用性：Ceph采用了复制和纠删码等机制来保证数据的弹性和高可用性。它在集群中自动复制数据副本，并且能够容忍多个故障或节点失效。统一的存储系统：Ceph提供了统一的接口和命名空间，使用户可以以各种方式访问数据，包括对象存储、文件系统和块设备。这简化了应用程序与存储交互的复杂性。自我管理：Ceph具有自动管理和自恢复的功能。

这通常在你的 Kubernetes 集群的 Git 仓库中。你也可以在 Rook 的官方仓库中找到示例文件：https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/ceph/operator.yaml。你也可以在 Rook 的官方仓库中找到示例文件：https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/ceph/cluster.yaml。

对象存储-- 不会反复修改的数据 http API Web应用/移动应用。块存储-- 高频访问的数据，极致的 IOPS 数据库。文件存储-- 频繁修改写入的数据，共享数据 大数据分析。

集群启动后，operator回一次启动一个mon，如果三个mon不能全启动，就不会向下进行。

StorageClass可以接各种provisioner, ceph或者云存储，nfs都可以pv静态是指管理员提前创建好pv动态是指用sc

storageclass是最省心的，上面三种删除了容器存储还在下图是管理员定义pv，用户不知道这些细节 PersistentVolumepv会跟后端的存储rbd对接用户通过PVC调用PV ,根据10G容量去pv里找相匹配的自动关联上图就叫 pvc-demo管理员定义好下面用户pvc是向storgeclass 申请多少容量,就会调用storgeclass的驱动创造pv出来，这个pv和后端存储对接这样我们就可以在容器中调用这个pvc动态创建就是在statefulset里面直接模板的形