Menu

crash

MySQL Galera cluster crash

, , , , 0

Привет,

Днес сутринта след рутинен update на пакетите на DB сървърите попаднах на MySQL Galera cluster crash.
За няколко минути cluster-а ми се счупи тотално и част от апликациите на root.bg не работиха.

MySQL Galera cluster crash

Ето как започна всичко :

След

apt-get update && apt-get upgrade -y

нещата се объркаха :

Setting up mariadb-server-10.1 (10.1.22+maria-1~xenial) ...
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.
invoke-rc.d: initscript mysql, action "start" failed.
● mariadb.service - MariaDB database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: failed (Result: exit-code) since Thu 2017-03-16 10:35:22 EET; 4ms ago
Process: 13607 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=1/FAILURE)
Process: 13602 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 13597 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Main PID: 19373 (code=exited, status=0/SUCCESS)

Mar 16 10:35:22 border mysqld[13607]: Segmentation fault (core dumped)

Веднага предприех опит да възтановя базите чрез вградения скрипт на galera за recovery :

galera_recovery

 

обаче резултата не беше такъв какъвто се надявах да бъде :

Още..

Липса на постове в блога

, , 1

Привет,

Не съм писал отдавна – сигурно си личи. Всичко е заради липсата ми на време – много бачкам 😀

От толкова работа даже не съм видял че имам проблем с блога – постовете в блога липсваха. Причината е спирането на сървъра където е блога онзи ден (Енерго про имаха проблем и нямаше няколко часа ток в сървърното ми). Поради тази причина ми се е бъгнала таблицата с постовете и изписваше : wp_posts is marked as crashed and last (automatic?) repair failed

Реших проблема си като спрях mariadb сървъра и поправих myisam таблиците чрез :
myisamchk -r *.MYI
в директорията на базата на блога. След това пуснах mariadb сървъра и всичко си беше ок.

Тук има хубава и лоша страна ; хубавата е че базата на блога е останала от едно време с таблици на MyISAM , а лошата е точно това , че използвам MyISAM вместо InnoDB 🙁 Може би някой ден ще си конвертирам таблиците и ще си реша проблеми завинаги, но това за в момента не ми е приоритет.

MySQL innodb crash

, , , , , 0

MySQL innodb crashПривет,

В допълнение на поста ми от 12.12.2013 за MySQL innodb crash-a, искам да споделя че, този проблем отново ми се случи на същия Ubuntu сървър. Оказа се че innodb е много фин сторидж енджин на MySQL-а и явно е много податлив на crash. Пример : счупи се единия хард диск и се наложи да преместя тази виртуалка на друг дял, и след като го сторих, MySQL-а не искаше да тръгва вече.

Проблемът:

Грешката отново беше следната:

Още..

MySQL crashed and server can’t start

, , , 0

MySQL crashed and server can't start

Днес ми се случи нещо много интересно на единия убунту сървър. MySQL-а му не искаше да се пуска сам, и след като тръгнах да дебъгвам, открих че крашва. Лога беше нещо от рода:

stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f9f3fe84259]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x7f9f3fd7c2b8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbd0)[0x7f9f3eb00bd0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f9f3e157037]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f9f3e15a698]
/usr/sbin/mysqld(+0x585225)[0x7f9f3ff18225]
/usr/sbin/mysqld(+0x585629)[0x7f9f3ff18629]
/usr/sbin/mysqld(+0x64781f)[0x7f9f3ffda81f]
/usr/sbin/mysqld(+0x63e1eb)[0x7f9f3ffd11eb]
/usr/sbin/mysqld(+0x586779)[0x7f9f3ff19779]
/usr/sbin/mysqld(+0x57823c)[0x7f9f3ff0b23c]
/usr/sbin/mysqld(+0x57c4b3)[0x7f9f3ff0f4b3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f8e)[0x7f9f3eaf8f8e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9f3e21aa0d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Пробвах с myismchk но без резулатат.. Накрая открих в интернет решение на проблема ми. Добавих опцията

innodb_force_recovery = 3

в my.cnf и MySQL сървъра тръгна. Сега обаче в лога за грешките взеха да излизат тонове от това:

InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.

Тук за съжеление не открих как да спра тея грешки, и за това просто коментирах лога с грешки. В интернет пише че след innodb force recovery таблиците се оправят и след това може да се стартира сървъра без нея опция. При мен за съжеление не се получи, за това оставям recovery-то пуснато докато не открия друг начин да оправя този проблем.