Невозможно перезапустить mariadb columnstore после того, как Cra sh дБ - PullRequest
Новая
       78

Невозможно перезапустить mariadb columnstore после того, как Cra sh дБ

2 голосов
/ 09 января 2020

У меня проблема с моим БД. Он разбился сегодня утром без объяснения причин, но я знаю, что некоторые индексы повреждены. Я попытался перезапустить его с помощью команды mcsadmin restartSystem, но получил сообщение, в котором говорилось что-то вроде «api named failed»

Так что я остановил его и попытался перезапустить, используя 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

По последствиям , когда я пытаюсь вызвать mcs mysql, я получаю чудесное сообщение: 

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, Матье

Ответы [ 2 ]

1 голос
/ 16 января 2020

Спасибо за ваш комментарий. Фактически, это была оригинальная проблема, которая вызвала крэ sh. Нам, наконец, удалось ее решить, но, на самом деле, эта текущая проблема была вызвана тем, что некоторые индексы наших таблиц innodb были повреждены из-за cra sh, поэтому нам пришлось делать восстановление. Чтобы сделать это, мы следовали этому методу:

  • Остановите систему с помощью mcsadmin shutdownSystem.
  • Завершить процесс mysql.
  • edit /etc/my.cnf установить значение переменной innodb_force_recovery = 1 (приращение 1 на 1, если не работает).
  • перезагрузка mysql.
  • сбросить наши таблицы innodb.
  • удалить эти таблицы (возьмите columnstore должен быть остановлен, иначе вы также потеряете свои таблицы mcs).
  • stop mysql.
  • комментарий innodb_force_recovery в /etc/my.cnf
  • restart mysql.
  • import dump.
  • перезагрузка системы с помощью mcsadmin restartSystem.
1 голос
/ 15 января 2020

Просто дикое предположение, но вы проверили на своем дисковом пространстве?

...