MySQL查询过程是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行的过程。MySQL客户端/服务端通信协议是“半双工”的：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时发生，一旦一端开始发送消息，另一端要接收完整个消息才能响应它。
遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：
一、尽可能搞清楚问题的前因后果
不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。
必须搞清楚的问题有：
故障的表现是什么？无响应？报错？
故障是什么时候发现的？
故障是否可重现？
有没有出现的规律（比如每小时出现一次）
最后一次对整个平台进行更新的内容是什么（代码、服务器等）？
故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)?
基础架构（物理的、逻辑的）的文档是否能找到?
是否有监控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic…
什么都可以）
是否有日志可以查看?. （比如Loggly、Airbrake、 Graylog…）
最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。
二、有谁在?
代码如下:
$ w
$ last
用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in
the kitchen is enough.）
三、之前发生了什么?
$
history查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。
到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT
环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。
四、现在在运行的进程是啥?
代码如下:
$ pstree -a
$ ps aux
这都是查看现有进程的。 ps aux 的结果比较杂乱， pstree -a 的结果比较简单明了，可以看到正在运行的进程及相关用户。
五、监听的网络服务
代码如下:
$ netstat -ntlp
$ netstat -nulp
$
netstat -nxlp
我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我绝不会用 numeric 选项
（鄙人一点浅薄的看法：IP 地址看起来更方便）。
找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。
如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。
通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。
六、CPU 和内存
代码如下:
$ free -m
$ uptime
$ top
$
htop
注意以下问题:
还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?
还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了?
服务器最大的负载来自什么地方? 平均负载是多少?
七、硬件
代码如下:
$ lspci
$ dmidecode
$
ethtool
有很多服务器还是裸机状态，可以看一下：
找到RAID 卡 (是否带BBU备用电池?)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。
网卡是否设置好?
是否正运行在半双工状态? 速度是10MBps? 有没有 TX/RX 报错?
八、IO 性能
代码如下:
$ iostat -kx 2
$ vmstat 2 10
$ mpstat
2 10
$ dstat --top-io --top-bio
这些命令对于调试后端性能非常有用。
检查磁盘使用量：服务器硬盘是否已满?
是否开启了swap交换模式 (si/so)?
CPU被谁占用：系统进程? 用户进程? 虚拟机?
dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源? 还是你的PHP进程?
九、挂载点 和 文件系统
代码如下:
$ mount
$ cat /etc/fstab
$ vgs
$
pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box
*/
一共挂载了多少文件系统?
有没有某个服务专用的文件系统? (比如MySQL?)
文件系统的挂载选项是什么： noatime?
default? 有没有文件系统被重新挂载为只读模式了？
磁盘空间是否还有剩余?
是否有大文件被删除但没有清空?
如果磁盘空间有问题，你是否还有空间来扩展一个分区？
十、内核、中断和网络
代码如下:
$ sysctl -a | grep ...
$ cat
/proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy
servers */
$ netstat
$ ss -s
你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？
SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好,
不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。
conntrack_max 是否设的足够大，能应付你服务器的流量?
在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？
如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。
你还可以看一下 Linux TCP tuning
了解网络性能调优的一些要点。
十一、系统日志和内核消息
代码如下:
$ dmesg
$ less /var/log/messages
$
less /var/log/secure
$ less /var/log/auth
查看错误和警告消息，比如看看是不是很多关于连接数过多导致？
看看是否有硬件错误或文件系统错误?
分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。
十二、定时任务
代码如下:
$ ls /etc/cron* + cat
$ for user in
$(cat /etc/passwd | cut -f1 -d:)do crontab -l -u $userdone
是否有某个定时任务运行过于频繁?
是否有些用户提交了隐藏的定时任务?
在出现故障的时候，是否正好有某个备份任务在执行？
十三、应用系统日志
这里边可分析的东西就多了,
不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:
Apache &Nginx查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。
MySQL
在mysql.log找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题.
PHP-FPM如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)，如果没设定，赶紧设定。
Varnish在varnishlog 和 varnishstat 里, 检查 hit/miss比.
看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？
HA-Proxy
后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？
结论
经过这5分钟之后，你应该对如下情况比较清楚了：
在服务器上运行的都是些啥？
这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。
这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。
你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。继续努力吧！
微软公司的SQL Server 发布已经有一段时间了 先前作了简单的测试安装 感觉确实有不小的改进 在 *** 作上我还是有些不适应 毕竟我不是专门做数据库管理的 菜啊！
之所以会对SQL 感兴趣 主要是因为很多朋友都在用 而且未来我可能也会接触它 一直以来都想搞一次MDaemon的冗余方案测试 本来打算采用免费的MySQL可是发现目前的 x版本竟然无法正常运行在MSCS上 无奈等待了有数月之久直到微软的SQL 发布 哈哈！机器的内存也升级到 G 所以决定抱着勇于求知的精神开始筹备测试部署SQL 群集 年前最后一天班下午没有太多事情就搭建了一个DC+NodeA+NodeB的群集环境 安装SQL 还是比较顺利的 后来放入第二张盘安装便失败了 以为是因宿主性能造成（在 M内存的虚拟机中安装SQL 群集 真的是非常得慢 我可怜的硬盘） 决定年后上班搭建一个双节点群集环境来做测试 这样一来资源占用应该会小很多 毕竟撤掉一台单独的DC
昨天是年后的第一天班 处理完手上的工作 下午便开始搭建双节点群集环境 这样强烈使用VMware GSX来作为虚拟机软件 不像VSRV R 那样配置方便 但是相对来说整体的 *** 作还是优于VSRV R 的 另外就是运行速度 感觉确实要快很多 新版的GSX搭建MCSC还是比较简便的 不必像网上资料中写的需要什么pln工具 直接生成固定容量磁盘后 修改虚拟机的配置文件添加参数就可以了 关于配置参数的资料可以参考
本文主要总结SQL 的群集部署 所以关于VMware下MSCS环境的搭建步骤就不再重复 直接从主题开始
测试环境 宿主机 硬件配置 PIV G/ G DDR / G PATA pm/ C NIC *** 作系统 Microsoft Windows XP Pro With SP ENU 虚拟平台 VMware GSX
VirtualHost Microsoft Cluster NodeA 硬件配置 PIV G/ M/ G/vlance NIC/vmxnet NIC *** 作系统 Microsoft Windows Server EE With SP CHS 网卡信息 vlance NIC M 全速半双工/HeartBeat/IP vmxnet NIC M 全速全双工/Public/IP /GW /DNS /WINS 承载服务 DC+DNS+WINS+IIS
VirtualHost Microsoft Cluster NodeB 硬件配置 PIV G/ M/ G/vlance NIC/vmxnet NIC *** 作系统 Microsoft Windows Server EE With SP CHS 网卡信息 vlance NIC M 全速半双工/HeartBeat/IP vmxnet NIC M 全速全双工/Public/IP /GW /DNS /WINS 承载服务 DC+DNS+WINS+IIS
Virtual G Pln Qdisk M/Sdisk M 注意 本次测试将仲裁盘和资源盘放在了一起 实际中最佳的做法应当单独配置一个物理磁盘作仲裁使用 为提高安全性还应该为仲裁磁盘配置RAID
MSCS IP
目标实现 成功部署 SQL Server 群集/HostName SQL /IP
群集实施 我手上的SQL 为企业中文版 CD 首先放入第一张盘 点击 服务器组件 工具 联机丛书和示例 开始SQL 的群集安装 安装程序会自动检测当前是否为群集环境并为群集安装准备 小提示 MSCS默认环境下 群集组资源中缺少MSDTC组件 所以需要先添加MSDTC后再开始SQL 的群集安装 否则会出现警告并停止！
接受软件使用许可协议
SQL 在进行初始检测后开始执行安装 SQL 所需组件
完成所必需组件的安装
安装程序开始执行系统配置检查
进入SQL 的安装向导
向导开始执行系统配置检查 因为是安装群集 会自动检查各节点并给出状态提示 因为虚拟机配置的是 M内存 所以这里会 最低硬件要求 的警告 可以忽略！
选择要安装的组件 如要得到各组件的详细信息可以选择高级项
进入高级项后就来到了详细的各组件的功能选择 这里可以得到详细的组件信息 根据需要选择组件功能
实例名 配置中选择 默认实例
虚拟服务器名称配置中 为此群集命名为sql
为虚拟服务器配置IP 这里我使用Public作为公共访问 并分配一个IP 添加后点击 下一步
在 选择群集组 中选择可以得群集组 因为这里我只有一个默认的群集组 所以点击 下一步 继续
d出警告 提示我此群集组包含仲裁资源 这是因为我之前配置了一块Pln磁盘并分配两个逻辑分区来做群集 因此在这里会提示警告 可以直接忽略
群集节点配置中 选择可用的节点 因为我当前是双节点群集环境 所以安装向导自动为我选择了NodeA节点
配置远程安装的帐户 这里的帐户必须是各节点上有效的管理员帐户
为服务配置帐户 之前我已经添加了一个名为sql 的域用户作为SQL服务帐户 所以这里填写上正确的信息
配置群集服务的域组 这里其实我到现在还没有彻底搞明白是什么意思 参看帮助文件 便在域中为每个SQL服务创建对应的全局组 （希望达人能够帮我解答一下此处的意义！）
身份验证模式中 选择 混合模式 这和SQL 的感念是一样的
排序规则我是按照默认选择的
这里我没有选择微软提供的跟踪服务功能
前期的安装配置完成后就准备开始执行正式的文件安装 激动啊！
SQL 的群集安装进度还是很人性化的 这里你可以切换每个节点来监视安装进度
到这里就是一个漫长的等待了 真是心疼我的硬盘 不过结果很悲惨 在CD 安装完毕后 系统提示我插入CD 记得年前的测试也是在这里出现问题的 感觉会不会是因为磁盘写延迟 导致另外一个节点没有安装完 我就放入第二张CD造成的呢？抱着幻想我就一直等待 并且监视两台节点的日志 直到节点的硬盘和网卡没有强烈的提示后 我才放入CD 点击了确定 谁知道接下来就出现了之前测试相同的错误 安装终止并结束了 郁闷！这是怎么回事？检查系统发现SQL 的服务已经是启动了 这么说服务的安装时成功的 于是进入添加删除程序中 使用更改方式检查SQL 的安装 发现这里只有添加节点和卸载SQL 群集两个选择
重新执行光盘 发现CD 原来是 工具 联机丛书和示例 的安装盘
于是再次执行安装程序 哈哈 记起来了！之前也重新执行过安装不过放入的是CD 所以组件选中服务项等都是不安装 我以为红叉代表删除 所以就没敢继续 如果当时直接从CD 执行安装估计也就成功了
我个人认为 SQL 的管理工具等组件应该在群集安装后再单独为每个节点安装才是最佳的做法 至于为什么之前会失败只能靠其他达人来做试验来验证了！完成了管理工具等组件的安装 怀着兴奋的心情打开了全新的SQL 管理工具 默认启动后显示的是连接到服务器的配置页面 这里配置好登录后 可以在管理工具的选项中修改初始打开页面 在 已注册的服务器 窗体中打开SQL 服务器
哈哈 SQL 的群集算是安装完成了 真是令人兴奋！
进入 群集管理器 中检查SQL 群集的安装 发现没有问题 心理已经非常激动了！
最后来验证一下群集是否真的开始正常工作了 我将NodeB节点关闭后 在NodeA上打开 群集管理器 发现SQL 的群集资源已经自动并成功地从NodeB上转移到了NodeA 在NodeA上打开SQL 的管理工具进行服务器连接测试 成功！
至此 SQL 的群集算是圆满测试成功了 其间也是走了不少弯路 不过最后总算是成功了 心理也得到了安慰 其实SQL 的群集还是非常简单的 只不过CD 的安装出错到底是因为其本身不支持群集安装还是因为其他原因目前还不知晓 只能等权威的解释了！另外 SQL 的群集安装需要在拥有活动资源的节点上进行安装
总算是把文章写完了 今天狂停电 真郁闷！害死我了 最后算是一边写一边发布再编辑 真是费神 此实战总结为个人观点 其中有不足或错误之处还希望大家多多指正！
lishixinzhi/Article/program/SQLServer/201311/22067
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）