防止服务器宕机时MySQL数据丢失的几种方案_MySQL

对于多数应用来说，MySQL都是作为最关键的数据存储中心的，所以，如何让MySQL提供HA服务，是我们不得不面对的一个问题。当master当机的时候，我们如何保证数据尽可能的不丢失，如何保证快速的获知master当机并进行相应的故障转移处理，都是需要我们好好思考的。这里，笔者将结合这段时间做的MySQL proxy以及toolsets相关工作，说说我们现阶段以及后续会在项目中采用的MySQL HA方案。

Replication

要保证MySQL数据不丢失，replication是一个很好的解决方案，而MySQL也提供了一套强大的replication机制。只是我们需要知道，为了性能考量，replication是采用的asynchronous模式，也就是写入的数据并不会同步更新到slave上面，如果这时候master当机，我们仍然可能会面临数据丢失的风险。

为了解决这个问题，我们可以使用semi-synchronous replication，semi-synchronous replication的原理很简单，当master处理完一个事务，它会等待至少一个支持semi-synchronous的slave确认收到了该事件并将其写入relay-log之后，才会返回。这样即使master当机，最少也有一个slave获取到了完整的数据。

但是，semi-synchronous并不是100%的保证数据不会丢失，如果master在完成事务并将其发送给slave的时候崩溃，仍然可能造成数据丢失。只是相比于传统的异步复制，semi-synchronous replication能极大地提升数据安全。更为重要的是，它并不慢，MHA的作者都说他们在facebook的生产环境中使用了semi-synchronous（这里），所以我觉得真心没必要担心它的性能问题，除非你的业务量级已经完全超越了facebook或者google。在这篇文章里面已经提到，MySQL 57之后已经使用了Loss-Less Semi-Synchronous replication，所以丢数据的概率已经很小了。

如果真的想完全保证数据不会丢失，现阶段一个比较好的办法就是使用gelera，一个MySQL集群解决方案，它通过同时写三份的策略来保证数据不会丢失。笔者没有任何使用gelera的经验，只是知道业界已经有公司将其用于生产环境中，性能应该也不是问题。但gelera对MySQL代码侵入性较强，可能对某些有代码洁癖的同学来说不合适了:-)

我们还可以使用drbd来实现MySQL数据复制，MySQL官方文档有一篇文档有详细介绍，但笔者并未采用这套方案，MHA的作者写了一些采用drdb的问题，在这里，仅供参考。

在后续的项目中，笔者会优先使用semi-synchronous replication的解决方案，如果数据真的非常重要，则会考虑使用gelera。

Monitor

前面我们说了使用replication机制来保证master当机之后尽可能的数据不丢失，但是我们不能等到master当了几分钟才知道出现问题了。所以一套好的监控工具是必不可少的。

当master当掉之后，monitor能快速的检测到并做后续处理，譬如邮件通知管理员，或者通知守护程序快速进行failover。

通常，对于一个服务的监控，我们采用keepalived或者heartbeat的方式，这样当master当机之后，我们能很方便的切换到备机上面。但他们仍然不能很即时的检测到服务不可用。笔者的公司现阶段使用的是keepalived的方式，但后续笔者更倾向于使用zookeeper来解决整个MySQL集群的monitor以及failover。

对于任何一个MySQL实例，我们都有一个对应的agent程序，agent跟该MySQL实例放到同一台机器上面，并且定时的对MySQL实例发送ping命令检测其可用性，同时该agent通过ephemeral的方式挂载到zookeeper上面。这样，我们可以就能知道MySQL是否当机，主要有以下几种情况：

机器当机，这样MySQL以及agent都会当掉，agent与zookeeper连接自然断开

MySQL当掉，agent发现ping不通，主动断开与zookeeper的连接

Agent当掉，但MySQL未当

上面三种情况，我们都可以认为MySQL机器出现了问题，并且zookeeper能够立即感知。agent与zookeeper断开了连接，zookeeper触发相应的children changed事件，监控到该事件的管控服务就可以做相应的处理。譬如如果是上面前两种情况，管控服务就能自动进行failover，但如果是第三种，则可能不做处理，等待机器上面crontab或者supersivord等相关服务自动重启agent。

使用zookeeper的好处在于它能很方便的对整个集群进行监控，并能即时的获取整个集群的变化信息并触发相应的事件通知感兴趣的服务，同时协调多个服务进行相关处理。而这些是keepalived或者heartbeat做不到或者做起来太麻烦的。

使用zookeeper的问题在于部署起来较为复杂，同时如果进行了failover，如何让应用程序获取到最新的数据库地址也是一个比较麻烦的问题。

对于部署问题，我们要保证一个MySQL搭配一个agent，幸好这年头有了docker，所以真心很简单。而对于第二个数据库地址更改的问题，其实并不是使用了zookeeper才会有的，我们可以通知应用动态更新配置信息，VIP，或者使用proxy来解决。

虽然zookeeper的好处很多，但如果你的业务不复杂，譬如只有一个master，一个slave，zookeeper可能并不是最好的选择，没准keepalived就够了。

Failover

通过monitor，我们可以很方便的进行MySQL监控，同时在MySQL当机之后通知相应的服务做failover处理，假设现在有这样的一个MySQL集群，a为master，b，c为其slave，当a当掉之后，我们需要做failover，那么我们选择b，c中的哪一个作为新的master呢？

原则很简单，哪一个slave拥有最近最多的原master数据，就选哪一个作为新的master。我们可以通过show slave status这个命令来获知哪一个slave拥有最新的数据。我们只需要比较两个关键字段Master_Log_File以及Read_Master_Log_Pos，这两个值代表了slave读取到master哪一个binlog文件的哪一个位置，binlog的索引值越大，同时pos越大，则那一个slave就是能被提升为master。这里我们不讨论多个slave可能会被提升为master的情况。

在前面的例子中，假设b被提升为master了，我们需要将c重新指向新的master b来开始复制。我们通过CHANGE MASTER TO来重新设置c的master，但是我们怎么知道要从b的binlog的哪一个文件，哪一个position开始复制呢？

GTID

为了解决这一个问题，MySQL 56之后引入了GTID的概念，即uuid:gid，uuid为MySQL server的uuid，是全局唯一的，而gid则是一个递增的事务id，通过这两个东西，我们就能唯一标示一个记录到binlog中的事务。使用GTID，我们就能非常方便的进行failover的处理。

仍然是前面的例子，假设b此时读取到的a最后一个GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:23，而c的为3E11FA47-71CA-11E1-9E33-C80AA9429562:15，当c指向新的master b的时候，我们通过GTID就可以知道，只要在b中的binlog中找到GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:15这个event，那么c就可以从它的下一个event的位置开始复制了。虽然查找binlog的方式仍然是顺序查找，稍显低效暴力，但比起我们自己去猜测哪一个filename和position，要方便太多了。

google很早也有了一个Global Transaction ID的补丁，不过只是使用的一个递增的整形，LedisDB就借鉴了它的思路来实现failover，只不过google貌似现在也开始逐步迁移到MariaDB上面去了。

MariaDB的GTID实现跟MySQL 56是不一样的，这点其实比较麻烦，对于我的MySQL工具集go-mysql来说，意味着要写两套不同的代码来处理GTID的情况了。后续是否支持MariaDB再看情况吧。

Pseudo GTID

GTID虽然是一个好东西，但是仅限于MySQL 56+，当前仍然有大部分的业务使用的是56之前的版本，笔者的公司就是55的，而这些数据库至少长时间也不会升级到56的。所以我们仍然需要一套好的机制来选择master binlog的filename以及position。

最初，笔者打算研究MHA的实现，它采用的是首先复制relay log来补足缺失的event的方式，但笔者不怎么信任relay log，同时加之MHA采用的是perl，一个让我完全看不懂的语言，所以放弃了继续研究。

幸运的是，笔者遇到了orchestrator这个项目，这真的是一个非常神奇的项目，它采用了一种Pseudo GTID的方式，核心代码就是这个

代码如下:

create database if not exists meta;

drop event if exists metacreate_pseudo_gtid_view_event;

delimiter ;;

create event if not exists

metacreate_pseudo_gtid_view_event

on schedule every 10 second starts current_timestamp

on completion preserve

enable

do

begin

set @pseudo_gtid := uuid();

set @_create_statement := concat('create or replace view metapseudo_gtid_view as select \'', @pseudo_gtid, '\' as pseudo_gtid_unique_val from dual');

PREPARE st FROM @_create_statement;

EXECUTE st;

DEALLOCATE PREPARE st;

end

;;

delimiter ;

set global event_scheduler := 1;

它在MySQL上面创建了一个事件，每隔10s，就将一个uuid写入到一个view里面，而这个是会记录到binlog中的，虽然我们仍然不能像GTID那样直接定位到一个event，但也能定位到一个10s的区间了，这样我们就能在很小的一个区间里面对比两个MySQL的binlog了。

继续上面的例子，假设c最后一次出现uuid的位置为s1，我们在b里面找到该uuid，位置为s2，然后依次对比后续的event，如果不一致，则可能出现了问题，停止复制。当遍历到c最后一个binlog event之后，我们就能得到此时b下一个event对应的filename以及position了，然后让c指向这个位置开始复制。

使用Pseudo GTID需要slave打开log-slave-update的选项，考虑到GTID也必须打开该选项，所以个人感觉完全可以接受。

后续，笔者自己实现的failover工具，将会采用这种Pseudo GTID的方式实现。

在《MySQL High Availability》这本书中，作者使用了另一种GTID的做法，每次commit的时候，需要在一个表里面记录gtid，然后就通过这个gtid来找到对应的位置信息，只是这种方式需要业务MySQL客户端的支持，笔者不很喜欢，就不采用了。

后记

MySQL HA一直是一个水比较深的领域，笔者仅仅列出了一些最近研究的东西，有些相关工具会尽量在go-mysql中实现。

更新

经过一段时间的思考与研究，笔者又有了很多心得与收获，设计的MySQL HA跟先前有了很多不一样的地方。后来发现，自己设计的这套HA方案，跟facebook这篇文章几乎一样，加之最近跟facebook的人聊天听到他们也正在大力实施，所以感觉自己方向是对了。

新的HA，我会完全拥抱GTID，比较这玩意的出现就是为了解决原先replication那一堆问题的，所以我不会考虑非GTID的低版本MySQL了。幸运的是，我们项目已经将MySQL全部升级到56，完全支持GTID了。

不同于fb那篇文章将mysqlbinlog改造支持semi-sync replication协议，我是将go-mysql的replication库支持semi-sync replication协议，这样就能实时的将MySQL的binlog同步到一台机器上面。这可能就是我和fb方案的唯一区别了。

只同步binlog速度铁定比原生slave要快，毕竟少了执行binlog里面event的过程了，而另外真正的slaves，我们仍然使用最原始的同步方式，不使用semi-sync replication。然后我们通过MHA监控整个集群以及进行故障转移处理。

以前我总认为MHA不好理解，但其实这是一个非常强大的工具，而且真正看perl，发现也还是看的懂得。MHA已经被很多公司用于生产环境，经受了检验，直接使用绝对比自己写一个要划算。所以后续我也不会考虑zookeeper，考虑自己写agent了。

分类: 电脑/网络 >> 操作系统/系统故障

解析:

无形的栅栏：完全解析Windows系统权限

一 权限的由来

远方的某个山脚下，有一片被森林包围的草原，草原边上居住着一群以牧羊为生的牧民。草原边缘的森林里，生存着各种动物，包括野狼。

由于羊群是牧民们的主要生活来源，它们的价值便显得特别珍贵，为了防止羊的跑失和野兽的袭击，每户牧民都用栅栏把自己的羊群圈了起来，只留下一道小门，以便每天傍晚供羊群外出到一定范围的草原上活动，实现了一定规模的保护和管理效果。

最初，野狼只知道在森林里逮兔子等野生动物生存，没有发现远处草原边上的羊群，因此，在一段时间里实现了彼此和平相处，直到有一天，一只为了追逐兔子而凑巧跑到了森林边缘的狼，用它那灵敏的鼻子嗅到了远处那隐隐约约的烤羊肉香味。

当晚，突然出现的狼群袭击了草原上大部分牧民饲养的羊，它们完全无视牧民们修筑的仅仅能拦住羊群的矮小栅栏，轻轻一跃便突破了这道防线……虽然闻讯而来的牧民们合作击退了狼群，但是羊群已经遭到了一定的损失。

事后，牧民们明白了栅栏不是仅仅用来防止羊群逃脱的城墙，各户牧民都在忙着加高加固了栅栏……

如今使用Windows 2000/XP等操作系统的用户，或多或少都会听说过“权限”(Privilege)这个概念，但是真正理解它的家庭用户，也许并不会太多，那么，什么是“权限”呢对于一般的用户而言，我们可以把它理解为系统对用户能够执行的功能操作所设立的额外限制，用于进一步约束计算机用户能操作的系统功能和内容访问范围，或者说，权限是指某个特定的用户具有特定的系统资源使用权力。

掌握了“Ring级别”概念的读者也许会问，在如今盛行的80386保护模式中，处理器不是已经为指令执行做了一个“运行级别”的限制了吗而且我们也知道，面对用户操作的Ring 3级别相对于系统内核运行的Ring 0级别来说，能直接处理的事务已经被大幅度缩减了，为什么还要对运行在“权限少得可怜”的Ring 3层次上的操作系统人机交互界面上另外建立起一套用于进一步限制用户操作的“权限”概念呢这是因为，前者针对的是机器能执行的指令代码权限，而后者要针对的对象，是坐在计算机面前的用户。

对计算机来说，系统执行的代码可能会对它造成危害，因此处理器产生了Ring的概念，把“ 在外”的一部分用于人机交互的操作界面限制起来，避免它一时头脑发热发出有害指令;而对于操作界面部分而言，用户的每一步操作仍然有可能伤害到它自己和底层系统——尽管它自身已经被禁止执行许多有害代码，但是一些不能禁止的功能却依然在对这层安全体系作出威胁，例如格式化操作、删除修改文件等，这些操作在计算机看来，只是“不严重”的磁盘文件处理功能，然而它忽略了一点，操作系统自身就是驻留在磁盘介质上的文件!因此，为了保护自己，操作系统需要在Ring 3笼子限制的操作界面基础上，再产生一个专门用来限制用户的栅栏，这就是现在我们要讨论的权限，它是为限制用户而存在的，而且限制对每个用户并不是一样的，在这个思想的引导下，有些用户能操作的范围相对大些，有些只能操作属于自己的文件，有些甚至什么也不能做……

正因为如此，计算机用户才有了分类:管理员、普通用户、受限用户、来宾等……

还记得古老的Windows 9x和MS-DOS吗它们仅仅拥有基本的Ring权限保护(实模式的DOS甚至连Ring分级都没有)，在这个系统架构里，所有用户的权力都是一样的，任何人都是管理员，系统没有为环境安全提供一点保障——它连实际有用的登录界面都没有提供，仅仅有个随便按ESC都能正常进入系统并进行任何操作的“伪登录”限制而已。对这样的系统而言，不熟悉电脑的用户经常一不小心就把系统毁掉了，而且病毒木马自然也不会放过如此“松软”的一块蛋糕，在如今这个提倡信息安全的时代里，Windows 9x成了名副其实的鸡肋系统，最终淡出人们的视线，取而代之的是由Windows NT家族发展而来的Windows 2000和Windows XP，此外还有近年来致力向桌面用户发展的Linux系统等，它们才是能够满足这个安全危机时代里个人隐私和数据安全等要求的系统。

Win2000/XP系统是微软Windows NT技术的产物，是基于服务器安全环境思想来构建的纯32位系统。NT技术没有辜负微软的开发，它稳定，安全，提供了比较完善的多用户环境，最重要的是，它实现了系统权限的指派，从而杜绝了由Win9x时代带来的不安全操作习惯可能引发的大部分严重后果。

二 权限的指派

1普通权限

虽然Win2000/XP等系统提供了“权限”的功能，但是这样就又带来一个新问题:权限如何分配才是合理的如果所有人拥有的权限都一样，那么就等于所有人都没有权限的限制，那和使用Win9x有什么区别幸好，系统默认就为我们设置好了“权限组”(Group)，只需把用户加进相应的组即可拥有由这个组赋予的操作权限，这种做法就称为权限的指派。

默认情况下，系统为用户分了6个组，并给每个组赋予不同的操作权限，依次为:管理员组(Administrators)、高权限用户组(Power Users)、普通用户组(Users)、备份操作组(Backup Operators)、文件复制组(Replicator)、来宾用户组(Guests)，其中备份操作组和文件复制组为维护系统而设置，平时不会被使用。

系统默认的分组是依照一定的管理凭据指派权限的，而不是胡乱产生，管理员组拥有大部分的计算机操作权限(并不是全部)，能够随意修改删除所有文件和修改系统设置。再往下就是高权限用户组，这一部分用户也能做大部分事情，但是不能修改系统设置，不能运行一些涉及系统管理的程序。普通用户组则被系统拴在了自己的地盘里，不能处理其他用户的文件和运行涉及管理的程序等。来宾用户组的文件操作权限和普通用户组一样，但是无法执行更多的程序。

这是系统给各个组指派的权限说明，细心的用户也许会发现，为什么里面描述的“不能处理其他用户的文件”这一条规则并不成立呢，我可以访问所有文件啊，只是不能对系统设置作出修改而已，难道是权限设定自身存在问题实际上，NT技术的一部分功能必须依赖于特有的“NTFS”(NT文件系统)分区才能实现，文件操作的权限指派就是最敏感的一部分，而大部分家庭用户的分区为FAT32格式，它并不支持NT技术的安全功能，因此在这样的文件系统分区上，连来宾用户都能随意浏览修改系统管理员建立的文件(限制写入操作的共享访问除外)，但这并不代表系统权限不起作用，我们只要把分区改为NTFS即可。

2特殊权限

除了上面提到的6个默认权限分组，系统还存在一些特殊权限成员，这些成员是为了特殊用途而设置，分别是:SYSTEM(系统)、Everyone(所有人)、CREATOR OWNER(创建者)等，这些特殊成员不被任何内置用户组吸纳，属于完全独立出来的账户。(图特殊权限成员)

前面我提到管理员分组的权限时并没有用“全部”来形容，秘密就在此，不要相信系统描述的“有不受限制的完全访问权”，它不会傻到把自己完全交给人类，管理员分组同样受到一定的限制，只是没那么明显罢了，真正拥有“完全访问权”的只有一个成员:SYSTEM。这个成员是系统产生的，真正拥有整台计算机管理权限的账户，一般的操作是无法获取与它等价的权限的。

“所有人”权限与普通用户组权限差不多，它的存在是为了让用户能访问被标记为“公有”的文件，这也是一些程序正常运行需要的访问权限——任何人都能正常访问被赋予“Everyone”权限的文件，包括来宾组成员。

被标记为“创建者”权限的文件只有建立文件的那个用户才能访问，做到了一定程度的隐私保护。

但是，所有的文件访问权限均可以被管理员组用户和SYSTEM成员忽略，除非用户使用了NTFS加密。

无论是普通权限还是特殊权限，它们都可以“叠加”使用，“叠加”就是指多个权限共同使用，例如一个账户原本属于Users组，而后我们把他加入Administrators组，那么现在这个账户便同时拥有两个权限身份，而不是用管理员权限去覆盖原来身份。权限叠加并不是没有意义的，在一些需要特定身份访问的场合，用户只有为自己设置了指定的身份才能访问，这个时候“叠加”的使用就能减轻一部分劳动量了。

3NTFS与权限

在前面我提到了NTFS文件系统，自己安装过Win2000/XP的用户应该会注意到安装过程中出现的“转换分区格式为NTFS”的选择，那么什么是NTFS

NTFS是一个特别为网络和磁盘配额、文件加密等管理安全特性设计的磁盘格式，只有使用NT技术的系统对它直接提供支持，也就是说，如果系统崩溃了，用户将无法使用外面流行的普通光盘启动工具修复系统，因此，是使用传统的FAT32还是NTFS，一直是个倍受争议的话题，但如果用户要使用完全的系统权限功能，或者要安装作为服务器使用，建议最好还是使用NTFS分区格式。

与FAT32分区相比，NTFS分区多了一个“安全”特性，在里面，用户可以进一步设置相关的文件访问权限，而且前面提到的相关用户组指派的文件权限也只有在NTFS格式分区上才能体现出来。例如，来宾组的用户再也不能随便访问到NTFS格式分区的任意一个文件了，这样可以减少系统遭受一般由网站服务器带来的入侵损失，因为IIS账户对系统的访问权限仅仅是来宾级别而已，如果入侵者不能提升权限，那么他这次的入侵可以算是白忙了。

使用NTFS分区的时候，用户才会察觉到系统给管理员组用户设定的限制:一些文件即使是管理员也无法访问，因为它是SYSTEM成员建立的，并且设定了权限。

但是NTFS系统会带来一个众所周知的安全隐患:NTFS支持一种被称为“交换数据流”(AlternateDataStream，ADs)的存储特性，原意是为了和Macintosh的HFS文件系统兼容而设计的，使用这种技术可以在一个文件资源里写入相关数据(并不是写入文件中)，而且写进去的数据可以使用很简单的方法把它提取出来作为一个独立文件读取，甚至执行，这就给入侵者提供了一个可乘之机，例如在一个正常程序里插入包含恶意代码的数据流，在程序运行时把恶意代码提取出来执行，就完成了一次破坏行动。

不过值得庆幸的是，数据流仅仅能存在于NTFS格式分区内，一旦存储介质改变为FAT32、CDFS等格式，数据流内容便会消失了，破坏代码也就不复存在。

4权限设置带来的安全访问和故障

很多时候，管理员不得不为远程网络访问带来的危险因素而担忧，普通用户也经常因为新漏洞攻击或者IE浏览器安全漏洞下载的网页木马而疲于奔命，实际上合理使用NTFS格式分区和权限设置的组合，足以让我们抵御大部分病毒和黑客的入侵。

首先，我们要尽量避免平时使用管理员账户登录系统，这样会让一些由IE带来的病毒木马因为得不到相关权限而感染失败，但是国内许多计算机用户并没有意识到这一点，或者说没有接触到相关概念，因而大部分系统都是以管理员账户运行的，这就给病毒传播提供了一个很好的环境。如果用户因为某些工作需要，必须以管理员身份操作系统，那么请降低IE的运行权限，有试验证明，IE运行的用户权限每降低一个级别，受漏洞感染的几率就相应下降一个级别，因为一些病毒在例如像Users组这样的权限级别里是无法对系统环境做出修改的。降低IE运行权限的方法很多，最简单的就是使用微软自家产品“Drop MyRights”对程序的运行权限做出调整。(图用RunAs功能降低IE运行级别)

对管理员来说，设置服务器的访问权限才是他们关心的重点，这时候就必须搭配NTFS分区来设置IIS了，因为只有NTFS才具备文件访问权限的特性。然后就是安装IIS，经过这一步系统会建立两个用于IIS进程的来宾组账户“IUSR_机器名”和“IWAM_机器名”，但这样还不够，别忘记系统的特殊成员“Everyone”，这个成员的存在虽然是为了方便用户访问的，但是对于网络服务器最重要的“最小权限”思路(网络服务程序运行的权限越小，安全系数越高)来说，它成了安全隐患，“Everyone”使得整个服务器的文件可以随便被访问，一旦被入侵，黑客就有了提升权限的机会，因此需要把惹祸的“Everyone”成员从敏感文件夹的访问权限去掉，要做到这一步，只需运行“caclsexe 目录名 /R "everyone" /E”即可。敏感文件夹包括整个系统盘、系统目录、用户主目录等。这是专为服务器安全设置的，不推荐一般用户依葫芦画瓢，因为这样设定过“最小权限”后，可能会对日常使用的一些程序造成影响。

虽然权限设定会给安全防范带来一定的好处，但是有时候，它也会闯祸的…… “文件共享”(Sharing)是被使用最多的网络远程文件访问功能，却也是最容易出问题的一部分，许多用户在使用一些优化工具后，发现文件共享功能突然就失效了，或者无论如何都无法成功共享文件，这也是很多网络管理员要面对的棘手问题，如果你也不巧遇到了，那么可以尝试检查以下几种原因:

(1)相应的服务被禁止。文件共享功能依赖于这4个服务:Computer Browser、TCP/IP NetBIOS Helper Service、Server、Workstation，如果它们的其中一个被禁止了，文件共享功能就会出现各种古怪问题如不能通过计算机名访问等，甚至完全不能访问。

(2)内置来宾账户组成员Guest未启用。文件共享功能需要使用Guest权限访问网络资源。

(3)内置来宾账户组成员Guest被禁止从网络访问。这问题常见于XP系统，因为它在组策略(gpeditmsc)->计算机配置->Windows设置->安全设置->本地策略->用户权利指派->拒绝从网络访问这台计算机里把Guest账户添加进去了，删除掉即可真正启用Guest远程访问权限。

(4)限制了匿名访问的权限。默认情况下，组策略(gpeditmsc)->计算机配置->Windows设置->安全设置->本地策略->安全选项->对匿名连结的额外限制的设置应该是“无。依赖于默认许可权限”或者“不允许枚举SAM账号和共享”，如果有工具自作聪明帮你把它设置为“没有显式匿名权限就无法访问”，那么我可以很负责的告诉你，你的共享全完蛋了。

(5)系统权限指派出现意外。默认情况下，系统会给共享目录指派一个“Everyone”账户访问授权，然而实际上它还是要使用Guest成员完成访问的工作，但是有时候，Everyone却忘记Guest的存在了，这是或我们就需要自己给共享目录手动添加一个Guest账户，才能完成远程访问。(图手动添加一个账户权限)

(6)NTFS权限限制。一些刚接触NTFS的用户或者新手管理员经常会出这个差错，在排除以上所有问题的前提下依然无法实现文件共享，哪里都碰过了就是偏偏不知道来看看这个目录的“安全”选项卡，并在里面设置好Everyone的相应权限和添加一个Guest权限进去，如果它们会说话，也许早就在音箱里叫唤了:嘿，快看这里!哟嗬!

(7)系统自身设置问题。如果检查了以上所有方法都无效，那么可以考虑重装一个系统了，不要笑，一些用户的确碰到过这种问题，重装后什么也没动，却一切都好了。这大概是因为某些系统文件被新安装的工具替换掉后缺失了文件共享的功能。

由权限带来的好处是显而易见的，但是我们有时候也不得不面对它给我们带来的麻烦，没办法，谁叫事物都是有两面性的呢，毕竟正是因为有了这一圈栅栏，用户安全才有了保障。

三 突破系统权限

距离上一次狼群的袭击已经过了一个多月，羊们渐渐都忘记了恐惧，一天晚上，一只羊看准了某处因为下雨被泡得有点松软低陷的栅栏，跳了出去。可惜这只羊刚跳出去不久就遭遇了饿狼，不仅尸骨无存，还给狼群带来了一个信息:栅栏存在弱点，可以突破!

几天后的一个深夜，狼群专找地面泥泞处的栅栏下手，把栅栏挖松了钻进去，再次洗劫了羊群。

虽然权限为我们做了不同范围的束缚，但是这些束缚并不是各自独立的，它们全都依靠于同样的指令完成工作，这就给入侵者提供了“提升权限”(Adjust Token Privilege)的基础。

所谓“提升权限”，就是指入侵者使用各种系统漏洞和手段，让自己像那只羊或者狼群那样，找到“栅栏”的薄弱环节，突破系统指派的权限级别，从而把自己当前的权限提高多个级别甚至管理员级别的方法，提升权限得以成功的前提是管理员设置的失误(例如没有按照“最小权限”思路来配置服务器)或者业界出现了新的溢出漏洞等(例如LSASS溢出，直接拿到SYSTEM权限)。

通常，如果IIS或SQL两者之一出现了漏洞或设置失误，入侵者会尝试直接调用SQL注入语句调用特殊的系统存储过程达到直接执行命令的愿望，如果这一步成功，那么这台服务器就沦陷了;但如果管理员还有点本事，删除了存储过程或者补好了SQL注入点呢入侵者会想办法得到IIS的浏览权限，例如一个WebShell之类的，然后搜寻整台服务器的薄弱环节(前提:管理员没删除Everyone账户权限)，例如Serv-U、IIS特殊目录、各种外部CGI程序、FSO特殊对象等，这场猫和耗子的游戏永远也不会结束，如果管理员功底不够扎实，那么只能看着入侵者破坏自己的劳动成果甚至饭碗了。

四 结语

狼群的进攻再次被牧民们击退了，吸取了这次教训，牧民们在加固栅栏时都会把栅栏的根部打在坚硬的泥地上，并且嵌得很深。

饿狼们，还会再来吗

权限是计算机安全技术的一个进步，但是它也是由人创造出来的，不可避免会存在不足和遗漏，我们在享受权限带来的便利时，也不能忽视了它可能引起的安全隐患或者设置失误导致的众多问题。要如何才算合理使用权限，大概，这只能是个仁者见仁，智者见智的问题了。

今天，你又在用管理员账户心安理得地到处逛了吗

因为又网卡的那台机器你没设置成DHCP或者DNS服务器，幸好你也没配，要不就得不偿失了，装了以上两种之一的话，你的计算机就会慢好多，不过有一种办法可轻易解决，就是把连笔记本的那块网卡手动设置一下IP，同时笔记本的网卡也手动设置一下IP，一般应在同一网段但IP绝不能相同如：

19216801与19216802

另：其实你已经解决了一大半了，能上网就没必要再去刨根问底了，网络太复杂了