我的数据库有问题。今天早晨它崩溃了，没有任何解释，但我知道某些索引已损坏。我尝试使用命令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
在不重新安装或删除数据的情况下如何解决？
thx，Mathieu
答案 0 :(得分：1)
只是一个疯狂的猜测，但是您是否检查了磁盘空间？
答案 1 :(得分：1)
谢谢您的评论。实际上，这是引发崩溃的原始问题。我们终于设法解决了这个问题，但实际上，当前问题是由于以下事实造成的：由于崩溃，我们的innodb表的某些索引已损坏，因此我们必须进行恢复。 为此，我们遵循了以下方法：