Website down - MariaDB failed

Galina Nv · 25 Юни 2023

Здравейте.Имам работещ уебсайт (не е нов) , който изведнъж спря.Събуждайки се сутринта констатирах че не отваря.Направих контакт с моя доставчик,като предположих ,че може да е някоя профилактика,но не.Казаха че от тяхна страна всичко е ок
Използвам Openlitespeed с MariaDB и Ubuntu 20

MySQL cannot find the table of plugins 'mysql.plugins'

OLS показва актив , MariaDB failed

Код:

lshttpd.service - OpenLiteSpeed HTTP Server
     Loaded: loaded (/etc/systemd/system/lshttpd.service; enabled; vendor prese>
     Active: active (running) since Sun 2023-06-25 04:41:05 UTC; 3h 9min ago
    Process: 322602 ExecStart=/usr/local/lsws/bin/lswsctrl start (code=exited, >
   Main PID: 322616 (litespeed)
     CGroup: /system.slice/lshttpd.service
             ├─322616 openlitespeed (lshttpd - main)
             ├─322617 openlitespeed (lscgid)
             ├─322618 openlitespeed (lshttpd - #01)
             ├─322619 openlitespeed (lshttpd - #02)
             ├─322620 openlitespeed (lshttpd - #03)
             ├─322621 openlitespeed (lshttpd - #04)
             ├─354870 lsphp
             └─377408 lsphp

Jun 25 04:41:02 kixia systemd[1]: This usually indicates unclean terminatio>
Jun 25 04:41:02 kixia systemd[1]: lshttpd.service: Found left-over process >
Jun 25 04:41:02 kixia systemd[1]: This usually indicates unclean terminatio>
Jun 25 04:41:02 kixia systemd[1]: lshttpd.service: Found left-over process >
Jun 25 04:41:02 kixia systemd[1]: This usually indicates unclean terminatio>
Jun 25 04:41:02 kixia systemd[1]: Starting OpenLiteSpeed HTTP Server...
Jun 25 04:41:02 kixia lswsctrl[322602]: [OK] Send SIGUSR1 to 310608
Jun 25 04:41:05 kixia systemd[1]: Started OpenLiteSpeed HTTP Server.
 lshttpd.service - OpenLiteSpeed HTTP Server



    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2023-06-25 05:08:44 UTC; 3h 7min ago
       Docs: man:mysqld(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 331113 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 331114 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 331116 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl >
    Process: 331166 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
   Main PID: 331166 (code=exited, status=1/FAILURE)
     Status: "MariaDB server is down"

Jun 25 05:08:43 kixia systemd[1]: Starting MariaDB 10.3.38 database server...
Jun 25 05:08:44 kixia systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 05:08:44 kixia systemd[1]: mariadb.service: Failed with result 'exit-code'.
Jun 25 05:08:44 kixia systemd[1]: Failed to start MariaDB 10.3.38 database server.

Log file

Код:

2023-06-25  5:08:43 0 [ERROR] InnoDB: Cannot create log files because data files are corrupt or the database was not shut down cleanly after creating the data files.
2023-06-25  5:08:43 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2023-06-25  5:08:43 0 [Note] InnoDB: Starting shutdown...
2023-06-25  5:08:44 0 [ERROR] Plugin 'InnoDB' init function returned error.
2023-06-25  5:08:44 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2023-06-25  5:08:44 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-06-25  5:08:44 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2023-06-25  5:08:44 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2023-06-25  5:08:44 0 [ERROR] Aborting

Някой има ли идея как да се справя с проблема.Пробвах с Backup / Purge library / Reinstall ..... , но стана по страшно . След това server restore и пак съм от 0 та.
Благодаря предварително

fast_and_the_curious · 25 Юни 2023

Вероятно са правени промени по сървъра от хостинга.

Много обичам да се събудя и сайта да не работи, а от хостинга да ми обясняват как нищо не са направили, после да се окаже че само леко са ме преместили на друг сървър.

Torbalan Trolski · 25 Юни 2023

Виж във /var/lib/mysql или където там е според твоя сетъп/дистрибуция трябва да имаш нещо такова
ib_logfileXX
...
aria_log_control

Премести тези файлове някъде и рестарт.

По-малко вероятен вариант някой да си е играл със se-linux или по някаква причина да няма пермишъни.

Galina Nv · 25 Юни 2023

Torbalan Trolski каза:
Виж във /var/lib/mysql или където там е според твоя сетъп/дистрибуция трябва да имаш нещо такова
ib_logfileXX
...
aria_log_control

Премести тези файлове някъде и рестарт.

По-малко вероятен вариант някой ако си е играл със se-linux да няма пермишъни.

Здравей и благодаря
Да има файла . Пробвах , преименувах го , рестартирах MariaDB и нищо
Пробвах това решение и вчера , но пак беше без резултат . Създава нов файл и до там
P.S.
имам само aria_log_control
другите 2 файла ib_logfile0 и 1 липсват

Galina Nv · 25 Юни 2023

fast_and_the_curious каза:
Вероятно са правени промени по сървъра от хостинга.

Много обичам да се събудя и сайта да не работи, а от хостинга да ми обясняват как нищо не са направили, после да се окаже че само леко са ме преместили на друг сървър.

Здравей и благодаря за отговора
Да , веднъж го направиха без предупреждение . След това добре че попитах та се оказах с ново IP
И аз сега съм в шок ,как ставам от сън и нищо не работи ,като аз имам всичко up to date , но не от сега за да знам че аз съм сгафила някъде, а и винаги следя логовете,досега не съм имала нито една грешка
Объркана съм ужасно

contra · 25 Юни 2023

Най-добре изчакай и топадминът да се изкаже.

Моят (аматьорски) подход би бил да копирам папките на базите данни от /var/lib/mysql/ някъде другаде и после да реинстална MariaDB.

Torbalan Trolski · 25 Юни 2023

Galina Nv каза:
Да има файла . Пробвах , преименувах го , рестартирах MariaDB и нищо

Сега загледах лога по-внимателно

InnoDB: Cannot create log files because data files are corrupt or the database was not shut down cleanly

така че премахването на логовете няма да помогне.

Galina Nv · 25 Юни 2023

contra каза:
Най-добре изчакай и топадминът да се изкаже.

Моят (аматьорски) подход би бил да копирам папките на базите данни от /var/lib/mysql/ някъде другаде и после да реинстална MariaDB.

Да, вариант е ,но ще изчакам
Вчера пробвах , специално с реинсталация на MariaDB и нещата бяха много страшни.Не запазих лог , за съжаление , но всяка линия беше с грешка . След това изтрих напълно Maria DB + всички файлове и конфигурации и не ми позволи да я инсталирам наново.Затова резетнах всичко до последния backup който имам и търся помощ,защото някъде нещо не се получава ок.Нещо ми убягва а и не съм специалист във сфера база данни (Sql database)
Благодаря ти

Galina Nv · 25 Юни 2023

Torbalan Trolski каза:
Сега загледах лога по-внимателно

InnoDB: Cannot create log files because data files are corrupt or the database was not shut down cleanly

така че премахването на логовете няма да помогне.

М,да . За жалост . Някъде проблема "може би" е
Could not open mysql.plugin table. Some plugins may be not loaded
но от това което прочетох наоколо и тествах ,нищо не помогна
Не намира таблиците а и тях ги няма в папките на сървъра
А и как се случва просто така . Ако нещо съм пипала ще знам .Но да се събудя сутринта и всичко да е леш е много объркващо
Все едно е претърпяла тотален краш , но как

contra · 25 Юни 2023

Щом са счупени данните, може да е спрел токът на сървъро. Какво съветва ChatGPT като го питаме дали може да разберем ако се е случило нещо подобно:

Galina Nv · 25 Юни 2023

contra каза:
Щом са счупени данните, може да е спрел токът на сървъро. Какво съветва ChatGPT като го питаме дали може да разберем ако се е случило нещо подобно:

journal

Код:

-- Logs begin at Fri 2023-04-28 23:44:06 UTC, end at Sun 2023-06-25 16:37:50 UTC. --
Jun 24 12:41:47 kalotixia kernel: Linux version 5.4.0-152-generic (buildd@lcy02-amd64-081) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #169-Ubuntu SMP Tue Jun >
Jun 24 12:41:47 kalotixia kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-152-generic root=UUID=c33adcdc-c2f2-4e05-9114-9e1e0a3a5ecd ro console=tty1 console=ttyS0
Jun 24 12:41:47 kalotixia kernel: KERNEL supported cpus:
Jun 24 12:41:47 kalotixia kernel:   Intel GenuineIntel
Jun 24 12:41:47 kalotixia kernel:   AMD AuthenticAMD
Jun 24 12:41:47 kalotixia kernel:   Hygon HygonGenuine
Jun 24 12:41:47 kalotixia kernel:   Centaur CentaurHauls
Jun 24 12:41:47 kalotixia kernel:   zhaoxin   Shanghai
Jun 24 12:41:47 kalotixia kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jun 24 12:41:47 kalotixia kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jun 24 12:41:47 kalotixia kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jun 24 12:41:47 kalotixia kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Jun 24 12:41:47 kalotixia kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Jun 24 12:41:47 kalotixia kernel: BIOS-provided physical RAM map:
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bffd9fff] usable
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x00000000bffda000-0x00000000bfffffff] reserved
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x0000000100000000-0x000000023fffffff] usable
Jun 24 12:41:47 kalotixia kernel: BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
Jun 24 12:41:47 kalotixia kernel: NX (Execute Disable) protection: active
Jun 24 12:41:47 kalotixia kernel: SMBIOS 2.8 present.
Jun 24 12:41:47 kalotixia kernel: DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
Jun 24 12:41:47 kalotixia kernel: Hypervisor detected: KVM
Jun 24 12:41:47 kalotixia kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
Jun 24 12:41:47 kalotixia kernel: kvm-clock: cpu 0, msr 134001001, primary cpu clock
Jun 24 12:41:47 kalotixia kernel: kvm-clock: using sched offset of 4151529362 cycles
Jun 24 12:41:47 kalotixia kernel: clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Jun 24 12:41:47 kalotixia kernel: tsc: Detected 2495.312 MHz processor
Jun 24 12:41:47 kalotixia kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jun 24 12:41:47 kalotixia kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Jun 24 12:41:47 kalotixia kernel: last_pfn = 0x240000 max_arch_pfn = 0x400000000
Jun 24 12:41:47 kalotixia kernel: MTRR default type: write-back
Jun 24 12:41:47 kalotixia kernel: MTRR fixed ranges enabled:
Jun 24 12:41:47 kalotixia kernel:   00000-9FFFF write-back
Jun 24 12:41:47 kalotixia kernel:   A0000-BFFFF uncachable
Jun 24 12:41:47 kalotixia kernel:   C0000-FFFFF write-protect
Jun 24 12:41:47 kalotixia kernel: MTRR variable ranges enabled:
Jun 24 12:41:47 kalotixia kernel:   0 base 0000C0000000 mask FFFFC0000000 uncachable

uptime
16:39:46 up 1 day, 3:58, 2 users, load average: 0.06, 0.22, 0.16

auth.log

Код:

Jun 25 00:00:01 kalotixia sudo:     root : TTY=unknown ; PWD=/root ; USER=nobody ; COMMAND=/usr/bin/cat /home/kalotixia.com/logs/kalotixia.com.access_log
Jun 25 00:00:01 kalotixia sudo: pam_unix(sudo:session): session opened for user nobody by (uid=0)
Jun 25 00:00:01 kalotixia sudo: pam_unix(sudo:session): session closed for user nobody
Jun 25 00:00:01 kalotixia CRON[205807]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:02 kalotixia sudo:     root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/usr/bin/chown -R cyberpanel:cyberpanel /home/cyberpanel
Jun 25 00:00:02 kalotixia sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 25 00:00:02 kalotixia sudo: pam_unix(sudo:session): session closed for user root
Jun 25 00:00:02 kalotixia CRON[205806]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205799]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205801]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205805]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205800]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205802]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205798]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205797]: pam_unix(cron:session): session closed for user root
Jun 25 00:00:03 kalotixia CRON[205804]: pam_unix(cron:session): session closed for user root
Jun 25 00:01:16 kalotixia sshd[206196]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.96  user=root
Jun 25 00:01:18 kalotixia sshd[206196]: Failed password for root from 218.92.0.96 port 61736 ssh2
Jun 25 00:01:22 kalotixia sshd[206196]: Failed password for root from 218.92.0.96 port 61736 ssh2
Jun 25 00:01:25 kalotixia sshd[206196]: Failed password for root from 218.92.0.96 port 61736 ssh2
Jun 25 00:01:26 kalotixia sshd[206196]: Received disconnect from 218.92.0.96 port 61736:11:  [preauth]
Jun 25 00:01:26 kalotixia sshd[206196]: Disconnected from authenticating user root 218.92.0.96 port 61736 [preauth]
Jun 25 00:01:26 kalotixia sshd[206196]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.96  user=root
Jun 25 00:02:38 kalotixia sshd[206586]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.96  user=root
Jun 25 00:02:41 kalotixia sshd[206586]: Failed password for root from 218.92.0.96 port 44158 ssh2
Jun 25 00:02:42 kalotixia sshd[206586]: Received disconnect from 218.92.0.96 port 44158:11:  [preauth]
Jun 25 00:02:42 kalotixia sshd[206586]: Disconnected from authenticating user root 218.92.0.96 port 44158 [preauth]
Jun 25 00:03:01 kalotixia CRON[206734]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 25 00:03:01 kalotixia CRON[206734]: pam_unix(cron:session): session closed for user root
Jun 25 00:03:41 kalotixia sshd[206918]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.108  user=root
Jun 25 00:03:43 kalotixia sshd[206918]: Failed password for root from 218.92.0.108 port 12037 ssh2
Jun 25 00:03:45 kalotixia sshd[206918]: Failed password for root from 218.92.0.108 port 12037 ssh2
Jun 25 00:03:47 kalotixia sshd[206918]: Failed password for root from 218.92.0.108 port 12037 ssh2
Jun 25 00:03:49 kalotixia sshd[206918]: Received disconnect from 218.92.0.108 port 12037:11:  [preauth]
Jun 25 00:03:49 kalotixia sshd[206918]: Disconnected from authenticating user root 218.92.0.108 port 12037 [preauth]
Jun 25 00:03:49 kalotixia sshd[206918]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.108  user=root
Jun 25 00:03:51 kalotixia sshd[206975]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.108  user=root
Jun 25 00:03:54 kalotixia sshd[206975]: Failed password for root from 218.92.0.108 port 32190 ssh2
Jun 25 00:03:58 kalotixia sshd[206975]: Failed password for root from 218.92.0.108 port 32190 ssh2
Jun 25 00:04:02 kalotixia sshd[206975]: Failed password for root from 218.92.0.108 port 32190 ssh2
Jun 25 00:04:04 kalotixia sshd[206975]: Received disconnect from 218.92.0.108 port 32190:11:  [preauth]
Jun 25 00:04:04 kalotixia sshd[206975]: Disconnected from authenticating user root 218.92.0.108 port 32190 [preauth]
Jun 25 00:04:04 kalotixia sshd[206975]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.108  user=root

Май е ок тока му , ама моя изгорЕ със сигурност

contra · 25 Юни 2023

Тоя ъптайм само 1 ден... някой рестартвал ли го е вчера?

Galina Nv · 25 Юни 2023

contra каза:
Тоя ъптайм само 1 ден... някой рестартвал ли го е вчера?

Да ,попитах моя доставчик дали случайно имат някакъв мой backup при тях да го пуснат . От там е

s1yf0x · 25 Юни 2023

contra каза:
Тоя ъптайм само 1 ден... някой рестартвал ли го е вчера?

То от луната се вижда в логовете, че е рестартиран, кога е рестартиран, че е виртуална машина и след рестарта му е сменен хостнейма. За останалото от топадмина мога да ти пратя цена на час.

contra · 26 Юни 2023

s1yf0x каза:
То от луната се вижда в логовете, че е рестартиран, кога е рестартиран, че е виртуална машина и след рестарта му е сменен хостнейма. За останалото от топадмина мога да ти пратя цена на час.

Само ти ги виждаш тия неща.

Въпросът е дръпнат ли му е щепсела, тая смяна на хостнейма ли е потрошила нещо, тоест има ли сеир или няма?
Пусни малко царевичка да се радваме.

s1yf0x · 26 Юни 2023

само от https://www.nforce.com/ могат да ти кажат. Иначе сеир има, гледам Ви сеира какви куци съвети давате и каква мъка е, че доставчика е чужд, а не български и няма къде да се ожалвате.

Galina Nv · 26 Юни 2023

s1yf0x каза:
То от луната се вижда в логовете, че е рестартиран, кога е рестартиран, че е виртуална машина и след рестарта му е сменен хостнейма. За останалото от топадмина мога да ти пратя цена на час.

Здравей . Преди години съм била с друг домейн на бг хост , но това е и друга тема
Днес пробвах

Код:

systemctl stop mariadb
rm -R /var/lib/mysql/*
mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
systemctl start mariadb

но нищо освен че инсталира нова mysql и до там . MariaDb актив , но каква полза като грешките не спират

pdns е със статус activating
lsws актив
mariadb актив

Имам един backup който е в контрол панела на доставчика ми ,но не последен
имам и mysql-lib / my.conf.bak / restore_backup.sql

Имах запитване и в друг форум откъдето ми отговори само един човек

The data files the DBMS is trying to start from are toast. Gone. Kaput.

If you're lucky then you were running mysqld from a non-default location (i.e. other than /var/lib/mysql) and the config file you had in place has been overwritten or deleted. You just need to fix the config.

Има и вариант, то е ясно Rebuilt , но все си мисля че проблема не е с corrypt system и все си мисля че има начин за фиксация , но не съм експерт . Ако бях нямаше да съм тук

Моля те ако прецениш че имам решение на проблема сподели ми цена . Мога да върна всичко до последния backup който имам
и отделно ако имаш запитване за нещо конкретно моля сподели

Благодаря

P.S. Аз наистина недоумявам как сутринта отворих сайта и не работеше,като се има в предвид не само че не съм правила никакви ъпдейти ами дори не бях отваряла контрол панела повече от седмица . Това ме шокира най-много

Galina Nv · 26 Юни 2023

contra каза:
Само ти ги виждаш тия неща.

Въпросът е дръпнат ли му е щепсела, тая смяна на хостнейма ли е потрошила нещо, тоест има ли сеир или няма?
Пусни малко царевичка да се радваме.

Започва да ме съмнява и мен нещо такова . Реална причина от моя страна да спре всичко да работи няма 101%
Както споделих преди малко дори контрол панела на съм отваряла , а да не говорим за ъпдейти,терминали и т.н.
При безпроблемно работещ сайт за какво да ми е да го правя , а ако системата е крашнала по НЯКАКВА причина , каква ли . Аз съм уж с добри сървър параметри .

contra · 26 Юни 2023

Това:

rm -R /var/lib/mysql/*

е изтрило всички бази.
Ако въобще е имало нещо работещо там.
И ако въобще командата е проработила без sudo отпред.

Ако верно е изтрило, навява мисълта че базите може да не са били с правилния owner и това евентуално (?) да е бил проблемът. Влез във /var/lib и напиши 'ls -l', после погледни средните колони за папката 'mysql'. Трябва owner и group да са 'mysql'.

ПП: Само топадминът може да ти помогне.

Galina Nv · 26 Юни 2023

contra каза:
Това:

е изтрило всички бази.
Ако въобще е имало нещо работещо там.
И ако въобще командата е проработила без sudo отпред.

Ако верно е изтрило, навява мисълта че базите може да не са били с правилния owner и това евентуално (?) да е бил проблемът. Влез във /var/lib и напиши 'ls -l', после погледни средните колони за папката 'mysql'. Трябва owner и group да са 'mysql'.

ПП: Само топадминът може да ти помогне.

Да , че ги изтрива не ме плаши докато все още имам поне един backup под ръка . Пробвах ако презапиша след това файловете от бакъпа но не стана . Mariadb е пак down
Правата при проверката от вчера бяха точни mysql-mysql и root-root, а сега са само root-root
Всичко проработи без sudo с статус ок , дори сложих нова парола за mysql
sda1 inodes е 6% с size 43% use - 28gb available

Website down - MariaDB failed

Member

Well-Known Member

Well-Known Member

Member

Member

Well-Known Member

Well-Known Member

Member

Member

Well-Known Member

Member

Well-Known Member

Member

Well-Known Member

Well-Known Member

Well-Known Member

Member

Member

Well-Known Member

Member