Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Python后端技术栈(八)--系统设计

Python后端技术栈(八)--系统设计

作者头像
小闫同学啊
发布于 2019-07-18 08:24:41
发布于 2019-07-18 08:24:41
1.6K00
代码可运行
举报
文章被收录于专栏:小闫笔记小闫笔记
运行总次数:0
代码可运行

正文共:3342 字 1 图 预计阅读时间:10 分钟

每日分享

Breathe. Take care. Stand still for a minute. What you are looking for might just be looking for you too.

呼吸。 放轻松。 静止一会儿。 您正在寻找的也可能只是在寻找您。

小闫语录:

充实自己,提升自己,照顾好自己,以全盛的姿态去迎接即将到来的、你要寻找的东西。它不会缺席,迟到只是浪费时间在寻找你的路上。不要放弃,更不要为了寻找变的狼狈。

1.8系统设计

上篇文章传送门『我是个链接

上篇文章对 Python web 框架中的一些经典问题做了总结,比如 WSGI、web 框架、网络安全问题、RESTful 以及 RESTful API

本篇文章将开始系统设计的相关内容,开始咯~

1.8.1 系统设计相关内容

1.什么是系统设计

2.系统设计需要掌握哪些知识

3.如何设计以及如何实现一个后端系统服务的设计

1.8.1.1 什么是系统设计 System Design

系统设计是一个定义系统架构、模块、接口和数据满足特定需求的过程。比如设计一个短网址服务、评论服务、Feed流系统(微博、知乎)、抢红包系统。这些系统设计是最近几年才开始流行起来的,因为现在很多的公司开始采用了微服务架构,在微服务架构之下很多系统被按照业务拆分,需要单独设计一个系统服务。

举个例子,比如短网址服务。一开始是由于 Twitter 只能发 140 个字,很多时候贴一个网址就快占满了,为了解决这个问题,诞生了短网址服务。简单的说就是根据一个长地址生成一个短地址,现在很多网站,比如头条、微博、知乎,大家都能见到这种类似形式的短网址。 在一个公司中会有很多不同的部门,不同的业务,不可能为每一个业务都开发一套。这个时候,公司里可以提供一个供所有业务使用的短网址服务。所有有需要的业务都可以向短网址服务请求接口,获取一个短网址。这就是短网址服务诞生的场景。

1.8.1.2 系统设计的难点

系统设计是中高级工程师必经之路。需要具备相关领域、算法的经验,有一定的架构设计能力。还需要熟悉后端的技术组件,比如消息队列、缓存、数据库和各种 web 框架。我们需要掌握它们的使用场景以及底层原理。比如什么时候去使用缓存?数据同步的问题如何去解决?业务的选型(关系型数据库还是非关系型)?另外一点就是具备文档撰写、流程图绘制、架构设计、编码实现等综合能力。

1.8.1.3 系统设计的要素

系统设计有三大要素

1.适用场景和限制条件;

2.数据存储设计;

3.算法模块设计。

1.8.1.4 要素之一:场景和限制

1.这个系统是在什么地方使用的?比如短网址系统提供给站内各种服务生成短网址。

2.限制条件:用户估计有多少?至少要能支撑多少用户(服务)?

3.估算并发 qps:峰值 qps 是多少?平均 qps 是多少?

qps :每秒的查询请求量

1.8.1.5 要素之二:数据存储设计

数据库的选型:

1.按需求设计数据表,需要哪些字段,使用什么类型?数据增长的规模等。

2.数据库选型:是否需要持久化?使用关系型还是 NoSQL

3.如何优化?如何设计索引?是否可以使用缓存?

1.8.1.6 要素之三:算法模块设计

算法解决问题的核心。程序 = 算法 + 数据结构系统 = 服务 + 存储

1.需要哪些接口?接口如何设计?

2.使用什么算法或者模型?

3.不同实现方式之间的优劣对比,如何取舍?

1.8.1.7 延伸问题

1.用户多了,qps 高了如何处理?

2.数据库存储多了,不够存了如何处理?

3.故障如何处理?单点失败、多点失败、雪崩等问题

1.8.2 系统设计案例-短网址系统设计与实现

1.8.2.1 如何设计与实现一个短网址系统

我们需要考虑下面的几个问题:

1.什么是短网址系统?包含哪些功能(接口)?

2.短网址系统的存储设计?需要存储哪些字段?

3.如何设计算法生成短网址?

1.8.2.2 什么是短网址系统

TinyURL Service,也就是把一个长网址转成短网址的服务。比如 https://bitly.com/(这个网站可以将长网址变成短网址)。转换之后网址的后缀不超过 7 位(字符或者数字)。

1.8.2.3 场景和限制

使用场景:提供短网址服务为公司各业务服务

功能:一个长网址转成短网址并存储;根据短网址还原长 url。

要求:短网址的后缀不超过 7 位(大小写字母和数字)

预估峰值插入请求数量级:数百

查询请求数量级:数千

1.8.2.4 数据存储设计

根据上面的需求,我们使用 MySQL 就可以满足。接下来再思考一下需要的字段有哪些?id 、生成之后的短网址、长网址和生成时间 4 个字段即可。如下:

id

token

url

created_at

自增长编号

短网址生成的 token,不存储整个短网址,因为希望前面的主机名可以随意的替换。此字段建立索引

原网址

创建时间

1.8.2.5 算法实现设计

我们需要考虑短网址生成算法有哪些,然后对比它们的优缺点。

1.首先我们需要提供两个 API 接口。一个是 long2short_url,一个是 short2long_url

我们既要将长网址生成短网址,又要还原查询到跳转网址。

2.常用算法: hash 算法截取;自增序列算法

3.对比多种算法,我们采取自增序列算法实现

短网址生成算法:

这个问题很抽象,我们可以先进行转化一下。也就是每一个长网址从下面的字符集中生成一个不超过 7 位长度的短网址的 token:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"

再简单点就是 token 里面的每一个字符都来自上面的字符集。

1.md5 摘要算法是否可以呢?毕竟它可以将任意长度的字节,生成一个定长的字符。此算法多用在我们下载文件的时候,会使用 md5 校验值检查文件是不是被修改了。

利用下面的代码实现:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
import hashlib
hashlib.md5(url.encode()).hexdigest()

大家实验过之后应该会发现它是一个 32 位定长的字符串。但是我们需要 7 位啊?有人会想我们可以截断,比如取前面7个值或者后面7个字符等方式。虽然可以实现,但是会有一定概率的冲突,一旦有冲突,我们在插入的时候还需要去数据库检查一下,这样在高并发的情况下是非常不友好的。

2.如果我们把每一个自增长的 id 生成一个不重复的短网址的 token 呢?想法是不是很美好。我们先来看一下字符集的特点。一共有 62 个字符( 26 个小写英文,26 个大写英文外加 10 个数字,也就是字符集的长度总和为 62),我们需要生成的 token 最长为 7 位,每一位上面都有 62 种可能性,也就是 62 的 7 次幂,是多大呢?万亿级,足够使用了,nice ~。

如果你仔细观察给出的 CHARS 字符集,你会发现它是一个类似于 62 位进制的数字。如果还是不好理解,我们一步一步来,大家都知道二进制的可选项是 0,1 对吧?十六进制是 0 - 9 加 a - f 。而我们此处的 62 进制可选项就是字符集中字符了,此处当然不是严格的 62 进制这样的数字,而是字符集中 0 到 61 位上的每一个字符都与之对应。

简单的说就是根据自增 id 来给每一个长网址生成一个 62 进制的短网址。下面又有问题了,那就是怎么将 10 进制的 id 转换成 62 进制的短网址呢?

先看一个简单的例子,怎么将 10 进制转化成 2 进制。口诀就是不断取余,倒叙输出。Python 中 bin 这个函数可以进行转化,但是我们不用,我们傲娇,我们要自己用代码实现一下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
def mybin(num): # 10进制 -> 2进制
    if num == 0:
        return 0
    res = []
    while num:
        # 如果10进制要转化成62进制,将下面的2改为62即可
        num, rem = divmod(num, 2)
        res.append(str(rem))
    return ''.join(reversed(res))

里面涉及到一个函数 divmod,我们先来看一下它的简介,然后再举个例子:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
In [1]: divmod?
Signature: divmod(x, y, /)
Docstring: Return the tuple (x//y, x%y).  Invariant: div*y + mod == x.
Type:      builtin_function_or_method

In [2]: divmod(10, 2)
Out[2]: (5, 0)

我们可以看到传了两个数之后,返回一个元祖,第一个是取整数,第二个是取余数。

然后编写一段代码,实现 10 进制数字转化为上述字符集 62 进制字符串:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"

def encode(num):
    if num == 0:
        return CHARS[0]
    res = []
    while num:
        num, rem = divmod(num, len(CHARS))
        res.append(CHARS[rem])
    return ''.join(reversed(res))

我们将上面的算法称为 递增序列算法,通过这个算法生成短网址。但是还有一个问题,就是数据库只有在插入的时候才有自增 id 。因此我们需要有一个全局的计数器,用来生成自增的 id。计数器可以使用 Redis 的 incr 实现。

下面回顾一下流程

一个请求过来之后,我们先去 Redis 中拿到 incr 的值,然后将值转化成 62 进制串,最后将其保存到 MySQL 中就可以了。

下面我们使用 flask 实现一个短网址服务:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
import os

from flask import Flask, jsonify, render_template, request
from flask_mysqldb import MySQL
from flask.ext.redis import FlaskRedis

app = Flask(__name__)
app.config['MYSQL_USER'] = 'root'
# 此处填写自己电脑的密码
app.config['MYSQL_PASSWORD'] = os.getenv('MYSQL_PASS')
app.config['MYSQL_DB'] = 'test'
app.config['MYSQL_CURSORCLASS'] = 'DictCursor'

mysql = MySQL(app)
redis_store = FlaskRedis(app)

CHARS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"

def encode(num):
    if num == 0:
        return CHARS[0]
    res = []
    while num:
        num, rem = divmod(num, len(CHARS))
        res.append(CHARS[rem])
    return ''.join(reversed(res))

@app.route('/shorten', methods=['POST'])
def shorten_url():
    long_url = request.json['url']
    index = int(redis_store.incr('SHORT_CNT'))
    token = encode(index)
    sql = "INSERT INTO short_url(token, url) VALUES(%s, %s)"
    cur = mysql.connection.cursor()
    cur.execute(sql, (token, long_url))
    mysql.connection.commit()
    shourt_url = 'https://short.com/' + token
    return jsonify(url=short_url)

@app.route('/')
def index():
    return render_template('index.html')

if __name__ == '__main__':
    app.run(debug=True)

数据库所需表:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CREATE TABLE short_url (
    id bigint unsigned NOT NULL AUTO_INCREMENT,
    token varchar(10),
    url varchar(2048),
    created_at timestamp NOT  NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`),
    KEY `idx_token` (`token`)
);

前端页面此处不提供,只提供后端代码。

结束语

截止到现在,这一系列的笔记就完成了!当然,这八篇文章不可能面面俱到,只能将一些重点提到,树的枝干有了之后,就看大家去如何丰富了,希望这些笔记对大家有所帮助。每天其实最开心的就是晚上看到后台增长的粉丝数。虽然我只是一个很小的公众号,内容也不是多么精彩,但是我愿意不断的进步,也希望大家随着我一起进步。完全的免费,只有你们的认可才是我坚持下去的动力,所以喜欢就分享出去,让更多的人看到吧。

优质文章推荐:

redis操作命令总结

MySQL相关操作

SQL查询语句

前端中那些让你头疼的英文单词

Flask框架重点知识总结回顾

团队开发注意事项

浅谈密码加密

Django框架中的英文单词

Django中数据库的相关操作

DRF框架中的英文单词

DRF框架

Django相关知识点回顾

python技术面试题-腾讯

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-06-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 全栈技术精选 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
ZFS文件系统服务器无法读取修复案例
今天为大家介绍的数据恢复成功案例服务器型号为:ORACLE-SUN-ZFS7320。服务器内涉及硬盘32块,服务器操作采用的是Windows操作系统。
北亚数据安全与救援
2020/11/04
2K0
ZFS文件系统服务器无法读取修复案例
ZFS文件系统与Freenas介绍
ZFS文件系统的英文名称为Zettabyte File System,也叫动态文件系统(Dynamic File System),是第一个128位文件系统。最初是由Sun公司为Solaris 10操作系统开发的文件系统。作为OpenSolaris开源计划的一部分,ZFS于2005年11月发布,被Sun称为是终极文件系统,经历了 10 年的活跃开发。而最新的开发将全面开放,并重新命名为 OpenZFS。
DB之路
2021/04/30
5.1K0
HP存储RAID5硬盘离线LVM下VXFS文件系统恢复教程分享
在HP存储RAID5硬盘离线LVM下VXFS文件系统是如何进行恢复的呢?HP存储也是在企业中常用的存储设备了,本次分享的故障设备为:HP FC MSA2000存储,由于RAID5阵列中出现2块硬盘损坏并离线,而此时只有一块热备盘成功激活,因此导致RAID5阵列瘫痪,上层LUN无法正常使用,整个存储空间由8块450GB SAS的硬盘组成,其中7块硬盘组成一个RAID5的阵列,剩余1块做成热备盘使用。
北亚数据安全与救援
2021/05/07
8480
HP存储RAID5硬盘离线LVM下VXFS文件系统恢复教程分享
存储硬盘离线VXFS文件系统恢复教程
图片1.png 服务器数据恢复故障描述 客户的服务器共有8块450GB SAS硬盘,其中7块硬盘组成一个RAID5阵列,1块热备盘。阵列中2块硬盘损坏并离线,导致RAID5阵列瘫痪,进而影响上层LUN无法正常使用。经工程师检测硬盘无物理故障,无坏道,随后北亚工程师将所有磁盘镜像成文件。 数据恢复过程 一、RAID组结构及掉线盘分析 服务器的LUN都是基于RAID组的,所以需要先对底层RAID组的信息作出分析,再依据这些数据重构原始的RAID组。通过分析得知4号盘为hot Spare盘。继续分析Oracl
北亚数据安全与救援
2021/05/27
2.8K0
存储硬盘离线VXFS文件系统恢复教程
EMC存储崩溃恢复案例
本次分享的案例为EMC FC AX-4存储崩溃,整个存储空间由12块1TB STAT的硬盘组成的,其中10块硬盘组成一个RAID5的阵列,其余两块做成热备盘使用。由于RAID5阵列中出现2块硬盘损坏,而此时只有一块热备盘成功激活,因此导致RAID5阵列瘫痪,上层LUN无法正常使用。由于存储是因为某些磁盘掉线,从而导致整个存储不可用。因此接收到磁盘以后先对所有磁盘做物理检测,检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道,发现也没有坏道。
北亚数据安全与救援
2020/11/24
2K0
存储崩溃的数据恢复通用方法
服务器数据恢复指的是通过技术手段将原本存储在服务器、存储设备内的,由于误操作、硬件故障、恶意攻击等原因丢失的数据进行修复提取的专业技术。在介绍服务器数据恢复前我们首先需要了解服务器的数据结构、文件存储原理,今天小编通过一起华为s5300服务器数据介绍该型号服务器的数据存储结构和数据恢复原理。
北亚数据恢复中心
2019/12/10
9350
存储崩溃的数据恢复通用方法
存储瘫痪抢救Oracle数据库案例
本次分享的案例是关于HP FC MSA2000存储瘫痪抢救Oracle数据库的案例,故障存储整个存储空间由8块硬盘组成,其中7块硬盘组成一个RAID5的阵列,剩余1块做成热备盘使用。由于RAID5阵列中出现2块硬盘损坏,而此时只有一块热备盘成功激活,因此导致RAID5阵列瘫痪,上层LUN无法正常使用。 由于存储是因为RAID阵列中某些磁盘掉线,从而导致整个存储不可用。因此接收到磁盘以后先对所有磁盘做物理检测,检测完后发现没有物理故障。排除物理故障后对数据全部备份后在进行进一步的分析。 【故障分析】 1、分析故障原因 由于前两个步骤并没有检测到磁盘有物理故障或者是坏道,由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为HP MSA2000控制器检查磁盘的策略很严格,一旦某些磁盘性能不稳定,HP MSA2000控制器就认为是坏盘,就将认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘到达到RAID级别允许掉盘的极限,那么这个RAID组将变的不可用,上层基于RAID组的LUN也将变的不可用。目前初步了解的情况为基于RAID组的LUN有6个,均分配给HP-Unix小机使用,上层做的LVM逻辑卷,重要数据为Oracle数据库及OA服务端。 2、分析RAID组结构 HP MSA2000存储的LUN都是基于RAID组的,因此需要先分析底层RAID组的信息,然后根据分析的信息重构原始的RAID组。分析每一块数据盘,发现4号盘的数据同其它数据盘不太一样,初步认为可能是hot Spare盘。接着分析其他数据盘,分析Oracle数据库页在每个磁盘中分布的情况,并根据数据分布的情况得出RAID组的条带大小,磁盘顺序及数据走向等RAID组的重要信息。 3、分析RAID组掉线盘 根据上述分析的RAID信息,尝试通过北亚RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中一共掉线两块盘,因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据,发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样,因此初步判断此硬盘可能是最先掉线的,通过北亚RAID校验程序对这个条带做校验,发现除掉刚才分析的那块硬盘得出的数据是最好的,因此可以明确最先掉线的硬盘了。 4、分析RAID组中的LUN信息 由于LUN是基于RAID组的,因此需要根据上述分析的信息将RAID组最新的状态虚拟出来。然后分析LUN在RAID组中的分配情况,以及LUN分配的数据块MAP。由于底层有6个LUN,因此只需要将每一个LUN的数据块分布MAP提取出来。然后针对这些信息编写相应的程序,对所有LUN的数据MAP做解析,然后根据数据MAP并导出所有LUN的数据。 【数据恢复过程】 1、解析修复LVM逻辑卷 分析生成出来的所有LUN,发现所有LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息,发现其中一共有三套LVM,其中45G的LVM中划分了一个LV,里面存放OA服务器端的数据,190G的LVM中划分了一个LV,里面存放临时备份数据。剩余4个LUN组成一个2.1T左右的LVM,也只划分了一个LV,里面存放Oracle数据库文件。编写解释LVM的程序,尝试将每套LVM中的LV卷都解释出来,但发现解释程序出错。 仔细分析程序报错的原因,安排开发工程师debug程序出错的位置,并同时安排高级文件系统工程师对恢复的LUN做检测,检测LVM信息是否会因存储瘫痪导致LMV逻辑卷的信息损坏。经过仔细检测,发现确实因为存储瘫痪导致LVM信息损坏。尝试人工对损坏的区域进行修复,并同步修改程序,重新解析LVM逻辑卷。 2、解析VXFS文件系统 搭建环境,将解释出来的LV卷映射到搭建好的环境中,并尝试Mount文件系统。结果Mount文件系统出错,尝试使用“fsck –F vxfs” 命令修复vxfs文件系统,但修复结果还是不能挂载,怀疑底层vxfs文件系统的部分元数据可能破坏,需要进行手工修复。 3、修复VXFS文件系统 仔细分析解析出来的LV,并根据VXFS文件系统的底层结构校验此文件系统是否完整。分析发现底层VXFS文件系统果然有问题,原来当时存储瘫痪的同时此文件在系统正在执行IO操作,因此导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复,保证VXFS文件系统能够正常解析。再次将修复好的LV卷挂载到HP-Unix小机上,尝试Mount文件系统,文件系统没有报错,成功挂载。 4、检测Oracle数据库文件并启动数据库 在HP-Unix机器上mount文件系统后,将所有用户数据均备份至指定磁盘空间。所有用户数据大小在1TB左右。 使用Oracle数据库文件检测工具“dbv”检测每个数据库文件是否完整,发现并没有错误。再使用北亚Oracle数据库检测工具,发现有部分数据库文件和日志文件校验不一致,安排北亚工程师对此类文件进行修复
北亚数据安全与救援
2021/11/15
7350
恢复服务器安装信息被破坏了,服务器存储瘫痪数据恢复成功案例-服务器数据恢复…
机房突然断电导致整个存储瘫痪,加电后存储依然无法使用。经过用户方工程师诊断后认为是断电导致存储阵列损坏。
全栈程序员站长
2022/06/24
3.3K0
恢复服务器安装信息被破坏了,服务器存储瘫痪数据恢复成功案例-服务器数据恢复…
服务器崩溃导致数据库损坏的修复方法
故障服务器上一共16块FC硬盘,单盘容量600G。存储前面板10号和13号硬盘亮黄灯,存储映射到redhat上的卷挂载不上,服务器业务崩溃。
北亚数据恢复中心
2019/10/25
2.7K0
存储上的数据丢失了怎么恢复
需要进行数据恢复的服务器共10个磁盘柜,每个磁盘柜满配24块硬盘。其9个存储柜用作数据存储使用,另外1个存储柜用作元数据存储使用。元数据存储中共24块146G硬盘,其中设置了9组RAID 1阵列,1组4盘位RAID 10阵列,4个全局热备硬盘。
北亚数据恢复中心
2019/08/21
2.2K0
存储上的数据丢失了怎么恢复
存储卷丢失,虚拟机不可访问的解决方法,数据全恢复
存储环境部署及存储数据恢复故障的起因:某公司的NetApp FAS-8200存储,使用96块磁盘组建两组存储池,存储池互为镜像。存储池内划分卷并映射到ESXI作为数据存储使用,卷内虚拟机数量约300+。在操作过程中由于未知原因导致卷丢失,卷内虚拟机不可访问。该公司的管理员先进对存储进行了简单的检查和数据恢复但是没有成功,由于存储内有公司重要数据,管理员不敢妄动,只好联系北京的存储数据恢复公司进行专业数据恢复。
北亚数据恢复中心
2019/08/06
2K0
存储卷丢失,虚拟机不可访问的解决方法,数据全恢复
服务器数据恢复案例介绍;服务器崩溃修复
某法院的一台服务器由于硬盘出现故障导致服务器崩溃,在当地一家数据恢复机构进行了数据恢复操作,但是数据恢复没有成功,于是负责人在北京寻找服务器数据恢复公司进行数据恢复。这台服务器的基本配置情况如下图中所示。
北亚数据恢复中心
2019/10/23
1.9K0
服务器数据恢复案例介绍;服务器崩溃修复
服务器文件系统损坏,只需要这个教程轻松解决
今天为大家介绍一个Linux服务器数据恢复成功案例,本次服务器数据恢复物理服务器请款如下:客户故障服务器为一台X3850服务器,这个服务器是由4块146G SAS硬盘组成的RAID5作为存储介质,文件系统全都是reiserfs。我们首先经过分析发现了之前的硬盘数据组织结构是由一个不到100M的boot分区,后接一个271G的LVM卷,之后是2G的swap分区。LVM卷中直接划分了一个reiserfs文件系统,作为根分区。
北亚数据恢复中心
2020/02/05
1.4K0
服务器文件系统损坏,只需要这个教程轻松解决
DELL服务器数据恢复成功案例
DELL EqualLogic PS6100采用虚拟ISCSI SAN阵列,为远程或分支办公室、部门和中小企业存储部署带来企业级功能、智能化、自动化和可靠性。以简化的管理、快速的部署及合理的价格满足了分支办公室和中小企业的存储需求,同时提供全套企业级数据保护和管理功能、可靠的性能、可扩展性和容错功能,是中型企业级存储的起点产品,但某些物理故障或其他操作都可能会对卷或存储造成破坏,因此对系列存储的数据恢复技术才有了用武之地。而发生这些故障之后只能找专业的数据恢复公司做数据挽救工作。北亚数据恢复中心宋工最近处理过一起DELL EqualLogic PS 6100因磁盘故障导致存储不可用的案例:
全栈程序员站长
2022/09/07
1.5K0
DELL服务器数据恢复成功案例
VSAN存储结构解析+存储数据恢复案例
今天给大家介绍一的是一款常见存储设备-Vsan的结构原理,相对而言技术性文字较多。VSAN是一种以vSphere内核作为基础开发出来的一款可以扩展使用的分布式存储架构。这款存储在vSphere集群主机中安硬盘及闪存构建出VSAN存储层,通过存储进行管理与控制,最终形成一个共享存储层。
北亚数据恢复中心
2019/10/18
1.5K0
VSAN存储结构解析+存储数据恢复案例
SQL server数据库恢复案例分析
本次故障环境为4台服务器,每台服务器12块盘分为2组raid,共8组raid。经客户描述共4个节点,其中一个节点故障之后仍在继续使用,第二个节故障之后,进行过一系列的重新上线操作,导致管理存储软件无法使用。 为防止在数据恢复过程中由于部分操作对原始磁盘造成不可还原的修改,导致数据出现二次丢失,对原始磁盘进行镜像备份。北亚工程师进行详细分析,获取到5台节点服务器上的所有硬盘的底层镜像。经过分析,发现底层部分索引位图被破坏。对全部镜像文件进行分析,根据底层数据重组raid,并提取每组raid中的map,对数据map进行分析,根据位图手工索引数据,排除部分损坏位图。客户主要数据为SQL server数据库,经初步检测,索引位图有部分损坏,因此若提取数据卷后数据有损坏,可针对数据库进行修复。 【数据恢复过程】 1.重组RAID 工程师对RAID条带大小、盘序、校验方向的关键信息分析后,判断成员盘离线顺序。分别对十组RAID进行重组,并生成RAID镜像文件。
北亚数据安全与救援
2021/11/08
8490
构建我的第一个 22TB 容量的家庭存储服务器
今年我决定给自己量身定制一台家庭网络存储服务器(也就是 NAS),预计存储容量有 32TB,并使用开源的操作系统,用来存储我的个人和商业数据。
米开朗基杨
2022/11/07
6.5K0
构建我的第一个 22TB 容量的家庭存储服务器
Oracle数据库恢复案例
客户故障存储设备为IBM V5000存储,由于存储设备的控制器损坏,导致存储中数据卷无法访问,需恢复数据卷中的Oracle数据库文件。
北亚数据安全与救援
2020/12/02
1.6K0
Oracle数据库恢复案例
RAID出故障如何做好应急处理
当RAID出现: 1、RAID控制台里描述超过允许范围内的盘数异常,如RAID0里一块以上盘异常;RAID5(无热备)里2块以上盘异常;异常表现为OFFLINE或DDD、BAD等;2、服务器存储系统报警(喇叭或警示灯);3、系统无法识别RAID 逻辑硬盘等问题时,现场工程师应该如何操作才能挽救数据呢?(此方案适用 IBM、HP、SUN、DELL、DFT、APPLE、联想、方正等品牌服务器;RAID0、RAID1、RAID2、RAID3、RAID4、RAID5、RAID6、HP ADG、RAID10、RAID50、RAID1E、RAID5E、RAID5EE等;NAS、DAS、SAN等。)
北亚数据安全与救援
2021/04/07
1.9K0
RAID出故障如何做好应急处理
IBM存储RAID5数据恢复案例
本次北亚小编分享的案例是关于IBM存储DS3512,6块盘,坏了多块盘,导致阵列失效,数据丢失。
北亚数据安全与救援
2021/02/01
1.5K0
IBM存储RAID5数据恢复案例
推荐阅读
相关推荐
ZFS文件系统服务器无法读取修复案例
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验