1．服务器管理
在这项管理工作中，主要是配置和管理服务器属性，安装和设置TCP／IP协议和远程访问服务协议，安装、配置和管理域控制器、文件服务器、DNS、WINS、DHCP、Web、FTP 服务器和各种远程访问服务器。
对服务器的关键点工作状态(如温度、电源、风扇和UPS的运行等)进行必要的监控，以确保服务器正常工作。如果网络中存在多个域控制器，则还需对各服务器的配置信息进行实时更新；更新Web服务器页面信息、向数据库服务器注入新的数据、管理邮件服务器的用户信箱等。
最后还有一点非常重要，就是要及时地更新服务器系统的版本或补丁程序，这不仅关系到服务器的性能发挥，而且还关系到整个网络系统的安全性，因为现在的 *** 作系统不断有新的安全漏洞被发现，及时安装补丁可以有效地阻止填补这些安全漏洞。
本书中针对服务器的管理主要介绍了服务器的远程管理，以及VPN远程访问服务器的配置与管理，具体参见本书第9章和第1 O章。其他方面可参见本系列中的另一本图书《网管员必读——网络管理》一书。
2．用户管理
网络管理员在保证网络安全可靠运行的前提条件下，根据单位人员的工作职权和人员变动情况，为每个用户设置账户、密码和分配不同的网络访问权限；设置Web服务器、VPN 等远程访问服务器中用户的访问权限等；限制Web服务器可登录的账号数量，及时注销过期用户和己挂断的拨号用户，关闭不用的网络服务等。既要保证各用户的正常工作不受影响，同时又要避免分配过高权限而给网络安全和管理带来不必要的安全隐患。
在本书中，针对用户管理方面在第2章、第5章、第6章做了较为详细的介绍。
3．文件和文件夹的管理
网络中的文件和文件夹管理是整个网络管理中最重要的部件之一，它不仅涉及到各用√ 的正常工作和网络应用，同时还关系到整个网络系统的安全性能。对于网络管理员来说，j 文件和文件夹管理中我们所做的工作主要有以下几个方面：
证每一台工作站的一致性。如果要在工作站上安装新软件，应该先做一个安装测试，并记录下每一个步骤。测试新的安装在典型的工作站上是否会出现问题。如果认为满意，就在每一个用户的计算机上都重复安装过程，保证一致性。如果在每一台工作站上都使用相同的硬件和 *** 作系统，一致性的安装应用程序非常简单。如果网络上用户过多，可以考虑使用某些特殊的工具来生成软件自动安装过程。如Windows系统的“无人值守安装"和“远程安装"功能就可大大减轻网络管理员软件安装的负担。
软件永远不可能完美，总会有这样或那样的问题，所以无论是 *** 作系统还是设备的驱动程序，都应该至少每个季度检查一次有无升级的提示，在服务器和工作站上都要进行这一工作。有时，补丁程序本身比要解决的问题更加可怕， *** 作系统的补丁导致的严重事故比比皆是。比如2003年1月25日爆发的Slammer病毒就是利用了SQL Server 2000早就发现的一个漏洞进行攻击的蠕虫病毒。早在2002年7月，微软就针对SQL Server 2000中l 434端口的漏洞，公布了安全补丁程序，对于微软服务器软件的用户来说，只要下载了补丁程序，就可以避免这次灾难。但遗憾的是，太多用户忽视了微软的建议。从上面的例子不难看出，安全意识的树立在某种意义上比安全技术本身更重要。
另外，在软件管理方面还应对服务器中专门存放源程序的文件夹的访问权限进行严格限制，通常只允许系统管理员有权限访问和使用，否则一些不自觉的用户会在他们的计算机上安装一些本来他们不需要的软件。
8．硬件资源的维护与管理
在企业网络中，网络管理员通常需要负担起管理服务器和全部共享网络资源的责任，包括打印机、处理器、内存、硬盘等。在这种条件下，网络管理员的责任是相当直接的。保持所有资源连接、运转正常。在对这些网络硬件资源的管理中，其中一项重要任务就是实施常规检查。虽然现在复杂的网络 *** 作系统可以承受一定程度的问题而不至于停工，但是网络管理员在这些非关键性的错误堆积起来并变得严重之前，需要周期性地检测服务器并纠正这些错误。计算机系统也带有诊断的工具，但是可能需要使用比它们更复杂的专业工具，比方说 Intel公司的LANDesk Management Suite或者Novell的ManageWise，可以进行更细致的测试，并有更好的联机帮助。网络就是网络管理员的阵地，网络管理员还应对网络内的各台微机或各个工作站进行定期巡检，了解每台计算机的状态，并定期保养。
在出现了硬件故障后，网络管理员还必须承担起故障排除和基本硬件维修的责任。这是最体现网络管理员的技术水平、冷静心态和逻辑思考能力的时候。随着经验的增长，解决问题的能力也会逐步提高。网络管理员要了解各处可能发生的问题：时刻不忘在笔记本电脑中记下调查结果和建议；利用书籍、期刊和自学培训等方式尽可能地积累常见问题的解决方法；当然还应该采取措施预防网络故障的发生。网络管理员应尽可能多地搜集信息，并记录在网络文档中。你会惊奇地发现以前的积累常常可以帮助查明某个事件的原因。
9．网络打印机的配置和管理
在企业中，打印机是必不可少的，特别是现在网络打印机得到广泛应用的今天。之所以要单独把它列出来，是因为它在企业网络中的位置已越来越重要，特别是在一些商务型企业中。如何有效地管理企业网络中的打印机和打印任务，也是网络管理员所必须面对的。这就要求网络管理员不仅要懂得如何安装、设置共享打印和网络打印服务器，而且还要熟悉一些网络打印机管理软件的使用，设置网络打印机的策略、共享属性和安全规则。
针对打印机的配置与管理，在本书的第11章有较详细的介绍。
1 O．网络布线的日常维护
网络故障在相当大程度上是来自布线系统，有经验的网络管理员都会知道，布线系统看似简单，其实其中蕴涵着丰富的经验与技巧。做好了，在出现故障时，就能及时快速地定位故障的发牛点；做不好，可能花费几天的工夫也不一定能找到其实很明显的故障原因。
在日常的网络管理工作中，我们需要根据员工的调动与工作需要在网络上增加新的服务器、工作站和联网设备，替换被损坏的线缆或排除网络线缆接头故障等，都需要对网络布线系统进行维护。
建立网络布线基准文件。在线缆系统安装后，网络管理员使用电缆测试仪对线缆进 行周期性检测，确保布线系统的质量。在评估认证后，将电缆测试仪存储的测试结 果复制到计算机上并打印出来，作为网络布线基准文件。
网络布线故障的测试与定位。将网络布线系统分割为若干个逻辑元素，每个逻辑元 素包含一段固定链路、分线盒和跳接电缆。使用电缆测试仪逐个测试逻辑元素，若 电缆测试仪显示开路的距离，可以确定开路或短路的位置；若发现接线映射故障， 多数是固定链路两端的误接；若是衰减存在，多数是劣质电缆。使用替代法验证可 疑元件即可。
11．网络升级
这是小王自己总结出来的，属于最新型的一种网管职责。
随着网络技术的不断发展和网络应用领域的不断拓展，无论哪个企业的网络随着时间的推移，都将面临升级或改造。如在无线WLAN技术还没有得到厂L泛应用的2003年前，企业网络基本上都是清一色的有线以太网，而从2003年3月Intel推出了集成无线网卡的迅驰处理器以后，WL．AN无线网络技术得到了迅速发展，新技术、新标准不断涌现，WLAN技术已从小范围实验走向了企业应用的前沿。现在就有许多企业在原有有线网络中部署了WLAN 无线网络，如会议室、大堂等公共场所。还有，虽然现在绝大多数中小企业网络都只是百兆位，但实际上千兆位以太网早在几年前就开始普及了，原来的百兆位主干、十兆位桌面变成了千兆位主干、百兆位桌面，甚至是万兆位主干、千兆位桌面。还有如网络电话、VPN网络应用等，这些都是以前所没有得到实质应用的，而现在却在许多企业中广泛应用。这些都属于网络升级或改造的范围，作为网络管理员，必须掌握最新的网络升级、改造技术，能根据企业自身需要提出各种可行的升级、改造方案。
在本书的第1 7章就专门针对企业网络以太网升级(百兆位到千兆位)、部署无线WLAN 网络会议室和加装VoIP网络应用进行了详细的介绍。
l 2．关键设备的管理
计算机网络的关键设备一般包括网络的主干交换机、中心路由器及主域控制器。对这些网络设备的管理，除了可以通过网管软件监视其工作状态外，更重要的是要做好它们的备份工作。现在许多厂商都推出了关键服务器备份解决方案，备份服务器能够保持与主服务器之间的 *** 作和运行同步，这样就保证了关键数据库的数据一致性和可靠性，以备将来主服务器出现故障时备份服务器及时替代主服务器的工作。这涉及到服务器的容错技术和远程数据存储技术，具体将在《网管员必读一一服务器与数据存储》一书中详细介绍。
路由器与广域网连接一般通过在其他广域网端口上配置V25bis接口来做高可靠性广域网连接的拨号备份，当主链路因故障断开时，备份链路就能够及时拨号建立，继续主链路上的数据传输。
对主干交换机的备份，目前似乎很少有厂商能提供比较系统的解决方案，因而只有靠网 络管理员在曰常管理中加强对主干交换机的性胃邑齐阳[作状态的监视，才能维护网络主干交换机的正常工作。
在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量 *** 作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！
用户反馈系统部分功能无法使用，紧急排查，定位是数据库表被锁，然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程，建议点赞收藏，以备不时之需。
用户反馈某功能页面报502错误，于是第一时间看服务是否正常，数据库是否正常。在控制台看到数据库CPU飙升，堆积大量未提交事务，部分事务已经阻塞了很长时间，基本定位是数据库层出现问题了。
查看阻塞事务列表，发现其中有锁表现象，本想利用控制台直接结束掉阻塞的事务，但控制台账号权限有限，于是通过客户端登录对应账号将锁表事务kill掉，才避免了情况恶化。
下面就聊聊，如果当突然面对类似的情况，我们该如何紧急响应？
想象一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序，某一天突然数据库的表被锁了，业务无法正常运转，那么我们该如何快速定位是哪个事务锁了表，如何结束对应的事物？
首先最简单粗暴的方式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于后果如何，你能不能跑了，要你自己三思而后行了！
重启是可以解决表被锁的问题的，但针对线上业务很显然不太具有可行性。
下面来看看不用跑路的解决方案：
遇到数据库阻塞问题，首先要查询一下表是否在使用。
如果查询结果为空，那么说明表没在使用，说明不是锁表的问题。
如果查询结果不为空，比如出现如下结果：
则说明表（test）正在被使用，此时需要进一步排查。
查看数据库当前的进程，看看是否有慢SQL或被阻塞的线程。
执行命令：
该命令只显示当前用户正在运行的线程，当然，如果是root用户是能看到所有的。
在上述实践中，阿里云控制台之所以能够查看到所有的线程，猜测应该使用的就是root用户，而笔者去kill的时候，无法kill掉，是因为登录的用户非root的数据库账号，无法 *** 作另外一个用户的线程。
如果情况紧急，此步骤可以跳过，主要用来查看核对：
如果情况紧急，此步骤可以跳过，主要用来查看核对：
看事务表INNODB_TRX中是否有正在锁定的事务线程，看看ID是否在show processlist的sleep线程中。如果在，说明这个sleep的线程事务一直没有commit或者rollback，而是卡住了，需要手动kill掉。
搜索的结果中，如果在事务表发现了很多任务，最好都kill掉。
执行kill命令：
对应的线程都执行完kill命令之后，后续事务便可正常处理。
针对紧急情况，通常也会直接 *** 作第一、第二、第六步。
这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则，而锁就是用来实现这些访问规则的重要数据结构。
根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL中表级别的锁有两种：一种是表锁，一种是元数据锁（metadata lock，MDL)。
表锁是在Server层实现的，ALTER TABLE之类的语句会使用表锁，忽略存储引擎的锁机制。表锁通过lock tables… read/write来实现，而对于InnoDB来说，一般会采用行级锁。毕竟锁住整张表影响范围太大了。
另外一个表级锁是MDL（metadata lock），用于并发情况下维护数据的一致性，保证读写的正确性，不需要显式的使用，在访问一张表时会被自动加上。
常见的一种锁表场景就是有事务 *** 作处于：Waiting for table metadata lock状态。
MySQL在进行alter table等DDL *** 作时，有时会出现Waiting for table metadata lock的等待场景。
一旦alter table TableA的 *** 作停滞在Waiting for table metadata lock状态，后续对该表的任何 *** 作（包括读）都无法进行，因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列。如果核心表出现了锁等待队列，就会造成灾难性的后果。
通过show processlist可以看到表上有正在进行的 *** 作（包括读），此时alter table语句无法获取到metadata 独占锁，会进行等待。
通过show processlist看不到表上有任何 *** 作，但实际上存在有未提交的事务，可以在information_schema.innodb_trx中查看到。在事务没有完成之前，表上的锁不会释放，alter table同样获取不到metadata的独占锁。
处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，让其回滚。
通过show processlist看不到表上有任何 *** 作，在information_schema.innodb_trx中也没有任何进行中的事务。很可能是因为在一个显式的事务中，对表进行了一个失败的 *** 作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效，没有释放。从performance_schema.events_statements_current表中可以查到失败的语句。
处理方法：通过performance_schema.events_statements_current找到其sid，kill 掉该session，也可以kill掉DDL所在的session。
总之，alter table的语句是很危险的（核心是未提交事务或者长事务导致的），在 *** 作之前要确认对要 *** 作的表没有任何进行中的 *** 作、没有未提交事务、也没有显式事务中的报错语句。
如果有alter table的维护任务，在无人监管的时候运行，最好通过lock_wait_timeout设置好超时时间，避免长时间的metedata锁等待。
关于MySQL的锁表其实还有很多其他场景，我们在实践的过程中尽量避免锁表情况的发生，当然这需要一定经验的支撑。但更重要的是，如果发现锁表我们要能够快速的响应，快速的解决问题，避免影响正常业务，避免情况进一步恶化。所以，本文中的解决思路大家一定要收藏或记忆一下，做到有备无患，避免突然状况下抓瞎。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）