独立数据库 这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。 优点： 为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求； 如果出现故障，恢复数据比较简单。 缺点： 增大了数据库的安装数量，随之带来维护成本和购置成本的增加。 这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。 共享数据库，隔离数据架构 这是第二种方案，即多个或所有租户共享 Database，但是每个租户一个 Schema。 优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。 缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据； 如果需要跨租户统计数据，存在一定困难。 共享数据库，共享数据架构 这是第三种方案，即租户共享同一个 Database、同一个 Schema，但在表中通过 TenantID 区分租户的数 据。这是共享程度最高、隔离级别最低的模式。 优点： 三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。 缺点： 隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量； 数据备份和恢复最困难，需要逐表逐条备份和还原。 如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
高级亚马逊Web服务用户更喜欢自我管理运行在亚马逊弹性计算云上的数据库，而不是数据库即服务产品，至少现在看是这样的。 上周，AWS超级用户在线活动群组创立会议的演示中，关注超级用户如何在AWS上运行数据库。大多数演讲者表示他们在弹性计算云（EC2）上运行类似Cassandra和MySQL这样的自我管理数据库，而不是使用亚马逊的数据库即服务（DBaaS）平台，比如关系型数据库服务（RDS）以及DynamoDB。 然而，一些IT专家在此次活动中也表示有过DBaaS体验，而且一些仍旧在自我管理和DB
一个租户就是一个客户，例如我们开发的产品是给到某个企业使用，那么该企业就是我们的一个租户。
Greenplum 支持逻辑备份。我们使用Greenplum自带的pg_dump命令实现逻辑备份功能，导出备份文件，再通过 psql 导入到Greenplum中，达到备份的效果。
Mycat中的概念 数据库中间件 前面讲了Mycat是一个开源的分布式数据库系统，但是由于真正的数据库需要存储引擎，而Mycat并没有存储引擎，所以并不是 完全意义的分布式数据库系统。 那么Mycat是什么？Mycat是数据库中间件，就是介于数据库与应用之间，进行数据处理与交互的中间服务。由于前面讲的对数 据进行分片处理之后，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成了整个完整的数据库存储。 如上图所表示，数据被分到多个分片数据库后，应用如果需要读取数据，就要需要处理多个数据源的数据。如果没有数据库中间 件，那么应用将直接面对分片集群，数据源切换、事务处理、数据聚合都需要应用直接处理，原本该是专注于业务的应用，将会 花大量的工作来处理分片后的问题，最重要的是每个应用处理将是完全的重复造轮子。 所以有了数据库中间件，应用只需要集中与业务处理，大量的通用的数据聚合，事务，数据源切换都由中间件来处理，中间件的 性能与处理能力将直接决定应用的读写性能，所以一款好的数据库中间件至关重要。 逻辑库(schema) 逻辑库（schema） 前面一节讲了数据库中间件，通常对实际应用来说，并不需要知道中间件的存在，业务开发人员只需要知道数据库的概念，所以 数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库。 在云计算时代，数据库中间件可以以多租户的形式给一个或多个应用提供服务，每个应用访问的可能是一个独立或者是共享的物 理库，常见的如阿里云数据库服务器RDS。 逻辑表（table） 逻辑表 既然有逻辑库，那么就会有逻辑表，分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表，可以是数据切分后，分 布在一个或多个分片库中，也可以不做数据切分，不分片，只有一个表构成。 分片表 分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的 数据。 例如在mycat配置中的t_node就属于分片表，数据按照规则被分到dn1,dn2两个分片节点(dataNode)上。
前面讲了 Mycat 是一个开源的分布式数据库系统，但是由于真正的数据库需要存储引擎，而 Mycat 并没有存储引擎，所以并不是完全意义的分布式数据库系统。
redo log 和 binlog 是 MySQL 数据库中的两种日志文件，它们都可以用于恢复数据库。但是它们记录的内容、位置、时机、方式和作用都有所不同。
mongodump mongodump是一个MongoDB的备份工具，可以备份整个数据库或者某个集合中的数据，备份出的数据可以用于恢复操作或者数据迁移等。mongodump支持以下参数：
数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作，将因为数据库宕机产生的影响降低到最小。上一篇针对使用xtrabackup工具进行物理备份和数据恢复做了一个详细讲解，本篇主要谈谈如何使用mysql自带的备份工具mysqldump进行逻辑备份和数据恢复。如果还围观看过上一篇文章的可以先行查询上一篇文章关于使用xtrabackup进行数据备份与恢复：Mysql备份与恢复(1)---物理备份。
mongorestore是MongoDB自带的数据恢复工具，用于将mongodump命令备份的数据进行恢复。下面是mongorestore命令的参数说明：
数据库对企业来说最重要的莫过于其中的数据，所以做好数据库的备份是一个不可或缺的工作。数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作，将因为数据库宕机产生的影响降低到最小。所以，本篇文章主要数据库数据备份与恢复进行介绍。由于MyISAM存储引擎中备份数据是将表保存到单独的文件所以比较简单，所以这里我主要针对InnoDB存储引擎介绍备份与恢复机制。
MongoDB的恢复过程与备份过程相反。MongoDB提供了多种方式来恢复备份数据。以下是一些常见的恢复方法：
服务器数据恢复工程师对客户的服务器进行了初步检查，检查结果与客户描述及故障推测一致，服务器数据丢失的原因确实与异常断电有关，由于突然断电导致了启动信息丢失，另外客户服务器上的数据库也受到了破坏。想要恢复数据除了修复linux操作系统外还需要整理数据库碎片，修复数据库。
在 IT 圈内，“删库跑路”已经成为程序员经常提及的一句玩笑话。虽然是玩笑话，但却反映了数据库内数据对企业的重要性。2020年的“微盟事件”就直接让香港主板上市公司微盟集团的市值一天之内蒸发超10亿元，数百万用户受到直接影响。
曾几何时，人们在换手机时如何将数据备份/恢复还是一个令人头疼的问题。iCloud 的出现将 iPhone 的备份管理解决得无比漂亮，而且非常深入人心，现在 iPhone 用户换手机已经是一件没什么压力的事情。
在SQL Server中，通过日志恢复数据库是一个精细的过程，主要用于在数据库出现错误、数据丢失或需要回滚到特定时间点时恢复数据。以下是一般步骤概述：
第一步：备份网站数据 进入后台—站长—数据库—备份，数据备份类型选择“Discuz!和 UCenter数据”，备份成功以后，数据自动保存在data文件夹下。
在 Oracle 12.2 之前，当我们需要恢复数据库到某个时间点的时候，需要确定 SCN，或者日志序列号，或者一个时间点，以便尽可能多的应用归档日志，进而尽可能多的恢复数据。 从12.2开始，RMAN 新增参数： RECOVER DATABASE UNTIL AVALIABLE REDO RMAN 将会根据控制文件信息和归档日志/在线日志/归档日志备份集的物理可用性，将数据库恢复到最后一个可用的归档日志。所以在进行恢复的时候，可以不需要指定 SCN，或者时间,或者日志序列号。需要注意的是，数据文件仍然需要
大家好，又见面了，我是你们的朋友全栈君。 很多站长第一次做网站的时候，无奈选择了速度不是很稳定的空间，慢慢会发现有很多物美价廉速度相当快的空间 这个时候，站长在网站搬家的过程中就会遇到很多困难，今天老袋鼠给大家详细讲解一下discuz 论坛 搬家的详细过程 第一步：备份网站数据 进入后台—站长—数据库—备份，数据备份类型选择“Discuz!和 UCenter数据”，备份成功以后，数据自动保存在data文件夹下。 第二步：网站文件下载 把整个网站文件打包（虚拟主机管理控制面板一般都有整站压缩和解压的功能，在控制面板选择压缩，压缩之后的文件一般在FTP DB文件夹里面，然后把压缩包下载到本地电脑，如果虚拟主机没有在线压缩功能那就直接使用FTP下载文件到本地保存。 第三步：整理下载到本地的网站文件 1.把下载下来的文件里面的下列文件删除，请完全放心删除掉这几个文件，重新装上的时候会自动产生新的文件。 /install/install.lock （有的下载下来之后就没有这个文件，如果没有就不用管） /config/config_global.php /config/config_ucenter.php /uc_server/data/config.inc.php 2.到官方下载一个Discuz! X3.2的安装包，把 upload里的/install/文件夹复制过来覆盖你下载下来的网站文件。 3.把从官方下载下来的Discuz! X3.2安装包里面的 utility/restore.php 文件放到你网站文件的/data/文件夹内，这是用于数据库还原。 第四步：将整理好的网站文件包上传到新主机空间（放网页资料的文件夹下） 建议压缩之后在使用FTP上传，上传完成之后进入虚拟主机控制面板在线解压，这样可以节约很多时间，目前几乎所有的虚拟主机都有在线解压功能，格式一般是rar格式，不过有的部分虚拟主机如linux主机就只支持.zip格式，所以打包前请注意。 第五步：域名解析及空间绑定域名 进入域名控制面板把域名解析到你新的虚拟主机IP上，然后在进入虚拟主机空间绑定域名。 第六步：重新安装discuz http://你的域名/instal/进行安装，填入你新的虚拟主机数据库名和用户名及数据库密码，注意数据库的数据表前缀和以前一样，一般你之前的数据表如果没有改动的话，你重新安装的时候默认的就是和你以前的一样，所以可以不用改。当你安装的时候可能会提示要你删除data/install.lock这个文件才可以继续安装，那么你可以进入FTP删除之后然后返回安装页面刷新一下再继续安装，这就可以安装了。 第七步：还原数据库 安装成功后，用你安装的时候填写的管理员帐号和密码登录，进入后台—站长—数据库—恢复—数据恢复，选中要恢复的数据然后点击右边导入，点击确定即可恢复数据，为了安全起见当成功恢复数据后进入FTP删除/data/restore.php这个文件。 有时候进入之后数据恢复，发现没有可供还原的数据，那么你可以看到下面这一行文字，那你直接点击你的网址在浏览器当中恢复数据即可，为了安全起见当成功恢复数据后进入FTP删除/data/restore.php这个文件。 您可以在本页面数据备份记录处导入备份恢复数据，也可以通过在浏览器中执行 http://www.你的域名.com/data/restore.php 恢复数据 第八步：检查UCenter能否登陆 提示：1、检查UCenter 访问地址设置是否正确（没有更换域名做第六步安装，一般不会出错） 2、创始人密码和admin管理员密码不是同一个，创始人密码是上面第六步重新安装discuz程序时设置的密码。 第九步：检查UCenter应用是否通讯成功 后台——UCenter——应用管理，查看通讯情况，若通讯失败，请检查通信密钥设置是否相同。 后台——站长——UCenter设置，检查UCenter 通信密钥是否和UCenter应用设置相同 第十步：更新缓存 数据还原成功之后，在后台退出帐号，用你原来的后台管理员帐号登陆，进入后台更新缓存，网站搬家成功结束。
如今，许多企业都在谈论他们的公共云采用计划，而这些讨论经常围绕如何避免受到潜在的云服务中断影响。而其原因是确实发生了公共云服务的中断，尽管这些中断现在比以前发生的要少得多，但企业最关心的是如何减少中断
1.mongodump创建高保真的BSON文件，mongorestore可以用其恢复数据库。对于小型数据库的备份和恢复，这两个工具非常简单和高效，但对于大型数据库的备份并不理想。 2.mongodump/mongorestore可以直接对正在运行的mongodb执行操作。 3.默认情况下，mongodump不会捕获本地数据库的内容，而只是捕获其中的document，所以占用空间较小（我试过了，占用空间也不少，原空间占用17G，备份完了37G）。不过，这也导致mongorestore恢复数据时，需要重建索引。 4.mongodump执行过程中会影响mongodb的性能。另外，即使执行结束后的一段时间性能依然会受到影响，因为读取冷数据时，会把热数据从缓存中挤出去了。 5.如果数据大于系统内存，那么查询将会导致内存溢出，从而导致page faults。不过我测试时，待备份数据17G，机器内存8G，并没有出现错误。 6.如果输出文件夹中有文件，mongodump会覆盖。
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.报错的情况
前几天同事不小心误操作，将SQLServer库的一张表的一个状态字段给刷成了一个统一状态，由于是update执行所以原来的相关状态无法确定。发生这种事情的时候我的小伙伴背后 一凉。
亚马逊S3存储服务最近在美国东海岸的可用区域经历了五个小时的中断。而许多消费者和商业应用程序都依赖云存储服务，因此S3存储服务的中断迅速级联，并且Netflix，Slack等组织的服务出现暂时瘫痪。
主要是自己偷懒过程琢磨出来测试的一种方式，迁移成功，所以写下这篇文章稍微记录一下操作步骤。
作为一个面向大规模的分布式存储系统，故障处理是作为一个常态异常处理。Ceph 为了细化和保证故障发生和故障恢复的集群高可用性和一致性，在设计上将故障分为两类:
mongodump 是 MongoDB 官方提供的备份工具，它可以从 MongoDB 数据库读取数据，并生成 BSON 文件，mongodump 适合用于备份和恢复数据量较小的 MongoDB 数据库，不适用于大数据量备份。
sqlite>.output tablexx.sql # 备份数据库，备份的是SQL语句
Flashback恢复数据的原理是通过修改binlog内容，拿回原库进行回放，前提是binlog_format=row和binlog_row_image=FULL。
在前面几篇文章中，我们介绍了 MySQL 的高可用架构。当然，传统的高可用架构是不能预防误删数据的，因为主库的一个 drop table 命令，会通过 binlog 传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。
💝💝💝首先，欢迎各位来到我的博客，很高兴能够在这里和您见面！希望您在这里不仅可以有所收获，同时也能感受到一份轻松欢乐的氛围，祝你生活愉快！
数据库的备份是数据库工作的一个基本项,但实际上能做到毫无挑剔的备份,少之又少, 主要的问题在于备份的频率与性能之间的问题. 这有点类似于 RTO 和 RPO 之间的平衡. 具体怎么设置备份的策略是一个重要的问题.
在 MySQL架构（二）SQL 更新语句是如何执行的？中说到了 redo log 和 binlog 日志文件，在事务执行过程中，会分两个阶段写入这两份日志文件中，这也是为了保证两份日志之间的一致性，即维护 mysql 的数据一致性。
看到标题，有的童鞋心中暗想“数据删除有什么可提的呢？不就是执行个delete语句吗？有什么难的呀？”其实呢数据删除没有你想的这么简单，一般情况下公司会明确的要求数据只能逻辑删除，不能物理删除。那什么优势逻辑删除，什么又是物理删除呢？
数据库恢复的先决条件是,定时备份数据库,缩小binlog恢复范围.首先我们备份测试数据库数据:
每次手动备份太麻烦了，工作上需要，决定使用自动备份，所以写个博客来记录一次，本次备份功能是无密码通过批处理来执行定时备份的，如果是windows server r2服务器的话大家可以搭配任务计划程序来做定时执行，如果是linux内核的系统可以用crontab插件，crontab 插件大家可以自行百度，从而形成定时备份数据。
随着互联网高速发展，数据安全的重要性日趋明显。数据备份是企业应对系统故障的重要手段。数据备份可以提高系统的高可用性和灾难可恢复性，使用备份还原数据是系统崩溃时提供数据恢复最小代价的最优方案。
(1)先登录 mysql -h localhost -u root -p 📷 (2)查看数据库有哪些 show databases; 📷 (3)新建一个空表text create database text ; ####新建数据库text ,等下导表用### 📷 (4)删除数据库chuan drop database chuan; 📷 查看还在不在？不在了 show databases； 📷 退出mysql后再执行以下命令恢复数据库中的表： my
mongodump 是 MongoDB 官方提供的备份工具，它可以从 MongoDB 数据库读取数据，并生成 BSON 文件，mongodump 适合用于备份和恢复数据量较小的 MongoDB 数据库，不适用于大数据量备份。
SQLite 是一个软件库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。SQLite 是在世界上最广泛部署的 SQL 数据库引擎。SQLite 源代码不受版权限制。
近期一篇《就这样把根目录删了！！！》引发了广泛的讨论，《如何防止根目录被删》汇总了7种防删方案。还有同学评论中反馈“不小心把库删了”，如何快速恢复删掉的数据库，是今天要讨论的话题。 【高可用数据库架构
”工欲善其事，必先利其器“。数据备份是DBA的日常工作，也是保证数据安全的重要工作，要尽善尽美的完成这项工作，必须要使用一款高效可靠的备份工具。MySQL在其企业版里提供了一款备份工具——MySQL Enterprise Backup，简称MEB。
问题的起因是，在做repmgr 恢复的时候，经常有同学说恢复的时候， repmgr rejion node 的时候pg_rewind 会报错，与时间线有关。（pg_rewind之前是写过的清参阅之前的文字）
通过 bin 下面的 mysqlbinlog 工具来看法 binlog 文件，可以看到都记录了什么。
在Oracle 11gR2中，引入了SYSASM特权用来执行与ASM相关的特定操作。同样地，在Oracle 12c中引入了3个新的系统用户SYSBACKUP、SYSDG和SYSKM，其中，SYSKM可以执行与透明数据加密密钥（Transparent Data Encryption keystore）相关的操作，SYSDG可以在DGMGRL或命令行接口里执行与DG（Data Guard）相关的操作，而SYSBACKUP特权用来在RMAN或SQL*Plus中执行备份和恢复命令。
前一段时间接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新，对DBA而言，回滚数据着实是一件头疼的事情，凡涉及到恢复线上数据必然对应用带来一定的影响。大多数情况是开发误操作delete数据，update多数行，根据之前的操作经验，本文介绍常用的恢复方法。
我们都知道，Redis 的数据存储在内存中, 一旦服务器宕机，内存中的数据将全部丢失。因此，对 Redis 来说，实现数据的持久化，避免从后端数据库中进行恢复，是至关重要的。本篇我们详细讲解下 Redis 的三种持久化机制，分别是 AOF（Append Only File） 日志和 RDB 快照 以及 混合持久化。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
