安安 - 文件
type: channel
link: https://blog.90.vc/tag/%E6%96%87%E4%BB%B6/
items: SSD阵列卡方案优化：考虑使用RAID 50替代RAID 10
items: 获取HeidiSQL保存的密码
items: fstab配置项里最后两个数字代表的含义
items: nginx 处理请求的11个阶段
items: Kafka的集群部署实践及运维相关
items: Kubernetes 内部组件工作原理
items: HTTP Content-Type对照表
items: RAID5 真的安全吗
items: Cache 和 Buffer 有什么区别？
items: macOS升级到Catalina之后使用SecureCRT报错问题

SSD阵列卡方案优化：考虑使用RAID 50替代RAID 10
type: item
date: 2020-06-03T03:52:00+00:00
description: 大家都知道SSD成本比较高，而不少用户在考虑可用性时都会选用RAID 10作阵列，这样无疑又增加了成本。然而RAID 10的可用性也并非百分百完美。为了能够平衡可用性和成本，因此最近一直在研究性价比更高的RAID 50，它提供了接近RAID 10的可用性并且接近RAID 5的成本，像是在高可用的RAID 10和低成本的RAID 5之间的取了一个平衡点。为了能够直观了解不同RAID类型下的故障可用性，我们首先做个简单的可用性分析（以8盘RAID 10的同等容量作对比）：*RAID 50中：4块盘组成单组RAID 5，然后两组RAID 5再组成RAID 0最后得到8块盘的RAID 50*案例分析：第1块盘的容错概率都是100%，可见磁盘阵列最基本的能力就是容错，然而不同级别的阵列能够提供的数据保护能力也是不同的；从第2块盘开始除了RAID 6能够提供100%的故障可用性以外，其他包括RAID 10在内都不能提供完美的解决方案。同时我们可以发现RAID 5的容错能力是四者中最差的，但是要达到同样容量所需要的盘数量也是最少的，如果故障运维较为及时的话RAID 5是一个性价比较高的方案，不然在第一块盘故障后至阵列修复期间如果发生第二块盘故障就会导整个阵列故障（数据全部丢失），这就是风险所在；RAID 6当然是较为可靠的方案，但是它要牺牲两块盘的容量并且性能也较差（后面有性能测试说明），所以要权衡性能和可用性；当然重点还是RAID 10和50：我们发现50在第二块盘故障时的可用概率和10比较接近，由于上述案例中只有两组RAID 5因此只能提供至最多两块盘的容错，如果RAID 5的组数量更多的话能够容错的盘数也将更多，且可用概率也会更高。我们以9块盘RAID 50（3组RAID 5）为例作分析（达到相同容量的RAID 10需要12块盘）：再以12块盘RAID 50（4组RAID 5）为例作分析（达到相同容量的RAID 10需要16块盘）：上面对比中RAID 50已经能够容忍第3甚至第4块盘的故障，只是可用性相比RAID 10低了些，但是两者都不能达到完美的100%，所以权衡可用性和成本RAID 50还是有相当大的优势。接下来看看性能，为了能够很好地分析性能，我们沿用了第一组对比方案的作性能分析：随机读分析：理论上认为R10性能最好，真实测试数据显示4K、8K数据块下R5、R50、R6的性能都要优于R10；当数据块增大到16K、32K时，R10的多盘优势才被逐渐体现出来。随机写分析：4K由于R50、R5由于有大量校验计算一定程度上影响了性能，但随着数据块逐渐增大，盘数量的优势也显现出来。当数据块达到和超过8K时，R50性能全面超越了R10；R10由于存在R1的写同步问题，因此只有4块盘在支撑并发写，随着数据块的增大，R50和R5的多盘性能优势开始发挥。混合随机读写分析：得益多盘和无校验计算，混合读写R10领先；R50其次，和R10相差27%，性能也较为接近，R5和R50性能为线性关系，R6性能最差。顺序读分析：由于不存在校验计算，顺序读性能基本上由盘的数量决定；R50和R10性能也较为接近，同盘数的R6和R50性能相当，而盘数较少的R5性能相对前三者要弱一些，符合预期。至于为何R10性能无法线性增加，主要是因为阵列卡本身的性能限制。顺序写分析：顺序写R5被优化得最好；R50由于需要同时计算两次校验因此损失了一些性能，和R10性能相当，当数据块达到512K时，多盘优势进一步体现出来了，拉开了与R10的差距；R6由于校验和计算的实现较为复杂，顺序写性能也是最差的。再来看看这些阵列方案的性能和容错特性：性能测试结论：性能测试显示，相同容量的R50和R10性能接近：其中小块文件的随机读R50要全面好于R10，随机写4K虽然R50和R10差距在28%，但是块增大后R50要全面优于R10。顺序读写方面，R50和R10十分接近。容错方面，R50接近R10：第二块盘容错率R50十分接近R10，两者相差30%。R10的优势主要是在有一定的概率提供第三、甚至第四块磁盘的容错率，但是考虑到并非100%容错，因此从容错角度来看R50虽然和R10有一些差距，但也已体现出较好的容错率，至少优于R5。而且R50搭配灵活，甚至可以指定3组R5以达到最大3块磁盘的容错；成本方面，R50有很大优势：按这个配置计算R50只有R10的3/4。总结：RAID 50提供了接近RAID 10性能、可用性以及接近RAID 5成本的特性，具有较好的整体性价比优势，所以考虑使用RAID 50替换RAID 10把！

获取HeidiSQL保存的密码
type: item
date: 2020-05-09T05:40:00+00:00
description: 今天在使用一个数据库时一是半会想不起来数据库的密码了，后来想起来在客户端工具heidisql上有保存过密码，下面讲解如何获取heidisql保存的密码。HeidiSQL是一款开源的SQL管理工具，用于管理MYSQL,MSSQL 等数据库，很多管理工具都会把密码存在本地，HeidiSQL也是如此，但是只是经过非常简单的编码，解密的过程如下。使用的是版本是HeidiSQL_11.0_64_Portable,配置会存在软件目录下的portable_settings.txt中,如果是安装的版的话，HeidiSQL安装版会配置信息存在以下注册表中：HKEY_CURRENT_USER\Software\HeidiSQL\密码会保存在以下节点下面。HKEY_CURRENT_USER\Software\HeidiSQL\Servers打开portable_settings.txt可以看到配置文件中有以下这样的ip 密码之类这样的信息HeidiSQL配置文件节选:Servers\192.168.1.1\SessionCreated<|||>1<|||>2020-04-23 09:11:48 Servers\192.168.1.1\Host<|||>1<|||>192.168.1.1 Servers\192.168.1.1\WindowsAuth<|||>3<|||>0 Servers\192.168.1.1\CleartextPluginEnabled<|||>3<|||>0 Servers\192.168.1.1\User<|||>1<|||>root Servers\192.168.1.1\Password<|||>1<|||>6A6A6A9 Servers\192.168.1.1\LoginPrompt<|||>3<|||>0 Servers\192.168.1.1\Port<|||>1<|||>3306 Servers\192.168.1.1\NetType<|||>3<|||>0 Servers\192.168.1.1\Compressed<|||>3<|||>0 Servers\192.168.1.1\LocalTimeZone<|||>3<|||>0 Servers\192.168.1.1\QueryTimeout<|||>3<|||>30 Servers\192.168.1.1\KeepAlive<|||>3<|||>20 Servers\192.168.1.1\FullTableStatus<|||>3<|||>1 Servers\192.168.1.1\Databases<|||>1<|||> Servers\192.168.1.1\Library<|||>1<|||>libmysql-6.1.dll Servers\192.168.1.1\Comment<|||>1<|||> Servers\192.168.1.1\StartupScriptFilename<|||>1<|||> Servers\192.168.1.1\TreeBackground<|||>3<|||>536870911 Servers\192.168.1.1\SSHtunnelHost<|||>1<|||> Servers\192.168.1.1\SSHtunnelHostPort<|||>3<|||>22 Servers\192.168.1.1\SSHtunnelUser<|||>1<|||> Servers\192.168.1.1\SSHtunnelPassword<|||>1<|||>1 Servers\192.168.1.1\SSHtunnelTimeout<|||>3<|||>4 Servers\192.168.1.1\SSHtunnelPrivateKey<|||>1<|||> Servers\192.168.1.1\SSHtunnelPort<|||>3<|||>3307 Servers\192.168.1.1\SSL_Active<|||>3<|||>0 Servers\192.168.1.1\SSL_Key<|||>1<|||> Servers\192.168.1.1\SSL_Cert<|||>1<|||> Servers\192.168.1.1\SSL_CA<|||>1<|||> Servers\192.168.1.1\SSL_Cipher<|||>1<|||> Servers\192.168.1.1\ServerVersionFull<|||>1<|||>5.7.29 - MySQL Community Server (GPL) Servers\192.168.1.1\ConnectCount<|||>3<|||>7 Servers…

fstab配置项里最后两个数字代表的含义
type: item
date: 2020-05-05T10:09:19+00:00
description: Linux中/etc/fstab配置项里最后两个数字代表的含义如下第一个叫fs_freq，用来决定哪一个文件系统需要执行dump操作;第二个叫fs_passno，是系统重启时fsck程序检测磁盘的顺序号。fs_freq的作用：在 Linux 当中，可以利用 dump 这个指令来进行系统的备份。而 dump 指令则会针对 /etc/fstab 的设定值，去选择是否要将该 partition 进行备份的动作。0 代表不要做 dump 备份， 1 代表要进行 dump 的动作。 2 也代表要做 dump 备份动作， 不过，该 partition 重要度比 1 小。fs_passno的作用：开机的过程中，系统预设会以 fsck 检验我们的 partition 内的 filesystem 是否完整 (clean)。 不过，某些 filesystem 是不需要检验的，例如虚拟内存 swap ，或者是特殊档案系统， 例如 /proc 与 /sys 等等。所以，在这个字段中，我们可以设定是否要以 fsck 检验该 filesystem 。0 是不要检验， 1 是要检验， 2 也是要检验，不过 1 会比较早被检验， 一般来说，根目录设定为 1 ，其它的要检验的 filesystem 都设定为 2 就好了。

nginx 处理请求的11个阶段
type: item
date: 2020-05-05T09:58:48+00:00
description: nginx的处理用户请求的11 个阶段nginx将一个HTTP请求分为11个处理阶段，这样做让每个HTTP模块可以仅仅专注于完成一个独立，简单的功能。而一个请求的完整处理过程可以由多个HTTP模块共同合作完成。可以极大的提高多个模块合作的协同性，可测试性，可扩展性。换言之，nginx在处理每一个http请求，和配置文件上的顺序没有关系。1 post-read接受到完整的http头部后，读取请求内容阶段，nginx读取并解析完请求头之后就立即开始执行；2 server-rewrite在uri与location匹配之前修改请求的URI（重定向），在server块中的请求地址重写阶段；3 find-config配置查找阶段，根据请求uri匹配location表达式，这个阶段不支持nginx模块注册处理程序，而是由ngx_http_core_module模块来完成当前请求与location配置快之间的配对工作；4 rewritelocation块中的请求地址重写阶段，当rewrite指令用于location中，即运行。另外，ngx_lua模块中的set_by_lua指令和rewrite_by_lua指令也在此阶段；5 post-rewrite请求地址重写提交阶段，防止递归修改uri造成死循环，（一个请求执行10次就会被nginx认定为死循环）该阶段只能由ngx_http_core_module模块实现6 preaccess访问权限检查准备阶段，http模块介入处理阶段，标准模块ngx_limit_req和ngx_limit_zone就运行在此阶段，前置可以控制访问的频率，后者限制访问的并发度7 access访问权限检查阶段，标准模块ngx_access,第三方模块nginx_auth_request以及第三方模块ngx_lua的access_by_lua 指令运行在此阶段，配置指令多是执行访问控制性质的任务，比如检查用户的访问权限，检查用户的来源IP地址是否合法；8 post-access访问权限检查提交阶段；如果请求不被允许访问nginx服务器，该阶段负责向用户返回错误响应；9 try-files配置项try_files处理阶段如果http请求访问静态文件资源，try_files配置项可以使这个请求顺序地访问多个静态文件资源，直到某个静态文件资源符合选取条件；10 content内容产生阶段，大部分HTTP模块会介入该阶段，是所有请求处理阶段中最重要的阶段，因为这个阶段的指令通常是用来生成HTTP响应内容的；11 log日志模块处理阶段，记录日志；

Kafka的集群部署实践及运维相关
type: item
date: 2020-04-02T15:55:00+00:00
description: 一、Kafka的生产集群部署1.1 方案背景假设每天集群需要承载10亿数据。一天24小时，晚上12点到凌晨8点几乎没多少数据。使用二八法则估计，也就是80%的数据（8亿）会在16个小时涌入，而且8亿的80%的数据（6.4亿）会在这16个小时的20%时间（3小时）涌入。QPS计算公式：640000000 ÷ (3x60x60) = 60000，也就是说高峰期的时候Kafka集群要扛住每秒6万的并发。磁盘空间计算，每天10亿数据，每条50kb，也就是46T的数据。保存2个副本（在上一篇中也提到过其实两个副本会比较好，因为follower需要去leader那里同步数据，同步数据的过程需要耗费网络，而且需要磁盘空间，但是这个需要根据实际情况考虑），46 2 = 92T，保留最近3天的数据。故需要 92 3 = 276T1.2 QPS方面部署Kafka，Hadoop，MySQL···等核心分布式系统，一般建议直接采用物理机，抛弃使用一些低配置的虚拟机的想法。高并发这个东西，不可能是说，你需要支撑6万QPS，你的集群就刚好把这6万并发卡的死死的。加入某一天出一些活动让数据量疯狂上涨，那整个集群就会垮掉。但是，假如说你只要支撑6w QPS，单台物理机本身就能扛住4~5万的并发。所以这时2台物理机绝对绝对够了。但是这里有一个问题，我们通常是建议，公司预算充足，尽量是让高峰QPS控制在集群能承载的总QPS的30%左右（也就是集群的处理能力是高峰期的3~4倍这个样子），所以我们搭建的kafka集群能承载的总QPS为20万~30万才是安全的。所以大体上来说，需要5~7台物理机来部署，基本上就很安全了，每台物理机要求吞吐量在每秒4~5万条数据就可以了，物理机的配置和性能也不需要特别高。1.3 磁盘方面1.3.1 磁盘数量需要5台物理机的情况，需要存储276T的数据，平均下来差不多一台56T的数据。这个具体看磁盘数和盘的大小1.3.2 SAS还是SSD现在我们需要考虑一个问题：是需要SSD固态硬盘，还是普通机械硬盘？SSD就是固态硬盘，比机械硬盘要快，那么到底是快在哪里呢？其实SSD的快主要是快在磁盘随机读写，就要对磁盘上的随机位置来读写的时候，SSD比机械硬盘要快。比如说MySQL这种就应该使用SSD了（MySQL需要随机读写）。比如说我们在规划和部署线上系统的MySQL集群的时候，一般来说必须用SSD，性能可以提高很多，这样MySQL可以承载的并发请求量也会高很多，而且SQL语句执行的性能也会提高很多。因为写磁盘的时候kafka是顺序写的。机械硬盘顺序写的性能机会跟内存读写的性能是差不多的，所以对于Kafka集群来说其实使用机械硬盘就可以了。如果是需要自己创业或者是在公司成本不足的情况下，经费是能够缩减就尽量缩减的。1.4 内存角度JVM非常怕出现full gc的情况。kafka自身的jvm是用不了过多堆内存的，因为kafka设计就是规避掉用jvm对象来保存数据，避免频繁full gc导致的问题，所以一般kafka自身的jvm堆内存，分配个10G左右就够了，剩下的内存全部留给os cache。那服务器需要多少内存呢。我们估算一下，大概有100个topic，所以要保证有100个topic的leader partition的数据在操作系统的内存里。100个topic，一个topic有5个partition。那么总共会有500个partition。每个partition的大小是1G（在上一篇中的日志分段存储中规定了.log文件不能超过1个G），我们有2个副本，也就是说要把100个topic的leader partition数据都驻留在内存里需要1000G的内存。我们现在有5台服务器，所以平均下来每天服务器需要200G的内存，但是其实partition的数据我们没必要所有的都要驻留在内存里面，只需要25%的数据在内存就行，200G * 0.25 = 50G就可以了（因为在集群中的生产者和消费者几乎也算是实时的，基本不会出现消息积压太多的情况）。所以一共需要60G（附带上刚刚的10G Kafka服务）的内存，故我们可以挑选64G内存的服务器也行，大不了partition的数据再少一点在内存，当然如果能够提供128G内存那就更好。1.5 CPU coreCPU规划，主要是看你的这个进程里会有多少个线程，线程主要是依托多核CPU来执行的，如果你的线程特别多，但是CPU核很少，就会导致你的CPU负载很高，会导致整体工作线程执行的效率不太高，上一篇的Kafka的网络设计中讲过Kafka的Broker的模型。acceptor线程负责去接入客户端的连接请求，但是他接入了之后其实就会把连接分配给多个processor，默认是3个，但是一般生产环境建议大家还是多加几个，整体…

Kubernetes 内部组件工作原理
type: item
date: 2020-03-31T14:32:00+00:00
description: 翻译自:https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca原作者：Joe Beda (Dad of two. CTO of Heptio. Started Google Compute Engine, Kubernetes and Google Container Engine.)本篇文章讲述了Kubernetes内部组件的工作原理，及创建POD的流程。如果你是运维人员或者是Kubernetes的使用者，你可以不需要知道Kubernetes的内部工作原理，但是如果你想理解Kubernetes内部的工作原理，这篇文章非常适合你。读这篇文章的前提是，你已经大致了解并会运用Kubernetes。这篇文章不会去描述什么是Kubernetes及其组件（如：Pod, Node, Kubelet）。 本篇将讨论Kubernetes核心组件及这些核心组件是如何让Kubernetes 对"爵士乐即兴演奏"。通常将像Kubernetes这样的通用系统称为容器的 "管弦乐编排"。但是管弦乐编排，必须有一个预先计划的指挥家。因此，这并不是Kubernetes的一个好的描述。相反，Kubernetes更像是爵士乐即兴演奏，有一系列演员互相配合协调完成演奏。接下来，开始介绍每个核心组件的功能。然后将看一个典型的调度和启动一个Pod的流程。1. Datastore: EtcdEtcd是Kubernetes的存储状态的数据库。虽然Kubernetes系统中有重要的内存缓存，但Etcd被认为是记录系统状态。Etcd的快速总结：它是一个集群分布式数据库，它可以提供分布式数据的一致性。这类的系统（如Zookeeper, Consul）是在 Google开发的chubby系统之后形成的，这些系统也称为"锁服务器"，因为他们可以实现分布式锁。Etcd和chubby的数据模型是一个简单的层次化的Key，并存储了简单的非结构化value，这看起来像是一个文件系统。有意思的是，在Google, chubby 被频繁用于为实现访问本地文件和对象存储的功能的抽象文件接口。然而，分布式数据库的高度一致性，提供了数据的严格写入顺序并允许client原子性的对数据做更新操作。可靠的系统的状态管理是任何系统中非常困难的一件事情。在分布式系统中，它是更加困难的，因为它引入了一致性算法，如raft或paxos。通过使用etcd，Kubernetes可以专注系统的其他部分。Etcd的watch机制是Kubernetes工作的关键。系统允许client去执行轻量级的对于Key值变化事件的订阅。当要watch的数据发生变化时, client会立即得到通知。这可以用作分布式系统组件之间的协调机制。 一个组件一旦写入etcd，其他组件可以立即对该变化作出反应。Etcd的消息机制正好和PubSub消息队列机制相反。在许多消息队列系统系统中，topic不存储真正的用户数据，但发布到这些topic的消息含有丰富的数据。对于像Etcd这样的系统，Key（类似于主题）存储了真实的数据而消息（数据变化通知）不含独特的丰富消息。换句话说，对于消息队列来说，topic很简单，而像Etcd则正好相反。（译者认为此处概括的非常准确）2. Policy Layer: API ServerKubernetes的核心组件是API Server，它是Kubernetes系统和Etcd直接对话的唯一组件。实际上，etcd是API server的实现细节，理论上也可以用其他分布式存储系统来支持Kubernetes.API server是一个策略组件，提供对Etcd的过滤访问。它的作用本质上是相对通用的，目前正在被分解处理。因此，API Server也可以用于其他系统的控制平面。API server的主要货物是资源，通过暴露简单的REST API 向外提供服务。这些资源有一个标准结构可以实现一些扩展功能。无论如何，API Server，允许各类组件创建，读取，写入，更新，和监视资源。API Server的具体的功能：认证和授权。Kubernetes有一个可插拔的认证系统。有一些内置的用户认证机制和授权这些用户访问资源。此外，还有一些方法可用于向外部服务提供这些服务。这种可扩展性是Kubernetes构建的核心功能。API Server运行一组可以拒绝或修改请求的准入控制器。 这些允许策略被应用并设置默认值。 这是确保在API Server客户端仍在等待请求确认时进入系统的数据有效性的关键。 虽然这些准入控制器目前正在编译到API Server中，但目前正在进行的工作是使其成为另一种可扩展性机制。API Server 有助…

HTTP Content-Type对照表
type: item
date: 2020-03-21T03:25:00+00:00
description: 文件扩展名Content-Type(Mime-Type).*（ 二进制流，不知道下载文件类型）application/octet-stream0.001application/x-0010.323text/h3230.907drawing/907.acpaudio/x-mei-aac.aifaudio/aiff.aiffaudio/aiff.asatext/asa.asptext/asp.auaudio/basic.awfapplication/vnd.adobe.workflow.bmpapplication/x-bmp.c4tapplication/x-c4t.calapplication/x-cals.cdfapplication/x-netcdf.celapplication/x-cel.cg4application/x-g4.citapplication/x-cit.cmltext/xml.cmxapplication/x-cmx.crlapplication/pkix-crl.csiapplication/x-csi.cutapplication/x-cut.dbmapplication/x-dbm.dcdtext/xml.derapplication/x-x509-ca-cert.dibapplication/x-dib.docapplication/msword.drwapplication/x-drw.dwfModel/vnd.dwf.dwgapplication/x-dwg.dxfapplication/x-dxf.emfapplication/x-emf.enttext/xml.epsapplication/x-ps.etdapplication/x-ebx.faximage/fax.fifapplication/fractals.frmapplication/x-frm.gbrapplication/x-gbr.gifimage/gif.gp4application/x-gp4.hmrapplication/x-hmr.hplapplication/x-hpl.hrfapplication/x-hrf.htctext/x-component.htmltext/html.htxtext/html.icoimage/x-icon.iffapplication/x-iff.igsapplication/x-igs.imgapplication/x-img.ispapplication/x-internet-signup.javajava/*.jpeimage/jpeg.jpegimage/jpeg.jpgapplication/x-jpg.jsptext/html.larapplication/x-laplayer-reg.lavsaudio/x-liquid-secure.lmsffaudio/x-la-lms.ltrapplication/x-ltr.m2vvideo/x-mpeg.m4evideo/mpeg4.manapplication/x-troff-man.mdbapplication/msaccess.mfpapplication/x-shockwave-flash.mhtmlmessage/rfc822.midaudio/mid.milapplication/x-mil.mndaudio/x-musicnet-download.mochaapplication/x-javascript.mp1audio/mp1.mp2vvideo/mpeg.mp4video/mpeg4.mpdapplication/vnd.ms-project.mpegvideo/mpg.mpgaaudio/rn-mpeg.mpsvideo/x-mpeg.mpvvideo/mpg.mpwapplication/vnd.ms-project.mtxtext/xml.netimage/pnetvue.nwsmessage/rfc822.outapplication/x-out.p12application/x-pkcs12.p7capplication/pkcs7-mime.p7rapplication/x-pkcs7-certreqresp.pc5application/x-pc5.pclapplication/x-pcl.pdfapplication/pdf.pdxapplication/vnd.adobe.pdx.pglapplication/x-pgl.pkoapplication/vnd.ms-pki.pko.plgtext/html.pltapplication/x-plt.pngapplication/x-png.…

RAID5 真的安全吗
type: item
date: 2020-03-02T14:01:00+00:00
description: 转载自知乎一句话结论：现代大容量硬盘组成的RAID 5单盘故障后，重建失败的概率相当高，不可忽略；但数据本身还是基本安全的（会丢失部分文件），只是可能需要一个比较麻烦的恢复方案。楼上包括高赞回答在内一堆说两个硬盘同时坏的，要加一个热备盘的，都是没仔细看过问题里面的链接就回答的。在回答问题的现在，这个链接失效了，但网上还是有人转载过的，例如这篇[1]：DBA亲，你们的RAID5阵列有保障吗？marbury关注0人评论10546人阅读2014-02-21 10:30:24 该文章主要整理论坛内容。（论坛地址：http://bbs.et8.net/bbs/showthread.php?t=1026112）很多人遇到过服务器RAID5挂掉，往往掉一个盘后，第二个盘也立刻挂掉。引用：RAID 5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样，任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为n-1。如果挂掉两个盘，数据就玩完了。 理论上两个硬盘同时失效的概率是很低的，但为什么会这样呢？ 引用：从数学角度说，每个磁盘的平均无故障时间 (MTBF) 大约为 50 万至 150 万小时(也就是每 50～150 年发生一次硬盘损坏)。实际往往不能达到这种理想的情况，在大多数散热和机械条件下，都会造成硬盘正常工作的时间大幅减少。考虑到每个磁盘的寿命不同，阵列中的任何磁盘都可能出现问题，从统计学角度说，阵列中 N 个磁盘发生故障的机率比单个磁盘发生故障的机率要大 N 倍。结合上述因素，如果阵列中的磁盘数量合理，且这些磁盘的平均无故障时间 (MTBF) 较短，那么在磁盘阵列的预期使用寿命过程中，就很有可能发生磁盘故障(比方说每几个月或每隔几年就会发生一次故障)。 两块磁盘同时损坏的几率有多大呢(“同时”就是指一块磁盘尚未完全修复时另一块磁盘也坏掉了)?如果说 RAID 5 阵列的MTBF相当于MTBF^2，那么这种几率为每隔10^15个小时发生一次(也就是1万多年才出现一次)，因此不管工作条件如何，发生这种情况的概率是极低的。从数学理论角度来说，是有这种概率，但在现实情况中我们并不用考虑这一问题。不过有时却是会发生两块磁盘同时损坏的情况，我们不能完全忽略这种可能性，实际两块磁盘同时损坏的原因与MTBF基本没有任何关系。 对这种情况来说，这里首先要引入一个一般人不常接触到的概念：BER 硬盘误码率,英文是BER(Bit Error Rate),是描述硬盘性能的一个非常重要的参数,是衡量硬盘出错可靠性的一个参数。这个参数代表你写入硬盘的数据，在读取时遇到不可修复的读错误的概率。从统计角度来说也比较少见，一般来说是指读取多少位后会出现一次读取错误。 随着硬盘容量增加，驱动器读取数据的误读率就会增加，而硬盘容量暴涨，误码率的比例一直保持相对增加。一个1TB的驱动器是需要更多读取整个驱动器，这是在RAID重建期间发生错误的概率会比300G 驱动器遇到错误的几率大。 那这个错误的几率到底有多大呢？或者说，我们写入多少GB数据，才会遇到1byte的读取错误呢？看这篇文章：http://lenciel.cn/docs/scsi-sata-reliability/对于不同类型的硬盘（以前企业级、服务器、数据中心级硬盘用SCSI/光纤，商用、民用级别是IDE；现在对应的则是SAS/SATA； 他们的MRBF（平均无故障时间）是接近的，但是BER便宜的SATA硬盘要比昂贵的SCSI硬盘的误码率（BER）要高得多。 也就是说，出现某个sector无法读取的情况，SATA要比SCSI严重得多。具体区别在固件上：遇到读取不过去，或者写入不过去的坏道时，家用硬盘会花费1分钟以上的时间去尝试纠正错误，纠正不了就直接用备用扇区代替，这个时间超过阵列控制器能容忍的限度，所以遇到这种情况直接掉盘；企业级的磁盘会把这项工作放在后台进行，不需要停顿1分钟左右的时间，从而不影响阵列运行。在BER 硬盘误码率上没有任何区别。 按照文中的计算，一个1TB的硬盘，通常你无法读取所有sector的概率达到了56%，因此你用便宜的大容量SATA盘，在出现硬盘故障的情况下重建RAID的希望是：无法实现。 用1TB的SATA硬盘做RAID5的话，当你遇到一个硬盘失效的情况，几乎剩下的两个以上硬盘（RAID5最少组合是3个）铁定会遇到一个硬盘读取错误，从而重建失败。 所以，以前小硬盘做RAID5，基本很少遇到同时挂掉两个盘的情况；现在硬盘大了，出问题的概率也越来越大了。 对于跑RAID的用户，对整个硬盘进行读取的事情经常发生。即使系统足够和谐，知道不对你报告那些出现在你从不读取的文件中的坏道，但是也只是略过了…

Cache 和 Buffer 有什么区别？
type: item
date: 2019-12-19T07:57:38+00:00
description: Cache和Buffer是两个不同的概念，简单的说，Cache是加速“读”，而buffer是缓冲“写”，前者解决读的问题，保存从磁盘上读出的数据，后者是解决写的问题，保存即将要写入到磁盘上的数据。在很多情况下，这两个名词并没有严格区分，常常把读写混合类型称为buffer cache，本文后续的论述中，统一称为cache。Oracle中的log buffer是解决redo写入的问题，而data buffer cache则解决data block的读写问题。对于Oracle来说，如果IO没有在SGA中命中，都会发生物理IO，Oracle并不关心底层存储的类型，可能是一套存储系统，可能是本地磁盘，可能是RAID 10，也可能是RAID 5，可能是文件系统，也可能是裸设备，或是ASM。总之，Oracle把底层的存储系统称为存储子系统。在存储系统中，cache几乎无处不在（在后面的论述中，我们统称为cache），文件系统有cache，存储有cache，RAID控制器上有cache，磁盘上也有cache。为了提高性能，Oracle的一个写操作，很有可能写在存储的cache上就返回了，如果这时存储系统发生问题，Oracle如何来保证数据一致性的问题。Oracle数据库最重要的特性是：Write ahead logging，在data block在写入前，必须保证首先写入redo log，在事务commit时，同时必须保证redo log被写入。Oracle为了保证数据的一致性，对于redo log采用了direct IO，Direct IO会跳过了OS上文件系统的cache这一层。但是，OS管不了存储这一层，虽然跳过了文件系统的cache，但是依然可能写在存储的cache上。一般的存储都有cache，为了提高性能，写操作在cache上完成就返回给OS了，我们称这种写操作为write back，为了保证掉电时cache中的内容不会丢失，存储都有电池保护，这些电池可以供存储在掉电后工作一定时间，保证cache中的数据被刷入磁盘，不会丢失。不同于UPS，电池能够支撑的时间很短，一般都在30分钟以内，只要保证cache中的数据被写入就可以了。存储可以关闭写cache，这时所有的写操作必须写入到磁盘才返回，我们称这种写操作为write throuogh，当存储发现某些部件不正常时，存储会自动关闭写cache，这时写性能会下降。RAID卡上也有cache，一般是256M，同样是通过电池来保护的，不同于存储的是，这个电池并不保证数据可以被写入到磁盘上，而是为cache供电以保护数据不丢失，一般可以支撑几天的时间。还有些RAID卡上有flash cache，掉电后可以将cache中的内容写入到flash cache中，保证数据不丢失。如果你的数据库没有存储，而是放在普通PC机的本地硬盘之上的，一定要确认主机中的RAID卡是否有电池，很多硬件提供商默认是不配置电池的。当然，RAID卡上的cache同样可以选择关闭。磁盘上的cache，一般是16M-64M，很多存储厂商都明确表示，存储中磁盘的cache是禁用的，这也是可以理解的，为了保证数据可靠性，而存储本身又提供了非常大的cache，相比较而言，磁盘上的cache就不再那么重要。SCSI指令中有一个FUA(Force Unit Access)的参数，设置这个参数时，写操作必须在磁盘上完成才可以返回，相当于禁用了磁盘的写cache。虽然没有查证到资料，但是我个人认为一旦磁盘被接入到RAID控制器中，写cache就会被禁用，这也是为了数据可靠性的考虑，我相信存储厂商应该会考虑这个问题。至此，我们可以看到Oracle的一个物理IO是经历了一系列的cache之后，最终被写入到磁盘上。cache虽然可以提高性能，但是也要考虑掉电保护的问题。关于数据的一致性，是由Oracle数据库，操作系统和存储子系统共同来保证的。

macOS升级到Catalina之后使用SecureCRT报错问题
type: item
date: 2019-10-17T09:02:00+00:00
description: macOS 升级到 Catalina之后，使用SecureCRT报如下错误The permissions on the "/cores" directory need to be changed toinclude write permission for "other".Please execute (or ask an admin to execute) the following from aterminal window:sudo chmod go+w /coresIf you would prefer not to change the permissions on the /coresfolder, you can turn off the Global option "Create core file whenapplication crashes".应该是macOS的权限控制严格了，导致CRT没有权限访问/cores文件夹，这里关掉CRT崩溃时创建core转储文件即可Option --> Global Options 取消 Create core file when application crashes 前面的复选框选择即可