Hosting firma kako baca krivicu na korisnika - mišljenje tražim

Hosting i serveri
1

Dakle nisam bio na webu mjesec ili koji tjedan kada je zadnji put sve ažurriano.

Wordpress stranica.
Skoro ništa dodataka, 3 komada sve kupa jedan od njih je DIVI.

Dođem danas strancia kaže defaultna poruka Wordpressa da ne može ostavariti konekciju za bazom.

Pregledam bazu, ime password sve uredu nije mijenjano.

PHPMyAdmin, baza je tamo i stoji.

Zovem podršku, oni već u drugoj rečenicu moram ovo i ovo napraviti.

ČEKAJ SAMO MALO!??
Što ja to MORAM napraviti, pa nitko dirao web nije, odjednom ne radi…

I već u drugoj rečenici programer je kriv, nije ažuriran wordpress možda ovo ono, odbijanje bilo čga od starta.

Poludim i tražim nekoga višeg da pregleda sve.
za to vrijeme otkrijem u error logu ovo:
[20-Jul-2025 20:38:25 UTC] WordPress database error Index for table ‘./database_name/options_table.MYI’ is corrupt; try to repair it for query
INSERT INTO options_table (option_name, option_value, autoload)
VALUES (‘_site_transient_timeout_theme_patterns-abc123…’, ‘1753045705’, ‘off’)
ON DUPLICATE KEY UPDATE option_name = VALUES(option_name),
option_value = VALUES(option_value), autoload = VALUES(autoload)
made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’),
require_once(‘wp-config.php’), require_once(‘wp-settings.php’),
do_action(‘init’), WP_Hook->do_action, WP_Hook->apply_filters,
_register_theme_block_patterns, WP_Theme->get_block_patterns,
WP_Theme->set_pattern_cache, set_site_transient, add_site_option,
add_network_option, add_option

…

[20-Jul-2025 20:38:27 UTC] WordPress database error Index for table ‘./database_name/options_table.MYI’ is corrupt; try to repair it for query
INSERT INTO options_table (option_name, option_value, autoload)
VALUES (‘_transient_doing_cron’, ‘1753043906.9405…’, ‘on’)
ON DUPLICATE KEY UPDATE option_name = VALUES(option_name),
option_value = VALUES(option_value), autoload = VALUES(autoload)
made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’),
require_once(‘wp-config.php’), require_once(‘wp-settings.php’),
do_action(‘wp_loaded’), WP_Hook->do_action, WP_Hook->apply_filters,
_wp_cron, spawn_cron, set_transient, add_option

…

[20-Jul-2025 20:39:59 UTC] WordPress database error
Table ‘./database_name/options_table’ is marked as crashed and last (automatic?) repair failed
for query SELECT option_value FROM options_table WHERE option_name = ‘plugin_config_key’ LIMIT 1
made by require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’),
include(‘/themes/theme-name/…’), do_action(…), WP_Hook->apply_filters, …, get_option

Pa čekaj samo malo…

Stranica radi godinama, uvijek ažurna, održavana, i sada preko vikenda samo stane, a nitko na njoj radio nije?

Čudno.

Mogu ja nraptii repair , sistem restore koji su predlagali nema problema, no to nije moj posao ako je netko tamo nešto pokvario, točnije mu se kvarilo ili se sruši sql server, ili pto god.

Odrade oni valjda samo repair ili to god, sve radi.

I onda klijent i ja dobijemo obrazloženje koje sam tražio:
" Web programer mora provjeriti aplikaciju koja je zapisivala u tablicu options_table, a nije završila s unosom te je time onemogućila daljnji ispravan rad baze podataka database_name."

Pa ljudi moji pričam o jednom top hostingu u HR sa desetcima godina rada, i adminu iz više podrške takve stvari šalje meni i mom klijentu, ne spominjući 99.9% šanse i vjerojatnosti da je problem sa hostingom.

Zar se toliko nisko palo.
Ako sam zaj**** uvijek priznam i popravim, ali da ovako se radi i to u našoj “top”
ponudi, je zaista prestrašno.

2

ti bas imas problema sa tim hosting provajderima :rofl: predji na infomaniak shared i ne boli te glava, kakvi domaci

1 Like
3

Priznali su da postoji i opcija koju sam naveo, ali naravno nigdje u logovima nemaju zapis o tom događaju.

eto wordpress forsao bazu dok je nije rušio i zato je kriv programer. Napravila se corupt baza, crashed što god eto jer nešto worpdress nije mogao zapisati u nju???

ovo nije kokoš ili jaje ovo je egzaktno. No eto programer je kriv, budemo to naglasili:)

Za sada pokušavam sa hetznerom.

godinu i nešto par klijenata da vidim u ćemu je tamo problem, za sada apsolutno ništa.

Uzei Manged VC60 da vidim i to je predivno za te novce u HR nisam dobio ponudu za takvu uslugu.

4

Jel ovo drži neko naš?

Ps
Interserver, ja kod njih, podršku ako fino zamoliš, ljudi čak poslušaju da ti uđu u wp i riješe ti neke tvoje probleme, ja prije to plaćao “masno” “programerima”… A ostale probleme da ne spominjem…

5

Napravi repair baze preko phpmyadmin i to je sve.

6

Isto preporuka za njih :slight_smile:

Meni su i naši iz mydataknox također susretljivi

7

nope

8

Zašto bi to radio ako je recimo prolem nastao zbog greške na hostingu?

O tome ti pričam, mogu ja to napraviti uopće nije problem, nego prihvatiti da je problem kod tebe i odraditi da se popravi.

Iza mene nitko ne ide popravljati moje greške, meni ako netko javi da sam naešto krivo napravio, ja sam taj koji uređuje to.

A ovdje mi kaže napravite to i to u prvoj rečenici, a drugoj ažuriraj wordpress… dajte molim vas.

9

Eto nastavka.

[23-Jul-2025 06:12:26 UTC] WordPress database error Table ‘./xxyy/abc_postmeta’ is marked as crashed and last (automatic?) repair failed for query SELECT post_id, meta_key, meta_value FROM

Nitko ništa radio i gle stranica se sama od sebe srušlila. Točnije nije, nego tablica.

I vjerojatno je opet kriva stranica ili programer, ili ne ažurirana stranica…

Ma se** mi se od ovoga.

A u prošlom odgovoru nigdje napomenuli da možda može biti njihova greška tj od strane servera.
Samo da programer mora provjeriti ovo i ono.

Posljednj hosting koji sam smatrao da je uredu u HR, ma mičem se od toga svega.

A stranica je u rasulu, backedn radi, ali ako je post meta uništen, onda je ovo živa katastrofa.

EDIT:
tablice su sve myisam koje su za sada se rušile.
ima li prednsoti da prebacim to možda u inno radi ovakvih stvari?

10

a o kojem hostingu je riječ, da znamo je li vrijeme bježat ako netko ima stranice tamo?!

11

Samo da napomenem nekad se zna dogoditi da MySQL tablice same od sebe “puknu”, posebno ako je došlo do kakvog prekida u radu servera ili neispravnog gašenja baze. U takvom slučaju dobro je provjeriti tablice i napraviti REPAIR TABLE da se sve vrati u normalu. Ovo se posebno odnosi na stare MyISAM tablice, koje su osjetljivije na ovakve stvari.

12

Vidim da imate tipičnu MySQL grešku tablica abc_postmeta je “crashed” i automatski pokušaj popravka nije uspio. Ovo se zna dogoditi s MyISAM tablicama, pogotovo ako server nije pravilno ugašen ili je došlo do prekida u radu diska.

Preporučujem da pokušate ručno popraviti tablicu iz phpMyAdmina ili preko MySQL konzole:

REPAIR TABLE abc_postmeta;

13

Da, tipična je možda. No od hoatinga navode da nikako ništa nije do njih ni i jednom njihovom logu ništa nije vidljivo da se srušilo, stalo sa radom, nestali resursi, baš ništa.

Par puta naglašeno zadnji put izričito odbijanje ikakve greške, da postoji 250 korisnika tamo da im je ovo prvi put da nikome se ne ruši da je problem isključivo stranica i programer.

Na tom hostinunuzđeš čisti WordPress ručno gore ili preko sofftaculisa ista stvar pola tablica je myisam.

Da li da pretvaramo u inbox dB koje su myisam tabele?

Da li treba paziti na nešto?

1 Like
14

Razumijem i nije prvi put da hosting sve prebaci na korisnika. No ako i čista instalacija WordPressa tamo stvara tablice kao MyISAM, to nije baš standardno. WordPress već dugo koristi InnoDB kao default, tako da je pitanje je li im server možda još uvijek postavljen da koristi MyISAM kao zadani engine.

Što se tiče tvoje ideje da svakako bi bilo dobro pretvoriti postojeće MyISAM tablice u InnoDB, pogotovo one koje se često čitaju i pišu (poput postmeta, options, posts, itd.). MyISAM je poznat po tome da puca kod naglog gašenja servera, dok InnoDB to puno bolje podnosi jer ima ugrađen crash recovery.

Prije toga naravno napravi backup baze, čisto za svaki slučaj.

Možeš ručno provjeriti koje su tablice još uvijek MyISAM ovom naredbom:

SHOW TABLE STATUS WHERE Engine = ‘MyISAM’;

A konverzija je jednostavna:

ALTER TABLE ime-tablice ENGINE=InnoDB;

Ponovi to za svaku tablicu koju želiš prebaciti. Samo pazi ako neka od tablica koristi FULLTEXT indekse, jer ih u starijim verzijama InnoDB ne podržava ali ako koristiš moderniji MySQL (5.6+), ne bi trebalo biti problema.

EDIT:
Iskreno 99% sam siguran da je u nekom trenutku došlo do naglog gašenja njihovog servera makar to bilo samo na par sekundi ili minut / dvije. Znam da oni tvrde da je sve u redu ali MyISAM tablice ne pucaju same od sebe i to ne baš ovako često i bez razloga.

Imam iskustva s ovakvim stvarima i ovo nije prvi put da vidim ovakvu situaciju. Uvijek je isti princip da hosting ništa ne vidi u logovima, a tablice niotkud puknu. Ako je došlo čak i do kratkog prekida napajanja, to se rijetko zabilježi u njihovim standardnim logovima ali je sasvim dovoljno da ošteti MyISAM tablicu ako je upis bio u tijeku.

Što se servera tiče osobno mi je Netcup bolji od Hetznera pouzdaniji su i jeftiniji. Prije sam koristio njihov “RS 2000 G11” (Root server / VDS) ali sam prešao na dedicated server kod SpectraIP u Nizozemskoj. Ako baš želiš njemačku opciju Netcup je po mom iskustvu bolji od Hetznera.

15

Hvala ti na odgovoru, tako sam i mislio.
Ima iznad 5.6 mysql i tablice su naravno stvorene tako kod instalacije.

Prebacio sam sve uz opsežni backup.

Mene je samo zabolilo kako radiš s firmom preko deset godina i onda ti jednom tako bubnu i to napišu direktno meni i cc klijentu da programer je odgovoran.

Poslije su bile neke u rukavicama kvazi isprike, no niti jednom nije potvrđeno da bi mogla biti greška i s njihove strane, tako da mi se to zgadilo skroz i kuda to ide.