背景：昨天突然接到客戶電話說系統登錄不上了，之前都好好很穩定，我想着不會有太大問題，由於是周日，我立即登錄看了日志是怎么回事，發現數據庫連接異常，如題異常；
數據庫環境：CentOS + MariaDB10.1.22 + galera cluster
說明：可能一部分童鞋沒用過MariaDB，MariaDB數據庫管理系統是MySQL的一個分支，主要由開源社區在維護，采用GPL授權許可。開發這個分支的原因之一是：甲骨文公司收購了MySQL后，有將MySQL閉源的潛在風險，因此社區采用分支的方式來避開這個風險。
MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。
而galera cluster是mysql多主集群，包含在MariaDB中，同時支持Percona xtradb、MySQL，是一個易於使用的高可用解決方案，在數據完整性、可擴展性及高性能方面都有可接受的表現。
問題分析：當數據庫集群正常運行的時候，可高性能正常運行，當其他節點正常關閉，只剩下一個節點的時候，也是可以正常讀寫的，但是當其他節點異常關閉時，就不能提供正常的讀寫了，因為此時數據庫集群中沒有了裁判節點，也就是此時會出現腦裂，數據庫不知道讀寫出現混亂，不能正常讀寫。就會導致如題異常。
解決方案：
背景：昨天突然接到客戶電話說系統登錄不上了，之前都好好很穩定，我想着不會有太大問題，由於是周日，我立即登錄看了日志是怎么回事，發現數據庫連接異常，如題異常；
數據庫環境：CentOS6.4 + MariaDB10.1.22 + galera cluster
說明：可能一部分童鞋沒用過MariaDB，MariaDB數據庫管理系統是MySQL的一個分支，主要由開源社區在維護，采用GPL授權許可。開發這個分支的原因之一是：甲骨文公司收購了MySQL后，有將MySQL閉源的潛在風險，因此社區采用分支的方式來避開這個風險。
MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。
而galera cluster是mysql多主集群，包含在MariaDB中，同時支持Percona xtradb、MySQL，是一個易於使用的高可用解決方案，在數據完整性、可擴展性及高性能方面都有可接受的表現。
問題分析：當數據庫集群正常運行的時候，可高性能正常運行，當其他節點正常關閉，只剩下一個節點的時候，也是可以正常讀寫的，但是當其他節點異常關閉時，就不能提供正常的讀寫了，因為此時數據庫集群中沒有了裁判節點，也就是此時會出現腦裂，數據庫不知道讀寫出現混亂，不能正常讀寫。就會導致如題異常。
解決方案：收集了很多資料，一步一步的走，最后花了一天的時間才解決這個問題；
第一步：查看完日志后，發現數據庫異常后，查看數據庫狀態：service mysql status 發現只有一台DB服務是正常啟動狀態
第二步：查看galera cluster 節點數：進入數據庫 查看集群的節點 MariaDB [(none)]> SHOW STATUS WHERE Variable_name IN; 和預想的一樣就剩一個節點了，此時查看集群配置文件/etc/my.cnf.d/server.cnf 集群配置wsrep_cluster_address="gcomm://"里配置了3個節點服務ip,也就是說目前已經掛了兩個了，經過咨詢同事之前有一個節點是正常關閉（為了節省資源）；然后就把問題縮小到目前正在使用的兩個節點上了，很明顯一個節點正常，那肯定是另一個節點異常關閉了，從而導致了現在的異常
第三步：知道是節點異常關閉的問題，那就先恢復數據庫，那么現在問題來了在重啟數據庫的時候一直Failed
經過查閱mysql日志發現有一個節點，正常關閉的節點一直處於連接超時狀態，我就修改了galera cluster 配置文件/etc/my.cnf.d/server.cnf 不用的這個集群幾點刪除，重啟還是Failed , 查看日志報錯就變了：WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)，此時針對此錯誤：
刪除所有節點的兩個緩存文件及/var/lock/subsys 目錄下的mysql 文件，然后重新啟動：
rm -rf /var/lock/subsys/mysql
cd /var/lib/mysql
rm -rf galera.cache
rm -rf grastate.dat
第一個節點這樣啟動：
service mysql start --wsrep-new-cluster
其他節點正常啟動：
service mysql start
到此處主節點已經正常啟動了，也就是說數據庫已經可以正常用了，但是集群還沒起來，此時就要查看異常節點的日志了，查看的時候發現一直重復出現一條錯誤日志：19:25:02 [ERROR] Invalid (old?) table or database name 'lost+found'
這個日志的大致意思是什么呢？就是這個“lost+found”空間是無效的，這就很明了的，我火速查看磁盤空間，結果發現此節點所占的磁盤已經100%了
到此，異常原因和解決方案已經有了。
特別感謝：https://blog.csdn.net/yabingshi_tech/article/details/105489707 、 https://blog.csdn.net/qq_41133227/article/details/94392512、https://www.cnblogs.com/xiangyuqi/p/10221129.html
如有錯誤，歡迎指正！