189 8069 5689
一、在使用PXC集群时经常出现由于异常宕机或者批量关闭后导致集群无法再次启动的问题
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、虚拟空间、营销软件、网站建设、浮山网站维护、网站推广。
这边主要的原因是：
批量关闭或者异常宕机容易出现mysql集群无法及时的记录主节点的信息到grastate.dat 文件中，
而正常启动时，我们需要判断grastate.dat这个文件里面的safe_to_bootstrap这个值是否为1而进行引导节点启动，其他节点以非引导节点启动
异常宕机或者批量关闭容易造成该文件来不及写入，导致三个节点的safe_to_bootstrap这个值都是0，导致无法通过safe_to_bootstrap这个值来判断哪个是引导节点，导致无法启动
此时就需要人工进行判断查找确认哪个作为引导节点启动了
二、先来说一下grastate.dat这个文件里面的内容
参数说明
三、说明一下启动脚本
启动脚本：bin/mysqld --defaults-file=../my.cnf
命令说明
四、为什么要区分引导节点和非引导节点方式启动
1、对于PXC首先要明白一点， 整个集群的数据是以引导节点为准的 ，数据是强一致的
所以说，选择好引导节点很重要，不然容易造成数据丢失的风险
非引导节点启动时，都会和引导节点的数据进行对比， 如果发现数据差异太大，则会采用SST(全量复制)的方式进行数据同步覆盖，此时该节点原有的数据将会丢失
2、 在PXC集群中，任何节点都可以以引导的方式进行启动，这种方式适用于，当集体宕机了，此时之前又存在脑裂的情况下（其三个节点的uuid数据不一致 ），
此时不能贸然启动所有节点，应该单独每个节点的启动，然后对每个节点进行备份数据，全部备份好之后，找出备份最大的那个节点为准（表示该机器数据最全，可以作为主节点），然后其他节点再以非引导的方式启动，加入到集群
如果此时确认数据丢失的话，可以从之前的备份中再恢复回来
如果三个节点的uuid都一样的话，则可根据seqno的值最大的进行以引导模式启动
注：如何查看seqno是多少？
第一种方式：查看grastate.dat这个文件
第二种方式：启动时增加--wsrep-recover参数
对于这个值：92d17807-8a46-11ec-bc31-2b23b2ce51ec:43424
其中：uuid = 92d17807-8a46-11ec-bc31-2b23b2ce51ec
seqno = 43424
可以手动将应用的数据库配置修改为从机的配置（ip、port、数据库名），然后重启服务。
1.检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。
2.对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。
在my.cnf中[mysqld]下加上以下配置，采用强制恢复机制，看是否能够启动
[mysqld]
innodb_force_recovery=1
如果设置成1不能启动，可以逐渐的将数据增大到6，下文会详细说下1-6是什么意思，如果在1-6之间启动成功了，那么你运气还不错，这时候不要恢复业务，赶紧把数据用逻辑方式导出来，再启个新的实例把数据还原，有人会问，为什么mysql已经启动了，还要导出数据呢，原因在这：
当innodb_force_recovery被设置为大于0的时候 ，会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务，类似于windows系统下的安全模式。以下这段引于其它地方，具体地址不太清楚了，也可以从官方文档中找到。
可以使用语句检查表。如果结果的msg_text部分是好的，那么你的表是健康的。反之，则表明mysql数据库中的表有损坏。另外有些厉害的高手一额可以通过运行脚本来检测。
MyISAM 表可以采用以下方法进行修复 ：使用 reapair table 或myisamchk 来修复。如果修复无效，采用备份恢复表。
阶段1 ：检查你的表
如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的' 。
你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段2 ：简单安全的修复
注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段3 ：困难的修复
只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。使用表描述文件创建新的( 空) 数据文件和索引文件：
shell mysql db_name
mysql SET AUTOCOMMIT=1;
mysql TRUNCATE TABLE tbl_name;
mysql quit
如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。将老的数据文件拷贝到新创建的数据文件之中。回到阶段2 。现在myisamchk -r -q 应该工作了。你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
阶段4 ：非常困难的修复
只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2并且尝试重建索引文件。
1，首先通过任务管理器进行进程排序，查找占用内存较大的程序进程。一般占用内存较大的进程有W3WP、sqlserver、mysqld-nt.exe；
2， 站点进程w3wp 可以在cmd命令行中通过 iisapp 命令来对应是那个网站占用内存较大。可以通过设置回收时间、内存最大使用值或共用进程池来减少内存的占用，但是如果要保证网站的访问质量，还是建议升级至更高型号来解决；
3，数据库 sql server 也可以通过数据库的企业管理器来设置最大内存占用，但是如果网站程序必须要占用较大内存的话，设置后会发生页面报错、打不开等问题；
4，MYSQL本身会占用较大虚拟内存，如果不使用mysql数据库的话，可以将其停止。
1、为了排除EMC和网络的问题，把数据文件迁移到本地，再做大量的插入操作后(约插入了600万)，发现很快就会出现同样的故障。这样，就排除了存储和网络的问题，说明故障点在于AIX和ORACLE的aio设置。此时DISK_ASYNCH_IO＝true。 2、修改oracle的DI...