企业官网建设流程全解析

网站更多分享怎么做,百度问问我要提问,网站里+动效是用什么做的,网址导航百度1.操作系统故障定位手段查询状态时#xff0c;显示一个节点上所有实例都不正常时#xff0c;可能是操作系统发生了故障。 可以通过如下方法确定操作系统是否存在问题#xff1a;通过 SSH 或者其它远程登录工具登录该节点。如果连接失败#xff0c;请尝试通过 ping 发包检查…1.操作系统故障定位手段查询状态时显示一个节点上所有实例都不正常时可能是操作系统发生了故障。可以通过如下方法确定操作系统是否存在问题通过 SSH 或者其它远程登录工具登录该节点。如果连接失败请尝试通过 ping 发包检查网络状态。如果 ping 操作没有回复则表明这台机器可能存在网络连接故障、处于宕机状态或者正处于重启状态。如果操作系统内核发生 panic 引起系统崩溃系统重新启动时间较慢需经过较长时间大约 20 分钟才能重启。建议每 5 分钟尝试连接一次20 分钟后不能连接成功则表明这台机器已宕机或网络连接有问题需要管理员到现场进行检查处理。如果网络可以 ping 通但在 SSH 登入时卡住或登入后不能执行任何命令通常是由系资源不足如 CPU 或 IO 资源过载引起的机器不响应外部连接。建议重试几次。如果 5 分钟内仍不能成功需要管理员到现场进行检查处理。可以远程登录节点但在执行操作时响应缓慢需要检查系统运行情况后进行进一步处理。例如收集系统信息、确定系统版本、硬件、参数设置及登录用户情况。下面列出一些常用命令供参考。“who”命令查看当前在线用户。# who # cat /etc/openEuler-release # uname -a​“sysctl -a”命令需要 root 用户执行和“cat /etc/sysctl.conf”命令获得系统参数信息。“cat /proc/cpuinfo”和“cat /proc/meminfo”获得 CPU 和内存信息。# cat /proc/cpuinfo # cat /proc/meminfo​“top -H”命令查看 CPU 的使用情况确定是否因为某个进程导致 CPU 使用率过高。如果存在这种情况通过 gdb 或 gstack 打印该程序堆栈观察是否该程序处于死循环逻辑。“iostat -x 1 3”命令查看 IO 的使用情况确定是否当前磁盘的 IO 处于饱和状态。查看当前运行的执行作业情况决定是否对占用较多 IO 的执行作业进行处理。“vmstat 1 3”命令查看当前系统中内存的消耗情况结合“top”命令获得消耗内存较多的进程处于超出预期的状态。以 root 用户查看操作系统日志信息/var/log/messages或 dmseg 信息检查操作系统是否发生过异常错误。操作系统的 watchdog 是为了保证 OS 系统正常运行或者从死循环死锁等状态退出的一种机制如果 watchdog 超时一般默认值为 60s系统将会复位。2.网络故障定位手段在数据库正常工作的情况下网络层对上层用户是透明的但数据库在长期运行时可能会由于各种原因导致出现网络异常或错误。常见的因网络故障引发的异常有数据库启动失败报网络错误。状态异常如节点上所有的实例都是 UnKnown 或者所有主机都切换为备机。网络连接建立失败。对数据库执行 SQL 操作时报网络异常中断的错误。连接数据库或执行查询时发生进程停止响应。数据库出现了网络故障后主要通过使用 Linux 系统提供的网络相关命令工具ping、ifconfig、netstat、lsof 等进程堆栈查看工具gdb、gstack结合数据库的日志信息进行分析定位。本节通过举例介绍常见的网络问题并进行基本的分析定位。常见故障问题如下启动失败报网络错误问题现象 1日志中存在如下错误信息。可能是端口被其他进程侦听。LOG: could not bind socket at the 10 time, is another postmaster already running on port 15400?​处理办法执行如下命令查看侦听该端口的进程。端口号请根据实际端口号替换。# netstat -anop | grep 15400​根据查询结果强行停止正在占用端口的进程或者更改数据库侦听端口。问题现象 2使用 gs_om -t status –detail 查询状态如果显示主备间连接未建立。处理办法在 openEuler 操作系统下使用 systemctl status firewalld.service 命令查看节点上是否开启了防火墙。如果开启使用 systemctl stop firewalld.service 关闭防火墙。systemctl status firewalld.service ●firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1)​操作系统不同命令可能不同使用对应操作系统命令查看修改。数据库状态异常问题现象某一节点上出现如下问题所有实例都是 UnKnown。所有主实例都切换成了备实例。查询中出现大量 Connection reset by peerConnection timed out 等报错信息。处理办法如果 SSH 不能连接故障机器在其他机器上使用 Ping 命令向该机器发数据包。如果可以 Ping 通说明可能是该机器上的资源内存、CPU、磁盘耗尽导致不能建立连接。如果 SSH 可以连接该机器尝试执行查询并每隔 1s 执行/sbin/ifconfig eth??代表数字表示第几个网卡命令查看如下信息中的 dropped 及 errors 值的变化情况如果增长迅速可能是网卡或网卡驱动故障。# ifconfig enp125s0f0 enp125s0f0: flags4163 mtu 1500 inet 10.90.56.36 netmask 255.255.255.0 broadcast 10.90.56.255 inet6 fe80::7be7:8038:f3dc:f916 prefixlen 64 scopeid 0x20 ether 44:67:47:7d:e6:84 txqueuelen 1000 (Ethernet) RX packets 129344246 bytes 228050833914 (212.3 GiB) RX errors 0 dropped 647228 overruns 0 frame 0 TX packets 96689431 bytes 97279775245 (90.5 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0​检查如下参数设置是否正确。net.ipv4.tcp_retries1 3 net.ipv4.tcp_retries2 15 * 网络连接建立失败​问题现象 1节点连接其他节点失败日志中报出“ Connection refused ”错误。处理办法查看端口是否配置错误导致连接时使用的端口并非对方侦听的端口。查看报错节点配置文件 postgresql.conf 记录端口号与对方侦听的端口就号是否一致。查看对方端口侦听是否正常可以使用“netstat –anp”命令。查看对方进程是否存在。问题现象 2对数据库执行 SQL 操作时获取连接描述符失败报错如下。WARNING: 29483313: incomplete message from client:4905,9 WARNING: 29483313: failed to receive connDefs at the time:1. ERROR: 29483313: failed to get pooled connections​在日志中找到上面的错误并向上查看一段日志内容可以看到详细的错误信息常见的错误如下所示主要是由于主备信息不正确导致。FATAL: dn_6001_6002: can not accept connection in pending mode. FATAL: dn_6001_6002: the database system is starting up FATAL: dn_6009_6010: can not accept connection in standby mode.​处理办法使用 gs_om -t status –detail 查询状态确认是否发生过主备切换。重置实例状态。此外需要查看连接失败的节点是否发生了 core 或者重启。通过 om 日志可以查看到是否发生了重启。对数据库执行 SQL 操作时报网络异常中断的错误问题现象 1查询执行失败报错信息如下。ERROR: dn_6065_6066: Failed to read response from Datanodes. Detail: Connection reset by peer. Local: dn_6065_6066 Remote: dn_6023_6024 ERROR: Failed to read response from Datanodes Detail: Remote close socket unexpectedly ERROR: dn_6155_6156: dn_6151_6152: Failed to read vector response from Datanodes​连接建立失败报错信息如下。ERROR: Distribute Query unable to connect 10.145.120.79:14600 [Detail:stream connect connect() fail: Connection timed out ERROR: Distribute Query unable to connect 10.144.192.214:12600 [Detail:receive accept response fail: Connection timed out​处理办法使用 gs_check 检查网络配置是否符合标准。详细参考《工具参考手册》中“服务端工具 gs_check”章节中对 network 的检查。查看是否有进程发生 core 或重启以及主备切换。如果不存在上述问题可以联系网络技术人员做具体分析。3.磁盘故障定位手段常见的磁盘故障是磁盘空间不足、磁盘出现坏块、磁盘未挂载等。部分磁盘故障会导致文件系统损坏例如磁盘未挂载数据库管理自动定期执行磁盘检测时会识别故障并将实例停止查看数据库状态时对应实例状态异常部分磁盘故障不会导致文件系统损坏例如磁盘空间不足数据库管理无法检测到服务进程访问到故障磁盘会异常退出例如数据库无法启动、checksum 校验不对、页面读写失败、页面校验错误等。对于会导致文件系统损坏的故障查看状态会显示对应实例状态持续为 Unknown定位方法如下查看日志日志中会有类似 “data path disc writable test failed”异常说明文件系统已损坏。文件系统损坏可能是磁盘未挂载通过 ls –l 可以看到该磁盘对应的目录权限异常如下。也可能是磁盘出现坏块然后操作系统将文件系统保护起来拒绝读写可以使用磁盘坏块检查工具如 badblocks 检查磁盘是否有坏块如下。# badblocks /dev/sdb1 -s -v Checking blocks 0 to 2147482623 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors)​对于不会导致文件系统损坏的故障服务进程访问到故障磁盘会异常退出定位方法如下。查看日志。日志中会有文件读写错误例如“No space left on device”、“ invalid page header n block 122838 of relation base/16385/152715”。 文件读写错误可能是磁盘空间不足通过 df -h 可以看到磁盘空间已达 100%如下。# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 255G 0 255G 0% /dev tmpfs 255G 35M 255G 1% /dev/shm tmpfs 255G 57M 255G 1% /run tmpfs 255G 0 255G 0% /sys/fs/cgroup /dev/mapper/openeuler-root 196G 8.8G 178G 5% / tmpfs 255G 1.0M 255G 1% /tmp /dev/sda2 9.8G 144M 9.2G 2% /boot /dev/sda1 10G 5.8M 10G 1% /boot/efi /dev/mapper/openeuler-home 1.5T 69G 1.4T 5% /home tmpfs 51G 0 51G 0% /run/user/0 tmpfs 51G 0 51G 0% /run/user/1004 /dev/sdb1 2.0T 169G 1.9T 9% /data​4.数据库故障定位手段日志。数据库日志记录了数据库服务端启动、运行或停止时出现的问题当数据库在启动、运行或停止的过程中出现问题时数据库用户可以通过运行日志快速分析问题的产生原因并根据不同的原因采取相应的处理方法尽可能地解决问题。视图。数据库提供了许多视图用于展示数据库的内部状态在定位故障时经常使用的视图如下pg_stat_activity用于查询当前实例上各个 session 的状态。pg_thread_wait_status用于查询该实例上各个线程的等待事件。pg_locks用于查询当前实例上的锁状态。CORE 文件。数据库相关进程在运行过程中可能会因为各种意外情况导致数据库崩溃Coredump而崩溃时产生的 core 文件对于迅速定位程序崩溃的原因及位置非常重要。如果进程运行时出现 Coredump 现象建议立即收集 core 文件便于分析、定位故障。对性能有一定的影响尤其是进程频繁异常时对性能的影响更大。core 文件会占用磁盘空间。因此当检查到 core 文件产生后应及时解决以避免对操作系统带来更严重的影响。操作系统自带 core dump 机制。开启后系统中所有出现 Coredump 问题时都会生成 core 文件对操作系统带来性能和磁盘占用的影响。设置 core 文件生成路径。修改/proc/sys/kernel/core_pattern 内容。# cat /proc/sys/kernel/core_pattern /data/jenkins/workspace/GBase 8cInstall/dbinstall/cluster/corefile/core-%e-%p-%t