Ztrácení obsahu databázových tabulek na Webzdarma
Zdravím.
Rok co rok se opakovaně setkávám se ztrácením obsahu z určitých databázových tabulek. Chtěl bych se dopátrat příčiny toho, proč se v databázi `elektrostraka` ztrácejí obsahy tabulek `Navstevy`, `Odkud`, `Prohlizec`, `IP`.
K poslední ztrátě těchto obsahu čtyř tabulek došlo mezi '2011-02-21 21:43:17' a '2011-02-21 22:01:42'. Od techto časů databáze vypadala jako po TRUNCATE všech těchto 4 tabulek a všechny autoincrement primární klíče `ID` záznamů jsou číslovány znovu od 1. Při prohlédnutí SHOW TABLE STATUS je u každé z tabulek jiný čas `Create_time` z výše zmíněného rozmezí devatenácti minut.
Skripty na elektrostraka.webzdarma.cz neobsahují žádné DROP TABLE ani TRUNCATE.
(Kromě toho se ve skriptech provádí při každém zjištění chybového hlášení MySQL test přítomnosti databázových tabulek, jehož výsledek se ukládá do logovacího souboru. V logovacím souboru se však nenachází žádná informace o chybějících tabulkách, pouze údaje o občasném výpadku spojení MySQL během dotazu.)
Většinu ztracených záznamů dokážu obnovit ze své poslední zálohy, nicméně bych potřeboval zajistit neztrácení žádných záznamů. Zatím do vyřešení ponechávám tabulky neobnoveny v původním stavu.
Předem děkuji za pomoc
Rok co rok se opakovaně setkávám se ztrácením obsahu z určitých databázových tabulek. Chtěl bych se dopátrat příčiny toho, proč se v databázi `elektrostraka` ztrácejí obsahy tabulek `Navstevy`, `Odkud`, `Prohlizec`, `IP`.
K poslední ztrátě těchto obsahu čtyř tabulek došlo mezi '2011-02-21 21:43:17' a '2011-02-21 22:01:42'. Od techto časů databáze vypadala jako po TRUNCATE všech těchto 4 tabulek a všechny autoincrement primární klíče `ID` záznamů jsou číslovány znovu od 1. Při prohlédnutí SHOW TABLE STATUS je u každé z tabulek jiný čas `Create_time` z výše zmíněného rozmezí devatenácti minut.
Skripty na elektrostraka.webzdarma.cz neobsahují žádné DROP TABLE ani TRUNCATE.
(Kromě toho se ve skriptech provádí při každém zjištění chybového hlášení MySQL test přítomnosti databázových tabulek, jehož výsledek se ukládá do logovacího souboru. V logovacím souboru se však nenachází žádná informace o chybějících tabulkách, pouze údaje o občasném výpadku spojení MySQL během dotazu.)
Většinu ztracených záznamů dokážu obnovit ze své poslední zálohy, nicméně bych potřeboval zajistit neztrácení žádných záznamů. Zatím do vyřešení ponechávám tabulky neobnoveny v původním stavu.
Předem děkuji za pomoc
"Kdosi se 31.1.2007 pokusil ukrást stračí poklady. Vypadalo to takhle.
Gratuluji! Dobrá práce! Může to teď zkusit znovu :) "
Třeba tě někdo poslechl a zkusil to znovu.
Gratuluji! Dobrá práce! Může to teď zkusit znovu :) "
Třeba tě někdo poslechl a zkusil to znovu.
Mohou být dva způsoby, jak neoprávněně odstranit tabulky.
- Někdo zjistil přístupové údaje k databázi.
Tím se pak mohl dostat do phpmyadmin a provést patřičné operace.
Jelikož však odstranil jen něco, pak bych se více přikláněl k druhé variantě, protože když měl plný přístup, tak je mi nelogické, proč mazat jen něco, když mohu všechny.
- Ve skriptech je bezpečnostní díra v podobě SQL injection
Pomoci neošetřeného vstupu může dodatečně vložit vlastní SQL kód. A odkud by získal názvy tabulek? Ono stačí jen hádat nebo vyvolat SQL chybu, kde se vypíše, jaké tabulky se používají.
- Někdo zjistil přístupové údaje k databázi.
Tím se pak mohl dostat do phpmyadmin a provést patřičné operace.
Jelikož však odstranil jen něco, pak bych se více přikláněl k druhé variantě, protože když měl plný přístup, tak je mi nelogické, proč mazat jen něco, když mohu všechny.
- Ve skriptech je bezpečnostní díra v podobě SQL injection
Pomoci neošetřeného vstupu může dodatečně vložit vlastní SQL kód. A odkud by získal názvy tabulek? Ono stačí jen hádat nebo vyvolat SQL chybu, kde se vypíše, jaké tabulky se používají.
<HTML>Dobry den,
tabulky boli zmazane kvoli nadmernej zatazi databazy. Pricinou moze byt velky pocet zaznamov, prekrocenie poskytovanej velkost databazy 20MB a/alebo nevhodne dotazy v kombinacii s chybajucimi indexami.
Zvazte ci potrebujete mat v databaze informacie v rozsahu
`IP`, `Kdy`, `Stranka`, `Odkud`, `Prohlizec`, `Method`
pre kazdy jeden http request (za dva tyzdne je tam cca 40k zaznamov).
Nestacili by vam napriklad Google Analytics?</HTML>
tabulky boli zmazane kvoli nadmernej zatazi databazy. Pricinou moze byt velky pocet zaznamov, prekrocenie poskytovanej velkost databazy 20MB a/alebo nevhodne dotazy v kombinacii s chybajucimi indexami.
Zvazte ci potrebujete mat v databaze informacie v rozsahu
`IP`, `Kdy`, `Stranka`, `Odkud`, `Prohlizec`, `Method`
pre kazdy jeden http request (za dva tyzdne je tam cca 40k zaznamov).
Nestacili by vam napriklad Google Analytics?</HTML>
Wide> Děkuji za zodpovězení.
Nicméně nerozumím tomu proč byly smazány 4 tabulky, když velikostně nemohly všecky přesáhnout 20MB. To si je někdo jen tak ručně náhodně zvolí a smaže? Potíž je totiž v tom, že já se vůbec nedozvím, že přesáhly 20MB? když ještě než se stačím podívat, jsou smazané.
Nicméně nerozumím tomu proč byly smazány 4 tabulky, když velikostně nemohly všecky přesáhnout 20MB. To si je někdo jen tak ručně náhodně zvolí a smaže? Potíž je totiž v tom, že já se vůbec nedozvím, že přesáhly 20MB? když ještě než se stačím podívat, jsou smazané.
Zřejmě proto, že logování přístupu uživatelů není zrovna ideální pro použití databáze - existují na to vhodnější techniky, které jsou šetrnější k prostředkům.
Např.? Jako třeba zápis do souboru, u kterého se vůbec nedá ošetřit multivláknový přístup? Nebo jako třeba cookies, který se vůbec neukládá na serveru a u kterého nelze provést statistiku? Nebo jako např. když si to uložím na svém serveru doma v MySQL, kde mám omezení 160GB?
Kit měl možná na mysli přímý access log od Apache, kde se tyto údaje ukládají. Takže je ta tabulka pak zbytečná.
Pokud však přístup k access logu nemáš, pak je stejně databáze tou lepší volbou. Ovšem tam se pak musí provést šetrnější volba. Jak psal wide, pokud do tabulky zapisuješ každý request, pak se to dá považovat za plýtvání. Nejlepší je použít dvojitý zápis. Jeden záznam pro jeden počítač, kam vložíš třeba IP, prohlížeč a případně další, a tento záznam ošetříš cookie nebo kontrolou dostupnosti. A druhý záznam by pak byl na stránky, kam uložíš jen datum a stránku spolu s identifikátorem na hlavní záznam.
Vylepšením by pak bylo reportování. Třeba každý týden se provede report, kdy se zpracuji data a ty se uloží do souboru a zpracovaná data se pak mohou z databáze odstranit. Ušetří se místo v databázi a historii budeš mít v souboru, ze kterého budeš jen číst.
Pokud však přístup k access logu nemáš, pak je stejně databáze tou lepší volbou. Ovšem tam se pak musí provést šetrnější volba. Jak psal wide, pokud do tabulky zapisuješ každý request, pak se to dá považovat za plýtvání. Nejlepší je použít dvojitý zápis. Jeden záznam pro jeden počítač, kam vložíš třeba IP, prohlížeč a případně další, a tento záznam ošetříš cookie nebo kontrolou dostupnosti. A druhý záznam by pak byl na stránky, kam uložíš jen datum a stránku spolu s identifikátorem na hlavní záznam.
Vylepšením by pak bylo reportování. Třeba každý týden se provede report, kdy se zpracuji data a ty se uloží do souboru a zpracovaná data se pak mohou z databáze odstranit. Ušetří se místo v databázi a historii budeš mít v souboru, ze kterého budeš jen číst.
Zápis řetězce do souboru je bez problémů do 8 KB. Potíže nastanou teprve pokud chceš zapsat delší. Na logy plně vyhovující.
Tomík> Tak nějak mi databáze návštěvnosti: 1 tabulka udržuje IP adresy jako unikátní klíč, u ní se pak ukládají některé informace patřící ke konkrétnímu uživateli. Ve druhé tabulce se potom ukládá datum a čas, IP adresa uživatele, ID stránky, ID prohlížeče a pár dalších prostorově nevýznamných údajů.
Překvapilo mě však, že počet různých prohlížečů se velmi blíží počtu různých IP adres. Prohlížečů prostě existuje tolik variant, že citelně zaplnily jednu tabulku. Ta největší tabulka však stále je ta, která obsahuje pouze časy a ID.
Asi to teda vypadá, že budu muset vytvořit pravidelně spouštěnou automatickou archivaci do vzdálené databáze. Pro archivovaná data pak vytvořím novou, mnohem menší tabulku, ve které budou jen agregované informace, které se už v živé databázi nebudou nacházet, tj. hlavně počty IP adres. To zatím vidím jako jediný způsob, který by víceméně zachoval funkci a vyřešil vzniklý problém.
Dík za rady.
Překvapilo mě však, že počet různých prohlížečů se velmi blíží počtu různých IP adres. Prohlížečů prostě existuje tolik variant, že citelně zaplnily jednu tabulku. Ta největší tabulka však stále je ta, která obsahuje pouze časy a ID.
Asi to teda vypadá, že budu muset vytvořit pravidelně spouštěnou automatickou archivaci do vzdálené databáze. Pro archivovaná data pak vytvořím novou, mnohem menší tabulku, ve které budou jen agregované informace, které se už v živé databázi nebudou nacházet, tj. hlavně počty IP adres. To zatím vidím jako jediný způsob, který by víceméně zachoval funkci a vyřešil vzniklý problém.
Dík za rady.
Možná je to takový vtíravý dotaz, ale potřebuješ ty data vůbec ukládat?
Nestačilo by ti použít "obyčejné" Google Analytics, kde máš už hotové všechny výstupy do grafů atp.?
Pokud ne, máš pravdu, že budeš muset zapracovat na pravidelné archivaci. A dodělat bys ji měl i v případě, že by na webzdarma omezení na velikosti tabulek nebylo -- s rostoucími tabulkami by se tvůj web akorát stával pomalejším.. (Jestli ta archivace bude do souboru nebo databáze někde mimo webzdarma je až další otázka..)
Nestačilo by ti použít "obyčejné" Google Analytics, kde máš už hotové všechny výstupy do grafů atp.?
Pokud ne, máš pravdu, že budeš muset zapracovat na pravidelné archivaci. A dodělat bys ji měl i v případě, že by na webzdarma omezení na velikosti tabulek nebylo -- s rostoucími tabulkami by se tvůj web akorát stával pomalejším.. (Jestli ta archivace bude do souboru nebo databáze někde mimo webzdarma je až další otázka..)
Freeze: Pokud se s rostoucími tabulkami zpomaluje web, je na aplikaci něco špatně a je nutné ji předělat.
Nové příspěvky
Žádosti o obnovení odstavených domén
sspklimky.wz.cz - smazání
Detailní návod na připojení přes Total Commander
nefukční HTTPS s balíčkem základ
SPF a DKIM záznam
FTP server
Propojení PHP a MySQL
Přenos domény
Obnova webu
pomalá odezva webu
Obnovení webu
Tarif zdarma definitivně nepoužitelný kvůli HTTP/HTTPS - druhá část
Dotaz na bod podmínek "využívat poskytnutý prostor jako uložiště pro soubory, zejména pokud k nim nevede odkaz ze stránek a odkazovat se na ně z jiného serveru;
Překročení datového limitu
prosím můj účet přesunout na nejnovější server kvůli automatická instalaci Wordpressu
Nechodí mi email na obnovu hesla
nový web a hostíng
zrušení přesměrování
HTTP
obrazy.unas.cz
DNSSEC u přesunuté domény
Načítací kolečko při nové objednávce domény
Nefunguje domena s WWW
502 bad gateway
Přechod ze zadarmové domény na placenou
Další témata
STATUS
FTP
HTTP
SQL
PHP
© 2002 - 2024 Web zdarma s.r.o. — zvládnete to sami