数据库崩溃后无法重新启动 mariadb 列存储

Posted 2023-03-25

【中文标题】数据库崩溃后无法重新启动 mariadb 列存储

【英文标题】：Impossible to restart mariadb columnstore after a crash of db

【发布时间】：2020-01-09 13:33:38

【问题描述】：

我的数据库有问题。今天早上它在没有任何解释的情况下崩溃了，但我知道某些索引已损坏。我尝试使用命令 mcsadmin restartSystem 重新启动它，但我收到一条消息，上面写着“api 调用失败”之类的内容

所以我停止了它并尝试使用 stopSystem 和 startSystem 重新启动它，但它失败了。因此，我使用 shutdownSystem y 停止了所有操作，并重新启动了所有服务器以重置所有环境。

现在，每次我检查进程状态时，我都会得到：

Process             Module    Status            Last Status Change        Process ID
------------------  ------    ---------------   ------------------------  ----------
ProcessMonitor      um1       ACTIVE            Thu Jan  9 14:02:57 2020        9533
ServerMonitor       um1       ACTIVE            Thu Jan  9 14:16:21 2020       43455
DBRMWorkerNode      um1       ACTIVE            Thu Jan  9 14:16:22 2020       43542
ExeMgr              um1       ACTIVE            Thu Jan  9 14:16:26 2020       43737
DDLProc             um1       ACTIVE            Thu Jan  9 14:16:30 2020       43882
DMLProc             um1       ACTIVE            Thu Jan  9 14:16:34 2020       44093
mysqld              um1       MAN_OFFLINE       Thu Jan  9 14:16:39 2020

ProcessMonitor      pm1       ACTIVE            Thu Jan  9 14:01:36 2020        9502
ProcessManager      pm1       ACTIVE            Thu Jan  9 14:01:42 2020        9919
DBRMControllerNode  pm1       ACTIVE            Thu Jan  9 14:16:17 2020       24950
ServerMonitor       pm1       ACTIVE            Thu Jan  9 14:16:19 2020       24975
DBRMWorkerNode      pm1       ACTIVE            Thu Jan  9 14:16:19 2020       25009
PrimProc            pm1       ACTIVE            Thu Jan  9 14:16:23 2020       25074
WriteEngineServer   pm1       ACTIVE            Thu Jan  9 14:16:24 2020       25105

结果，当我尝试调用 mcsmysql 时，我得到了一个美妙的结果：

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/mariadb/columnstore/mysql/lib/mysql/mysql.sock' (111)

以及 err.log 中我无法理解的这条消息：

2020-01-09 14:30:01 0 [Warning] /usr/local/mariadb/columnstore/mysql//bin/mysqld: unknown variable 'loose-server_audit_syslog_info=MyColumnStoreClusterRcc'
2020-01-09 14:30:01 0 [Note] Server socket created on IP: '::'.
2020-01-09 14:30:01 0 [Note] Reading of all Master_info entries succeeded
2020-01-09 14:30:01 0 [Note] Added new Master_info '' to hash table
2020-01-09 14:30:01 0 [Note] /usr/local/mariadb/columnstore/mysql//bin/mysqld: ready for connections.
Version: '10.3.16-MariaDB-log'  socket: '/usr/local/mariadb/columnstore/mysql/lib/mysql/mysql.sock'  port: 3306  Columnstore 1.2.5-1
mysys/stacktrace.c:270(my_print_stacktrace)[0x55eefe5ab279]
sql/signal_handler.cc:209(handle_fatal_signal)[0x55eefe0e3b6f]
sigaction.c:0(__restore_rt)[0x7fc2c36945d0]
:0(__GI_raise)[0x7fc2c15712c7]
:0(__GI_abort)[0x7fc2c15729b8]
4.8.2/ostream:530(std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) [clone .part.9])[0x55eefde60428]
page/page0page.cc:865(page_copy_rec_list_start(buf_block_t*, buf_block_t*, unsigned char*, dict_index_t*, mtr_t*))[0x55eefe2d1c88]
btr/btr0btr.cc:3750(btr_compress(btr_cur_t*, unsigned long, mtr_t*))[0x55eefe39bb76]
btr/btr0cur.cc:5411(btr_cur_compress_if_useful(btr_cur_t*, unsigned long, mtr_t*))[0x55eefe3ab63e]
btr/btr0cur.cc:5843(btr_cur_pessimistic_delete(dberr_t*, unsigned long, btr_cur_t*, unsigned long, bool, mtr_t*))[0x55eefe3aea72]
row/row0purge.cc:153(row_purge_remove_clust_if_poss_low(purge_node_t*, unsigned long))[0x55eefe3227be]
row/row0purge.cc:198(row_purge_remove_clust_if_poss)[0x55eefe3243c9]
row/row0purge.cc:1261(row_purge)[0x55eefe325526]
que/que0que.cc:1042(que_thr_step)[0x55eefe2e546f]
include/sync0types.h:1125(my_atomic_addlint)[0x55eefe365120]
srv/srv0srv.cc:2617(srv_do_purge)[0x55eefe34babb]
pthread_create.c:0(start_thread)[0x7fc2c368cdd5]
/lib64/libc.so.6(clone+0x6d)[0x7fc2c163902d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): is an invalid pointer
Connection ID (thread ID): 1
Status: NOT_KILLED

如何在不重新安装或删除我的数据的情况下解决它？

谢谢，马修

【参考方案1】：

只是一个疯狂的猜测，但你检查过你的磁盘空间吗？

【参考方案2】：

谢谢你的评论。这实际上是引发崩溃的原始问题。我们终于设法解决了它，但实际上，当前的问题是由于我们的 innodb 表的某些索引由于崩溃而损坏，因此我们不得不进行恢复。 为此，我们遵循了以下方法：

使用 mcsadmin shutdownSystem 停止系统。 杀死mysql进程。 编辑 /etc/my.cnf 将值设置为变量 innodb_force_recovery =1（如果不起作用，则增加 1）。 重启mysql。 转储我们的 innodb 表。 删除这些表（必须停止获取列存储，否则您将 也松开你的 mcs 表）。 停止 mysql。 在 /etc/my.cnf 中评论 innodb_force_recovery 重启mysql。 导入转储。 使用 mcsadmin restartSystem 重新启动系统。