数据持久化

Docker数据持久化与容器迁移

限于喜欢 提交于 2019-12-29 09:57:24
上节讲到当容器运行期间产生的数据是不会在写镜像里面的,重新用此镜像启动新的容器就会初始化镜像,会加一个全新的读写入层来保存数据。如果想做到数据持久化,Docker提供数据卷(Data volume)或者数据容器卷来解决问题,另外还可以通过commit提交一个新的镜像来保存产生的数据。那么,来一一看下各自的使用方法。 一、数据卷 数据卷特性: 可以绕过UFS文件系统,为一个或多个容器提供访问。 完全独立于容器的生存周期,因此不会在删除容器时删除其挂在的数据卷。 数据卷特点: 数据卷在容器启动初始化时,如果容器使用的镜像在挂载点包含了数据,这些数据会拷贝到新初始化的数据卷中。 数据卷可以在容器直接共享和重用。 可以直接对数据卷里的内容进行修改。 数据卷的变化不会影响镜像的更新。 卷会一直存在,即使挂载数据卷的容器已经删除。 1.数据卷使用 创建并挂载数据卷: $ sudo docker run -itd --name ubuntu_test1 -v /container_data:/data ubuntu 注:container_data为宿主机目录,/data是容器中目录,目录不存在会自动创建 $ sudo docker inspect ubuntu_test1 "Mounts": [ { "Source": "/container_data", "Destination": "

Python基础第十天---对象持久化与字符串处理机制

风流意气都作罢 提交于 2019-12-27 03:32:33
文章目录 一、对象持久化 对象持久化必要性 使用格式化文本文件 1文本文件操作 内置函数eval,它可以将读到的字符串转换为Python的表达式,此时可以将他当作Python语句来运行了。 2使用常见的pickle进行对象持久化 序列化到字符串中,再反序列化为原来类型 序列化到二进制文件中,再反序列化为原来类型 3使用常见的shelve进行对象持久化 二、字符串的本质 字符串类型分类 三种类型的转换 bytes字节类型 bytearray字节数组类型,支持原位改变,类似列表类型 概述 三 、UTF-8、ASCII常用字符串编码 ASCII 0-127代码点之间 latin-1为拉丁1字符码 UTF-16 UTF-32 通用可变字长UTF-8,通用性好。 四、字符的编码与解码 编码 解码 字符串默认编码解码 文件读取的编码与解码 字符串BOM处理(字节顺序标记) 一、对象持久化 对象持久化必要性 概论:所有程序运行过程,就是使用我们编写的指令,来调度运算我们特定的数据或数据结构,但这个运算过程在内存里边;我们知道内存不是永久性存储,当我们断电,内存中的状态或数据就会丢失,当然在实际计算可能需要将当前需要计算的某个数据结果永久存储起来,就要用到对象的持久化。如:玩游戏过关时,这个状态是在内存中表现的,若想明天接着玩,我们可以把当前进度保存一下

redis的 rdb 和 aof 持久化的区别

最后都变了- 提交于 2019-12-26 16:57:12
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> aof,rdb是两种 redis持久化的机制。用于crash后,redis的恢复。 rdb的特性如下: fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来。 save, shutdown, slave 命令会触发这个操作。 粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复 aof有如下特性: 把写操作指令,持续的写到一个类似日志文件里。(类似于从postgresql等数据库导出sql一样,只记录写操作) 粒度较小,crash之后,只有crash之前没有来得及做日志的操作没办法恢复 两种区别就是, 一个是持续的用日志记录写操作,crash后利用日志恢复 ; 一个是平时写操作的时候不触发写,只有手动提交save命令,或者是关闭命令时,才触发备份操作 。 选择的标准,就是看系统是愿意 牺牲一些性能,换取更高的缓存一致性(aof) , 还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save的时候,再做备份(rdb)。rdb这个就更有些 eventually consistent的意思了 redis的rdb和aof模式性能对比 由于是同一台机器,进行相对对比,我就不列配置了。系统是debian

Redis持久化和数据恢复的坑

房东的猫 提交于 2019-12-26 00:42:09
redis提供了rdb和aof两种持久化机制,rdb默认开启,aof默认关闭。 当两种持久化机制都开启时,redis重启恢复数据时加载aof持久化的appendonly.aof文件,而rdb持久化的dump.rdb文件不会被加载到内存中。 情景:开启rdb,关闭aof 通过redis-cli SHUTDOWN这种方式停掉redis,这是一种安全的退出方式,redis会在退出的时候将内存中的数据立即生成一份完整的rdb快照。 通过kill -9杀死redis进程,这种方式会导致redis异常退出,从而导致内存中的数据没有到达save指定的检查点,进而丢失内存中的数据。 情景:开启rdb,关闭aof,待dump.rdb有数据后,再开启aof redis持久化dump.rdb后,启用aof持久化,再重启redis,redis只会加载aof持久化的appendonly.aof文件,如果它不存在,那会创建一个新的空的文件,从而导致内存中丢失dump.rdb的数据。 解决方式:停止redis,关闭aof,重启redis,确保dump.rdb数据恢复在内存中,使用命令行热修改redis配置的方式打开aof,此时redis就会以aof持久化的形式将内存中的数据写入appendonly.aof文件,然后停止redis,修改配置文件将aof手动打开。 情景

redis持久化机制

陌路散爱 提交于 2019-12-25 17:06:30
redis中持久化机制有两种方法,分别是AOF(Append Only File)与RDB. 一、RDB 将内存中的快照保存到文件。 1. RDB触发条件分为自动触发与手动触发。 自动触发:触发条件可以通过redis.conf 配置文件中的 SNAPSHOTTING 下配置: 默认配置如下: save 900 1:表示900 秒内如果至少有 1 个 key 的值变化,则保存 save 300 10:表示300 秒内如果至少有 10 个 key 的值变化,则保存 save 60 10000:表示60 秒内如果至少有 10000 个 key 的值变化,则保存 手动触发:save:阻塞命令,客户端无法进行命令操作 。bgsave:(非阻塞,子进程执行保存操作) 2. 恢复数据: 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可,redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间,会一直处于阻塞状态,直到载入工作完成为止。 3. RDB优势与劣势 优势:  RDB是一个非常紧凑(compact)的文件,它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。  生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作。  RDB

Redis的持久化详解

不想你离开。 提交于 2019-12-25 15:49:57
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Redis持久化 Java大猿帅成长手册, GitHub JavaEgg ,N线互联网开发必备技能兵器谱 Redis 的数据全部在内存里,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失,这种机制就是 Redis 的持久化机制。 Redis有两种持久化的方式:快照( RDB 文件)和追加式文件( AOF 文件) RDB(Redis DataBase) 是什么 在指定的时间间隔内将内存中的数据集快照写入磁盘 ,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。 Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB 方式要比 AOF 方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 ? What ? Redis 不是单进程的吗? Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化, fork是类Unix操作系统上 创建进程 的主要方法。COW(Copy On

Redis配置与优化

这一生的挚爱 提交于 2019-12-24 20:49:18
Redis配置与优化 Redis概述 Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部分场合可以对关系数据库起到很好的补充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。 Redis优点 具有极高的数据读写速 支持丰富的数据类型 支持数据的持久化 原子性 支持数据备份 Redis配置文件(/etc/redis/6379.conf)bind: 监听的主机地址 port: 端口 daemonize yes: 启用守护进程 pidfile: 指定PID文件 loglevel notice: 日志级别 logfile: 指定日志文件 Redis安装部署 #安装编译环境 [ root@localhost ~ ] # yum install gcc gcc-c++ make -y #远程挂载源码包 [ root@localhost ~ ] # mount.cifs //192.168.142.1/redis /mnt Password for root@//192.168.142.1/redis: #解压源码包 [ root@localhost ~ ] # cd /mnt [ root

redis持久化

一个人想着一个人 提交于 2019-12-24 01:23:06
持久化的定义 redis将所有数据保持在内存中,对数据的更新将异步地保存在磁盘中 持久化的方式 快照 MySQL Dump Redis RDB ###写日志 MySQL Binlog Hbase HLog Redis AOF RDB 一、什么是RDB 经过RDB之后,redis会将内存中的数据创建一份快照到硬盘中,称为RDB文件(二进制) 当redis重新启动时,会加载硬盘中的RDB文件,加载到内存中完成数据恢复 二、RDB的触发方式 1.save(同步) 在save的同时,其他命令会阻塞等待 如果存在老的RDB文件,会先创建一个临时文件,然后对老文件进行替换 时间复杂度,O(n) 2.bgsave(异步) 调用bgsave后,会调用linux的fork()函数,创建一个子进程 如果存在老的RDB文件,会先创建一个临时文件,然后对老文件进行替换 时间复杂度,O(n) 子进程名称:redis-rdb-bgsave 3.save VS bgsave save bgsave IO类型 同步 异步 阻塞 是 是(阻塞发生在fork) 复杂度 O(n) O(n) 优点 不会消耗额外内存 不阻塞客户端命令 缺点 阻塞客户端命令 需要fork,消耗内存 三、通过配置自动进行RDB操作 内部相当于bgsave Redis默认的save配置 配置 second changes save 900 1

Redis配置与优化

只谈情不闲聊 提交于 2019-12-23 18:16:18
Redis配置与优化 Redis简介 Redis基于内存运行并支持持久化 采用key-value(键值对)的存储形式 优点: 具有极高的数据读写速度 支持丰富的数据类型 支持数据的持久化 原子性 支持数据备份 Redis和mem的差别 redis:支持持久化,不支持结构化 mem : 支持结构化,不支持持久化 Redis的安装部署 #安装必要安装包 yum install gcc gcc-c++ -y #挂载必要软件包 mount.cifs //192.168.100.3/mem /mnt #解压安装包 cd /mnt tar zxvf redis-5.0.7.tar.gz -C /opt #编译安装 cd /opt/redis-5.0.7/ make make PREFIX=/usr/local/redis/ install #进入util目录,执行脚本 cd utils/ ./install_server.sh #执行后一路回车在这里添加/usr/local/redis/bin/redis-server一句 Please select the redis executable path [ ] /usr/local/redis/bin/redis-server #创建命令连接 ln -s /usr/local/redis/bin/* /usr/local/bin netstat

redis架构详解

柔情痞子 提交于 2019-12-23 09:18:13
一、redis特性 1.redis 是什么? redis是基于内存的可持久化的key-value数据库 2.redis数据结构类型? value支持五种数据类型,字符串、字符串列表、字符串集合、有序集合、hashs 3.redis持久存储方式 redis两种持久化方式,RDB,和AOF RDB: 将某一时刻的数据持久化到磁盘上,是一种快照式的持久方式, redis在进行持久化的过程中,会先将数据写入临时文件中,待持久化过程结束,会用这个临时文件,替换上次持久化的文件,正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的。 原理:rdb方式持久化时,redis会fork出一个子进程进行持久化,主进程不会进行任何io操作,确保redis性能不会因持久化而降低,如果对数据不敏感且需要大规模恢复数据,可以使用这种方式 AOF: 将执行过的写指令记录下来,在数据恢复时,将指令按照顺序在执行一边. 我们通过配置redis.conf中的appendonly yes就可以打开AOF功能.如果有写操作,就会追加到aof文件末尾,默认aof持久化策略是每秒钟fsync一次将数据从缓存区域刷到磁盘上,因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据. 问题1: aof文件坏了怎么办? 备份被写坏的AOF文件 运行redis-check