mysql数据持久化方式_数据持久化

发布时间：2022-11-18 13:23:07 所属栏目：MySql教程来源：

导读：　　概述

　　存储管理与计算管理是两个不同的问题。Persistent Volume 子系统，对存储的供应和使用做了抽象，以 API 形式提供给管理员和用户使用。要完成这一任务，我们引入了两个新的 API 资源：Persistent Vo

　　概述

　　存储管理与计算管理是两个不同的问题。Persistent Volume 子系统，对存储的供应和使用做了抽象，以 API 形式提供给管理员和用户使用。要完成这一任务，我们引入了两个新的 API 资源：Persistent Volume(持久卷) 和 Persistent Volume Claim(持久卷消费者)。

　　Persistent Volume(PV)是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。PV 跟 Volume (卷) 类似，不过会有独立于 Pod 的生命周期。这一 API 对象包含了存储的实现细节，例如 NFS、iSCSI 或者其他的云提供商的存储系统。Persistent Volume Claim (PVC) 是用户的一个请求。跟 Pod 类似，Pod 消费 Node 的资源，PVC 消费 PV 的资源。Pod 能够申请特定的资源(CPU 和内存)；Claim 能够请求特定的尺寸和访问模式(例如可以加载一个读写，以及多个只读实例)

　　PV 与 PVC

　　PV 是集群的资源。PVC 是对这一资源的请求，也是对资源的所有权的检验。PV 和 PVC 之间的互动遵循如下的生命周期。

　　供应：集群管理员会创建一系列的 PV。这些 PV 包含了为集群用户提供的真实存储资源mysql持久化，它们可利用 Kubernetes API 来消费。

　　绑定：用户创建一个包含了容量和访问模式的持久卷申请。Master 会监听 PVC 的产生，并尝试根据请求内容查找匹配的 PV，并把 PV 和 PVC 进行绑定。用户能够获取满足需要的资源，并且在使用过程中可能超出请求数量。如果找不到合适的卷，这一申请就会持续处于非绑定状态，一直到出现合适的 PV。例如一个集群准备了很多的 50G 大小的持久卷，(虽然总量足够)也是无法响应 100G 的申请的，除非把 100G 的 PV 加入集群。

　　使用： Pod 把申请作为卷来使用。集群会通过 PVC 查找绑定的 PV，并 Mount 给 Pod。对于支持多种访问方式的卷，用户在使用 PVC 作为卷的时候，可以指定需要的访问方式。一旦用户拥有了一个已经绑定的 PVC，被绑定的 PV 就归该用户所有了。用户的 Pods 能够通过在 Pod 的卷中包含的 PVC 来访问他们占有的 PV。

　　释放：当用户完成对卷的使用时，就可以利用 API 删除 PVC 对象了，而且他还可以重新申请。删除 PVC 后，对应的卷被视为 “被释放”，但是这时还不能给其他的 PVC 使用。之前的 PVC 数据还保存在卷中，要根据策略来进行后续处理。

　　回收： PV 的回收策略向集群阐述了在 PVC 释放卷的时候，应如何进行后续工作。目前可以采用三种策略：保留，回收或者删除。保留策略允许重新申请这一资源。在持久卷能够支持的情况下，删除策略会同时删除持久卷以及 AWS EBS/GCE PD 或者 Cinder 卷中的存储内容。如果插件能够支持，回收策略会执行基础的擦除操作(rm -rf /thevolume/*)，这一卷就能被重新申请了。

　　定义 PV

　　持久卷插

　　持久卷是以插件方式实现的，目前支持的插件如下：

　　GCEPersistentDisk

　　AWSElasticBlockStore

　　NFS(我们采用的是该方案)

　　iSCSI

　　RBD (Ceph Block Device)

　　Glusterfs

　　HostPath (单节点测试使用)

　　本地持久卷

　　YAML 配置

　　创建一个名为 nfs-pv-mysql.yml 的配置文件

　　apiVersion: v1

　　kind: PersistentVolume

　　metadata:

　　name: nfs-pv-mysql

　　spec:

　　# 设置容量

　　capacity:

　　storage: 5Gi

　　# 访问模式

　　accessModes:

　　# 该卷能够以读写模式被多个节点同时加载

　　- ReadWriteMany

　　# 回收策略，这里是基础擦除 `rm-rf/thevolume/*`

　　persistentVolumeReclaimPolicy: Recycle

　　nfs:

　　# NFS 服务端配置的路径

　　path: "/usr/local/kubernetes/volumes"

　　# NFS 服务端地址

　　server: 192.168.141.140

　　readOnly: false

　　# 部署

　　kubectl create -f nfs-pv-mysql.yml

　　# 删除

　　kubectl delete -f nfs-pv-mysql.yml

　　# 查看

　　kubectl get pv

　　NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

　　nfs-pv-mysql 5Gi RWX Recycle Available 29m

　　配置说明

　　Capacity(容量)

　　一般来说，PV 会指定存储容量。这里需要使用 PV 的 capcity 属性。目前存储大小是唯一一个能够被申请的指标，今后会加入更多属性，例如 IOPS，吞吐能力等。

　　AccessModes(访问模式)

　　只要资源提供者支持，持久卷能够被用任何方式加载到主机上。每种存储都会有不同的能力，每个 PV 的访问模式也会被设置成为该卷所支持的特定模式。例如 NFS 能够支持多个读写客户端，但是某个 NFS PV 可能会在服务器上以只读方式使用。每个 PV 都有自己的一系列的访问模式，这些访问模式取决于 PV 的能力。访问模式的可选范围如下：

　　ReadWriteOnce：该卷能够以读写模式被加载到一个节点上

　　ReadOnlyMany：该卷能够以只读模式加载到多个节点上

　　ReadWriteMany：该卷能够以读写模式被多个节点同时加载

　　在 CLI 下，访问模式缩写为：

　　RWO：ReadWriteOnce

　　ROX：ReadOnlyMany

（编辑：开发网_运城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

MySQL8.0新特征支持原	zabbix 一次悲惨的分区
MySQL基本查询例子2	MySQL之日志管制