Nápověda:Dokumentace/Server WikiSkript

Z WikiSkript

Aplikační server WikiSkript běží na virtuálním serveru dek-debian-wiki.lf1.cuni.cz na IP adrese 195.113.49.4, databázový server wikiskript na wikidb.lf1.cuni.cz na IP adrese 195.113.49.7 Zrcadlo (které by mělo převzít funkci v případě ztráty konektivity) běží na virtuálním serveru UVT pod názvem wikiskripta-rep.lf1.cuni.cz na IP adrese 195.113.49.5.

  • kontaktní osoba je dr.Čestmír Štuka, stuka(at)cesnet.cz, telefon 2 2496 4102.

HW[upravit | editovat zdroj]

Aplikační server[upravit | editovat zdroj]

Po hardwarové stránce se jedná o virtuální stroj na platformě VMware ESX 4. HD – 150GB, RAM 32 GB, 8xCPU, ETH 1000 Mbitps, VM verze 8

Databázový server[upravit | editovat zdroj]

  • Po hardwarové stránce se jedná o virtuální stroj na platformě VMware ESX 4.
  • HD – 50GB, RAM 20 GB, 8xCPU, ETH 1000 Mbitps, VM verze 8
  • Za virtuální HW odpovídá Ivan Pešek (ipese(at)lf1.cuni.cz), telefon 2 2496 4101.

SW[upravit | editovat zdroj]

Aplikační server[upravit | editovat zdroj]

  • FreeBSD v.12, 64 bit, PHP 7.2, více ZDE.
  • Správcem serveru je ing.Radek Vávra (rvavr(at)lf1.cuni.cz), telefon 2 2496 4316.

Databázový server[upravit | editovat zdroj]

  • FreeBSD v.12, 64 bit, plně aktualizovaný
  • MariaDB 10.3
  • Správcem serveru je ing.Radek Vávra (rvavr(at)lf1.cuni.cz), telefon 2 2496 4316.

Řešení plánovaných odstávek serveru[upravit | editovat zdroj]

Příčinu, proč MySQL v poslední době začalo mít výpadky, zatím neznáme, na problému se pracuje. Víme ale, co je příčinou ztráty několika desítek editací během operace na serveru dne 19.4. Na vině je špatná komunikace. Je nezbytné určit přesný postup při přípravě operací (instalace, zálohování, údržba, hledání chyb …) na serveru, u kterých se předpokládá, že způsobí výpadky či jiné problémy. Návrh:

  • informovat správce o tom, co se bude dít, jak dlouho to potrvá
    • emailem
    • google Wave? Jak nejrychleji vytvořit novou prázdnou vlnu pro všechny správce?
    • editací určité stránky (této?), kterou budou mít zasledovanou všechny osoby, kterých se to týká? To bude možná nejvhodnější.
    • s jakým časovým předstihem je vhodné o tom informovat, ať se k tomu může vyjádřit tým Wikiskript?
  • někdo ze správců by měl s dostatečným (jakým?) předstihem dát info na úvodní stránku Wikiskript
  • před zahájením operace na serveru OVT zakáže všechny editace
  • po ukončení práce budou editace opět povoleny, správci o tom budou informováni dohodnutým způsobem a odstraní info na webu.
  • na tuto stránku OVT (ing. Vávra) doplní, co se dělo
  • po každé operaci na serveru bude vhodné sledovat pozorně chování Wikiskript, zda je opravdu vše v pořádku.

Budeme tímto způsobem ošetřovat všechny plánované výpadky, nebo jen ty, u kterých se předpokládá nedostupnost delší, než určitý časový interval (např. 5 minut)? Někdy je totiž potřeba jen jeden restart.


Jak postupovat při zjištění problému na serveru[upravit | editovat zdroj]

  • informovat správce serveru
  • zapsat zjištěné informace do GoogleWave
  • při nefunkčnosti delší než 5 min rozeslat hromadný mail s upozorněním (přes den)

Přetížení serveru[upravit | editovat zdroj]

Monitoring serveru[upravit | editovat zdroj]

(dostupné jen z vnitřní sítě)

Problémy SQL[upravit | editovat zdroj]

V posledních dvou měsících došlo k opakovaným pádům MySQL serveru. Uvádíme zde přehled výpadků zaznamenaných službou monitoring-serveru.cz (tj. delší než 10min.). (Podrobnější informace o kratších výpadcích by byla v logu SQL serveru, ale kvůli reinstalaci SQL serveru ze staršího – posledního stabilního – snapshotu nejsou snadno dostupné.)

Výpadky SQL serveru[upravit | editovat zdroj]

datum čas chyba doba výpadku
18.3.2010 19:41:24 – 20:11:24 vrací 500 30 minut
26.3.2010 17:01:24 – 17:11:24 nedostupné 10 minut
08.4.2010 09:21:24 – 09:31:24 vrací 500 10 minut
15.4.2010 20:31:24 – 21:41:24 nedostupné 1 hodina 10 minut
16.4.2010 13:01:24 – 13:21:24 nedostupné 20 minut
18.4.2010 09:11:24 – 09:21:24 nedostupné 10 minut
19.4.2010 02:01:24 – 03:11:24 vrací 500 1 hodina 10 minut
20.4.2010 11:41:24 – 11:51:24 vrací 500 10 minut
20.4.2010 12:11:24 – 12:21:24 nedostupné 10 minut
23.8.2010 10:31:24 – 10:51:24 nedostupné 20 minut

Krizové stavy[upravit | editovat zdroj]

Pokud se vyskytne hardwarový nebo softwarový problém s chodem serveru a je nutný zásah technické správy, je nutné před zahájením práce provést následující kroky:

  1. technická správa informuje o nutnosti zásahu MUDr. Vejražku. Ten informuje redaktory o nutnosti zásahu na serveru a zpětně potvrdí technické správě možnost zahájení práce event. sdělí termín možného odstavení serveru.
  2. následně technická správa zakáže editaci ve wikiskriptech, pozastaví MySQL, provede zálohu databáze a poté zahájí servisní práce
  3. po opětovném zprovoznění serveru technická správa oznámí MUDr. Vejražkovi ukončení práce a spuštění serveru

Dosavadní postup řešení[upravit | editovat zdroj]

  1. Po prvních výpadcích SQL serveru byly v logu MySQL nalezeny hlášky o nedostatku swapovacího prostoru.
  2. 14.04.2010 proto bylo zvětšeno nastavení RAM z původní hodnoty 2 GB na 3 GB a zvětšen swap disk serveru na 1 GB.
  3. Po tomto zásahu se v logu hlášení o nedostatku RAM resp. swapu přestala vyskytovat.
  4. Dne 18.04.2010 byl po výpadku SQL objeven v logu problém odkazující na kontrolu BIOSu
  5. Proto byl dne 20.4.2010 proveden návrat ke snapshotu ze dne 22.03.2010, ve kterém se ještě hlášky o problému s BIOSem nevyskytovaly. Návrat k uvedenému snapshotu proběhl mezi 11:30 hod až 12:30 h. Původní obsah databáze byl nahrazen zálohou databáze po odstavení serveru. Při této operaci došlo kvůli nedokonalému uzamčení SQL databáze ke ztrátě části editací provedených mezi 7:47 a 13:40.
  6. Souběžně se však objevil nový problém s MySQL, viz níže uvedený log. Při kontrole logů z 21.04.10 byla tato hláška opět zaznamenána a to v: 7 hod 41 minut, 11 hod 21 minut, 15 hod 29 minut a v 15 hod 35 minut. MySQL server se sám zotavil do 1s a výpadky wikiskript nebyly zaznamenány.
  7. Po 22.03.10 se v lozích uvedené hlášky nevyskytly.
  8. Nelze vyloučit souvislost s instalací OTRS (před 14ti dny). OTRS běží také nad MySQL a tato aplikace byla jediná, která byla v poslední době na server instalována. Budeme sledovat a ověříme to po nové kompletní instalaci MySQL plánované na pátek 30.4.10.

Další navržený postup řešení[upravit | editovat zdroj]

Zdá se, že problém je v SQL databázi. Pokud se nepřijde na jiné řešení, pokusíme se v pátek 30.4.2010 mezi 3:00-7:00 vyexportovat celý obsah databáze, smazat ji a nainstalovat znovu. Protože je však toto opatření náročné na pečlivé provedení a současně si nejsme jisti, že povede k úspěchu, počkáme zda se v „kolektivní inteligenci“ nenajde lepší návrh.

Ukázka logu s chybovým hlášením[upravit | editovat zdroj]

Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: Error: trying to access page number 830973312 in space 0,
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: space name ./ibdata1,
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: which is outside the tablespace bounds.
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: Byte offset 0, len 16384, i/o type 10.
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: If you get this error at mysqld startup, please check that
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: your my.cnf matches the ibdata files that you have in the
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: MySQL server.
Apr 19 09:15:59 localhost mysqld[4872]: 100419 9:15:59InnoDB: Assertion failure in thread 2968030128 in file fil0fil.c line 3959
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: We intentionally generate a memory trap.
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: Submit a detailed bug report to https://bugs.mysql.com/.
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: If you get repeated assertion failures or crashes, even
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: immediately after the mysqld startup, there may be
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: https://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Apr 19 09:15:59 localhost mysqld[4872]: InnoDB: about forcing recovery.
Apr 19 09:15:59 localhost mysqld[4872]: mysqld got signal 11;
Apr 19 09:15:59 localhost mysqld[4872]: This could be because you hit a bug. It is also possible that this binary
Apr 19 09:15:59 localhost mysqld[4872]: or one of the libraries it was linked against is corrupt, improperly built,
Apr 19 09:15:59 localhost mysqld[4872]: or misconfigured. This error can also be caused by malfunctioning hardware.
Apr 19 09:15:59 localhost mysqld[4872]: We will try our best to scrape up some info that will hopefully help diagnose
Apr 19 09:15:59 localhost mysqld[4872]: the problem, but since we have already crashed, something is definitely wrong
Apr 19 09:15:59 localhost mysqld[4872]: and this may fail.
Apr 19 09:15:59 localhost mysqld[4872]:
Apr 19 09:15:59 localhost mysqld[4872]: key_buffer_size=16777216
Apr 19 09:15:59 localhost mysqld[4872]: read_buffer_size=131072
Apr 19 09:15:59 localhost mysqld[4872]: max_used_connections=12
Apr 19 09:15:59 localhost mysqld[4872]: max_connections=100
Apr 19 09:15:59 localhost mysqld[4872]: threads_connected=4
Apr 19 09:15:59 localhost mysqld[4872]: It is possible that mysqld could use up to
Apr 19 09:15:59 localhost mysqld[4872]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
Apr 19 09:15:59 localhost mysqld[4872]: bytes of memory
Apr 19 09:15:59 localhost mysqld[4872]: Hope that's ok; if not, decrease some variables in the equation.
Apr 19 09:15:59 localhost mysqld[4872]:
Apr 19 09:15:59 localhost mysqld[4872]: thd=0xb0d1b3c0
Apr 19 09:15:59 localhost mysqld[4872]: Attempting backtrace. You can use the following information to find out
Apr 19 09:15:59 localhost mysqld[4872]: where mysqld died. If you see no messages after this, something went
Apr 19 09:15:59 localhost mysqld[4872]: terribly wrong…
Apr 19 09:15:59 localhost mysqld[4872]: Cannot determine thread, fp=0xb0e85cc8, backtrace may not be correct.
Apr 19 09:15:59 localhost mysqld[4872]: Stack range sanity check OK, backtrace follows:
Apr 19 09:15:59 localhost mysqld[4872]: 0x81c07a9
Apr 19 09:15:59 localhost mysqld[4872]: 0x83aaaa1
Apr 19 09:15:59 localhost mysqld[4872]: 0x83886e5
Apr 19 09:15:59 localhost mysqld[4872]: 0x8388cf5
Apr 19 09:15:59 localhost mysqld[4872]: 0x837c7a7
Apr 19 09:15:59 localhost mysqld[4872]: 0x83650df
Apr 19 09:15:59 localhost mysqld[4872]: 0x836524a
Apr 19 09:15:59 localhost mysqld[4872]: 0x83666f7
Apr 19 09:15:59 localhost mysqld[4872]: 0x8333915
Apr 19 09:15:59 localhost mysqld[4872]: 0x8327316
Apr 19 09:15:59 localhost mysqld[4872]: 0x832bfc1
Apr 19 09:15:59 localhost mysqld[4872]: 0x827d631
Apr 19 09:15:59 localhost mysqld[4872]: 0x820bb11
Apr 19 09:15:59 localhost mysqld[4872]: 0x8210587
Apr 19 09:15:59 localhost mysqld[4872]: 0x820a72c
Apr 19 09:15:59 localhost mysqld[4872]: 0x8210547
Apr 19 09:15:59 localhost mysqld[4872]: 0x82142b7
Apr 19 09:15:59 localhost mysqld[4872]: 0x822080d
Apr 19 09:15:59 localhost mysqld[4872]: 0x8222530
Apr 19 09:15:59 localhost mysqld[4872]: 0x8222d9e
Apr 19 09:15:59 localhost mysqld[4872]: 0x81d78f8
Apr 19 09:15:59 localhost mysqld[4872]: 0x81dbf07
Apr 19 09:15:59 localhost mysqld[4872]: 0x81dc3c0
Apr 19 09:15:59 localhost mysqld[4872]: 0x81dd698
Apr 19 09:15:59 localhost mysqld[4872]: 0x81de0a4
Apr 19 09:15:59 localhost mysqld[4872]: 0xb7f3c240
Apr 19 09:15:59 localhost mysqld[4872]: 0xb7d7749e
Apr 19 09:15:59 localhost mysqld[4872]: New value of fp=(nil) failed sanity check, terminating stack trace!
Apr 19 09:15:59 localhost mysqld[4872]: Please read https://dev.mysql.com/doc/refman/8.0/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Apr 19 09:15:59 localhost mysqld[4872]: stack trace is much more helpful in diagnosing the problem, so please do
Apr 19 09:15:59 localhost mysqld[4872]: resolve it
Apr 19 09:15:59 localhost mysqld[4872]: Trying to get some variables.
Apr 19 09:15:59 localhost mysqld[4872]: Some pointers may be invalid and cause the dump to abort…
Apr 19 09:15:59 localhost mysqld[4872]: thd->query at 0x8af2408 = SELECT /* ApiQueryRevisions::execute 85.214.135.240 */ rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,page_namespace,page_title,page_latest,old_id,old_text,old_flags FROM `revision`,`page`,`text` WHERE (page_id = rev_page) AND rev_text_id=old_id) AND (page_id=rev_page) AND (page_latest=rev_id) AND page_id IN ('6998','2915','3060','3233','2913','1758') AND rev_page IN ('6998','2915','3060','3233','2913','1758') ORDER BY rev_page, rev_id LIMIT 7
Apr 19 09:15:59 localhost mysqld[4872]: thd->thread_id=10694 Apr 19 09:15:59 localhost mysqld[4872]: The manual page at https://dev.mysql.com/doc/ contains
Apr 19 09:15:59 localhost mysqld[4872]: information that should help you find out what is causing the crash.
Apr 19 09:15:59 localhost mysqld_safe[17296]: Number of processes running now: 0
Apr 19 09:15:59 localhost mysqld_safe[17298]: restarted
Apr 19 09:15:59 localhost mysqld[17301]: 100419 9:15:59 InnoDB: Database was not shut down normally!
Apr 19 09:15:59 localhost mysqld[17301]: InnoDB: Starting crash recovery.
Apr 19 09:15:59 localhost mysqld[17301]: InnoDB: Reading tablespace information from the .ibd files…
Apr 19 09:15:59 localhost mysqld[17301]: InnoDB: Restoring possible half-written data pages from the doublewrite
Apr 19 09:15:59 localhost mysqld[17301]: InnoDB: buffer…
Apr 19 09:15:59 localhost mysqld[17301]: 100419 9:15:59 InnoDB: Starting log scan based on checkpoint at
Apr 19 09:15:59 localhost mysqld[17301]: InnoDB: log sequence number 1 1706781227.
Apr 19 09:15:59 localhost mysqld[17301]: InnoDB: Doing recovery: scanned up to log sequence number 1 1706791778
Apr 19 09:15:59 localhost mysqld[17301]: 100419 9:15:59 InnoDB: Starting an apply batch of log records to the database…
Apr 19 09:16:00 localhost mysqld[17301]: InnoDB: Progress in percents: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Apr 19 09:16:00 localhost mysqld[17301]: InnoDB: Apply batch completed
Apr 19 09:16:00 localhost mysqld[17301]: InnoDB: Last MySQL binlog file position 0 983464, file name /var/log/mysql/mysql-bin.001206
Apr 19 09:16:00 localhost mysqld[17301]: 100419 9:16:00 InnoDB: Started; log sequence number 1 1706791778
Apr 19 09:16:00 localhost mysqld[17301]: 100419 9:16:00 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
Apr 19 09:16:00 localhost mysqld[17301]: 100419 9:16:00 [Note] Starting crash recovery…
Apr 19 09:16:00 localhost mysqld[17301]: 100419 9:16:00 [Note] Crash recovery finished.
Apr 19 09:16:00 localhost mysqld[17301]: 100419 9:16:00 [Note] /usr/sbin/mysqld: ready for connections.
Apr 19 09:16:00 localhost mysqld[17301]: Version: '5.0.32-Debian_7etch12-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Debian etch distribution

Instalovaná rozšíření[upravit | editovat zdroj]

Pro úplnost uveďme seznam instalovaných extension, která mohou rovněž ovlivňovat chod SQL serveru. Jejich seznam je zde:

Zde prosím vkládejte Vaše komentáře a návrhy. Dík![upravit | editovat zdroj]

Pavel.dusek(at)googlewave.com:[upravit | editovat zdroj]

Přeposílal jsem informaci bráškovi (matfyzák v páťáku na informatice) jestli náhodou netuší, proč to padá. Sice prý nikdy SQL server nespravoval a není si jistý, zdali rozumí všemu, ale odpověděl mi:

„To vypadá na bug v samotném MySQL serveru, takže byste ho asi měli nahlásit a nic víc dělat nemůžete. Aspoň podle mě a podle toho co jsem přečet z toho logu…“
„PS. Ještě něco dělat můžete – zálohovat zálohovat zálohovat.“
Podle všeho jsem pochopil, že zálohujeme, alespoň v rámci možností. A nevím, jestli má smysl posílat bug report…

Antonin.sipek(at)googlewave.com:[upravit | editovat zdroj]

Přeposlal jsem spolužákovi z gymplu, co končí elektrotechniku a s MySQL dlouho dělá. Něco mi sepsal:

„Každopádně bych vřele doporučoval postupovat podle toho návodu, co vám to hodilo do logu. Zejména věnovat zvýšenou pozornost tomuhle: https://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html “
„Vsadil bych kalhoty na to, že těmi hrátkami se snapshoty a obnovování ze zálohy tam někdo zanesl nekonzistentní tabulku/tabulky. Taky bych vám doporučil zjistit, jak přesně se provádí ty zálohy, pokud se po obnově z nich dějí takovéhle věci, je tam asi něco shnilého. Bug v MySQL bych spíš vyloučil. Takové hlášky se do logu dávají vždycky. Používáte jednu z nejtypičtějších konfigurací vůbec a provozujete na ní jednu z nejpoužívanějších aplikací ☺ Že by to byl nějaký úplně nový zásadní bug se mi zdá dost nepravděpodobné.“
„Moc se mi nezdají ani ty předchozí výpadky. Nevím, jakou mají wiki skripta návštěvnost, ale 2GB mi připadá zatím až dost, tak nechápu, proč to swapuje. Jaká je velikost celé databáze?“
„Tam jak píšou, že tam byla chyba 500, to je informace k ničemu – je potřeba se kouknout do logů apache a mysql a syslogu, co se tam tou dobou dělo.“

Lubos Dolezal, VFN[upravit | editovat zdroj]

Snad jen par poznamek:

  • K nasazenemu storage engine v mysql:
    • Ad1) je duvod pouzit InnoDB v MySQL? Pokud ne, konvertovat tabulky na MyISAM,
    • Ad2) pokud je to nutne triggery etc. zkontrolovat konzistenci.
  • Je treba mit aktivni vytvareni bin log? Pokud se neprovadi replikace, tak bych se zkusil vypnout (nejenom samotny „log_bin“, ale take „expire_logs_days“, „max_binlog_size “).
  • Dále bych vyzkousel prechod na stable Debian (Lenny), jestli se budou popisovane problemy vyskytovat i na distribucni 5.0.51a. Podpora pro Etch skoncila 15.2.2010.
  • Take bych asi zkusil vymenit stavajici my.cnf za distribucni default.
  • Jinak, bylo by asi dobre uvest jeste log apache z doby, kdy se vyskytnou problemy s db.

S pozdravem, Lubos Dolezal Odd. spravy informacnich systemu Vseobecna fakultni nemocnice v Praze

Petr Kadlec / Mormegil / Wikipedia[upravit | editovat zdroj]

Nejsem odborník na MySQL (či snad dokonce Linux), takže jen takové spíš nápady:

  • Souhlasil bych, že to vypadá na poškození tabulek.
  • Zkontroloval bych, jestli někdo neměnil konfigurační soubor MySQL (my.cnf)
  • jisté podezření bych měl i na to, jestli tam není nějaký HW problém (poškozený disk apod.).
  • Nevím, jak velkou databázi tam máte, pokud není nějak moc velká, možná bych zkusil dump do SQL a opětovné načtení, aby se vyloučila možnost nějakého jejího drobného zákeřného poškození;
  • jinak pochopitelně provést kontrolu konzistence.

Co se týká toho uvedeného logu, chápu dobře, že se ty problémy vyskytnou „náhodně“ v průběhu běžné činnosti, nikoli při spouštění databáze apod.?

Systém na kterém jede Wikipedia

A mimochodem – opravdu bych doporučoval sledovat mailing list https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce a instalovat aktualizace; aktuální verzí totiž je 1.15.3, která oproti vámi používané 1.15.1 opravuje (mimo jiné) dvě bezpečnostní chyby.

Odstávky a výpadky serveru[upravit | editovat zdroj]

30.04.2010[upravit | editovat zdroj]

Dne 30.04.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a reinstalace databáze. Bylo provedeno následující:

  1. restart serveru a kontrola nabíhání a logů po jeho znovuspuštění – vše ok, logy prosté chybových hlášení
  2. kontrola spouštění služeb při startu serveru – ok
  3. vyexportování databáze – ok
  4. reinstalace serveru mysql -ok
  5. naimportování databáze – ok
  6. kontrola činnosti db – ok
  7. kontrola koexistence dat v db – ok

Server byl spuštěn těsně před 5 hodinou po kontrole obsahu ing. Martiňákem.

20.05.2010[upravit | editovat zdroj]

Dne 20.05.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. preventivní kontrola chodu serveru – ok
  2. kontrola db, kontrola struktury tabulek – ok
  3. aktualizace OS serveru – ok
  4. odzkoušení nového scriptu pro start spadlé mysql – ok
  5. nastavení wikiskript jako MASTER replikačního serveru – ok
  6. nastavení wiki-rep jako SLAVE replikačního serveru – ok
  7. konfigurace, spuštění a ověření replikace mezi výše uvedenými servery – ok

Server byl uveden do standarního provozu krátce před 7 hodinnou po kontrole funkčnosti ing. Martiňákem.

04.06.2010[upravit | editovat zdroj]

Dne 04.06.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. aktualizace OS na wiki a wiki-rep – ok
  2. kontrola běhu serverů wiki a wiki-rep – ok
  3. kontrola konzistence tabulek na wiki a wiki-rep -ok
  4. wiki-rep byla nakonfigurována tak, že je vidět z internetu – ok
  5. nastavení replikací databází wikien a mysql – ok
  6. vzdálená synchronizace adresářů images na serverech wiki a wiki-rep jak u wiki tak i wikien, synchronizuji každou minutu pomocí rsync – ok

Server byl uveden do standarního provozu v cca 6 30 hod. po kontrole funkčnosti ing. Martiňákem.

23.07.2010[upravit | editovat zdroj]

Dne 23.07.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. aktualizace OS serveru na – ok
  2. restart serveru, kontrola startu – ok
  3. aktualizace vmwares tools – ok
  4. kontrola db, kontola struktury tabulek – ok
  5. reset a kontrola replikace – ok
  6. sjednocení ACL práv na apachi s ostaními wiki servery – ok

Server byl po provedení výše uvedených prací odemknut v cca 6 45 hod.

06.08.2010[upravit | editovat zdroj]

Dne 06.08.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. restart serveru, kontrola startu – ok
  2. kontrola db, kontola struktury tabulek – ok
  3. reset a kontrola replikace – ok
  4. sejmutí image wiki-rep

Server byl po provedení výše uvedených prací odemknut v cca 6 30 hod.

Výpadek 23.08.2010[upravit | editovat zdroj]

Dne 23.08.10 v 10:31 došlo k výpadku serveru WikiSkript na dobu cca 20 min. Šlo o výpadek způsobený výpadkem virtuálních serverů po krátkodobém výpadku konektivity v lokalitě U nemocnice 5, serverovna DR81.

Přijatá opatření:

  1. urychleně zprovoznit virtuální cluster s RUK (Vávra, Horák)
  2. převést klíčové sedevery na režim třícestné replikace, aby nebyly ohroženy lokálními výpadky konektivity (Pešek)
  3. zprovoznit samostatné sítové zokruhování prvků virtualizačního clusteru pomocí switchů Telesyn, které bude současným zokruhováním přes Cisco switche zálohované (Veselý, Pešek)

Upgrade 10.09.2010[upravit | editovat zdroj]

Dne 10.09.2010 došlo v době od 03:00 do 08:00 k upgradu softwaru MediaWiki na verzi 1.16 na českých i anglických WikiSkriptech a jejich replikačních serverech.

3.12.2010[upravit | editovat zdroj]

Dne 3.12.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. aktualizace jádra linuxu na wiki, wiki-rep a WikiSkripta-rep – ok
  2. kontrola běhu serverů wiki, wiki-rep, WikiSkripta-rep – ok
  3. kontrola konzistence tabulek na wiki, wiki-rep a WikiSkripta-rep – ok
  4. změna časové synchronizace na wiki (oproti hostujícímu serveru) – ok
  5. nastavení apache pro phpmyadmin – povolen přístup z vnitřní sítě 1. LF UK a z PC dek-jmarti.lf1.cuni.cz z jeho veřejné IP – ok
  6. kontrola činnosti UCARP – ok

Server byl uveden do standarního provozu v cca 6 55 hod. po kontrole funkčnosti ing. Martiňákem.

23.12.2010[upravit | editovat zdroj]

Dne 23.12.10 byla provedena plánovaná odstávka serveru od 3-7 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. kontrola běhu hlavního serveru - ok
  2. kontrola db, kontrola konzistence tabulek - ok
  3. dokončení upgrade serveru wikiskripta-rep.lf1.cuni.cz z etch na lenny včetně upgrade vm tools - nutno dohledovat a dořešit - replikaci, rsync, ucarp
  4. se změnou verze linuxu přestal fungovat např. rsync (zřejmě kolize verzí rsync klienta a rsync serveru)
  5. replikační server wiki-rep.lf1.cuni.cz jede bez problémů

Server byl uveden do standarního provozu v cca 6 55 hod.

29.12.2010[upravit | editovat zdroj]

Dne 29.12.10 bylo v průběhu pracovní doby dořešeno:

  1. replikace db z wikiskript na wikiskripta-rep.lf1.cuni.cz - ok
  2. rsync z wikiskript na wikiskripta-rep.lf1.cuni.cz - ok
  3. ucarp mezi wikiskripty a wikiskripta-rep.lf1.cuni.cz - ok

14.01.2011[upravit | editovat zdroj]

Dne 14.01.2011 byla provedena plánovaná odstávka serveru od 8-11 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. kontrola běhu hlavního serveru - ok
  2. kontrola db, kontrola konzistence tabulek - ok
  3. synchronizace db mezi replikacemi
  4. kontrola replikací mezi servery - ok
  5. UCARP - synchronizace a provedeno několik následných testů - ok

Server byl uveden do standarního provozu v cca 10 50 hod.

25.01.2011[upravit | editovat zdroj]

Dne 25.01.2011 byl navýšen počet procesorů o dva. Celkem wikiskripta.eu jedou na 4 procesorech.

27.01.2011[upravit | editovat zdroj]

Dne 27.01.2011 byl proveden upgrade OS debian z verze 4 (etch) na verzi 5 (lenny).

28.04.2011[upravit | editovat zdroj]

Dne 28.04.2011 byla provedena aktualizace OS serveru.

20.10.2011[upravit | editovat zdroj]

Bylo provedeno následující:

  1. synchronizace db mezi hlavním serverem a replikačními servery
  2. kontrola konziestence db
  3. aktualizace linuxu
  4. aktualizace vmwares tools
  5. restart serverů

Odstávka byla plánována od 8 do 12 hodin. Server byl puštěn do běžného provozu v 11 hodin. Při kontrole serveru jsem nenarazil na žádné chyby.

17-18.3.2012[upravit | editovat zdroj]

O víkendu 17-18.3 2012 došlo k upgrade původního serveru wikiskript s OS Debian 5 32bit na OS Debian 6 64 bit. Došlo také k upgradu aplikací wikiskript. Při této příležitosti jsme stejným způsobem upgradovali server wiki-rep.lf1.cuni.cz. Server wikiskripta-rep.lf1.cuni.cz je stále ve stejném stavu a nebyl na něm proveden žádný upgrade.

Od pondělí 19.3.2012 jsme řešili problémy s replikací, emailováním apod.

Stav po upgrade:

  • www.wikiskripta fungují bez problémů a dochází k replikaci db a synchronizaci příslušných datových souborů na wiki-rep.lf1.cuni.cz
  • o víkendu došlo též k testu UCARPu proti wikiskripta-rep.lf1.cuni.cz a v případě výpadku hlavního serveru rektorátní převzal jeho funkci (pokud by došlo k výpadku, uvidíte tedy původní wikiskripta)
  • na wikiskripta-rep.lf1.cuni.cz nedochází k replikaci a synchronizaci. Zvážíme, zda-li bychom neponechali původní Debian 5 a nepřeinstalovali db a aplikace nebo přeinstalujeme server včetně OS. Poté bych nastavil replikaci i synchronizaci též na tento server.
  • z nových wikiskript se nám nepodařilo rozchodit tisk pdf dokumentů na webservices.lf1.cuni.cz (mw-qserve), byl tedy nasměrován na původní wikis.lf1.cuni.cz (mw-serve), pokud byste chtěli využívat nového serveru, pro tisk pdf dokumentů používejte tedy wiki-rep.lf1.cuni.cz, který je na webservices.lf1.cuni.cz nasměrován

2.4.2012[upravit | editovat zdroj]

Navýšení původní RAM 4 GB na 6 GB.

11.4.2012[upravit | editovat zdroj]

  • Spuštění replikace a synchronizace na rektorátní server wikiskripta-rep.lf1.cuni.cz. V případě výpadku hlavního serveru se zobrazuje již aktuální verze wikiskript.

24.05.2012[upravit | editovat zdroj]

Dne 24.05.2012 byla provedena plánovaná odstávka serveru od 8-12 hodin z důvodu kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. kontrola běhu hlavního serveru - ok
  2. kontrola db, kontrola konzistence tabulek - ok
  3. kontrola replikací mezi servery - ok
  4. UCARP - provedeno několik následných testů - ok
  5. aktualizace linuxu včetně kernelu - ok

01.11.2012[upravit | editovat zdroj]

Dne 01.11.2012 byla provedena plánovaná odstávka serveru od 8-10 hodin z důvodu aktualizace linuxu, kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. restart serveru, kontrola nastartování - ok
  2. kontrola HD - ok
  3. kontrola db, kontrola konzistence tabulek - ok
  4. kontrola replikací mezi servery - ok
  5. UCARP - proveden jeden test při shutdown - ok
  6. aktualizace linuxu včetně kernelu - ok

18.01.2013[upravit | editovat zdroj]

Dne 18.01.2013 byla provedena plánovaná odstávka serveru od 8-12 hodin z důvodu aktualizace aplikace WS na 1.19, aktualizace linuxu, kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. instalace wiki verze 1.19 - ok
  2. kontrola aplikací - ok
  3. restart serveru, kontrola nastartování - ok
  4. kontrola replikací mezi servery - ok
  5. UCARP - proveden jeden test při shutdown - ok
  6. aktualizace linuxu - ok

21.03.2013[upravit | editovat zdroj]

Dne 21.03.2013 byla provedena plánovaná odstávka serveru od 8-10 hodin z důvodu aktualizace aktualizace linuxu, kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. restart serveru, kontrola nastartování - ok
  2. kontrola replikací mezi servery - ok
  3. UCARP - provedeny testy při shutdown - ok
  4. aktualizace linuxu včetně kernelu - ok
  5. aktualizace vmwares tools
  6. test konzistence tabulek db - ok
  7. test disku - ok

10.10.2013[upravit | editovat zdroj]

Dne 10.10.2013 byla provedena plánovaná odstávka serveru od 8 30 - 11 hodin z důvodu aktualizace aktualizace linuxu, kontroly činnosti serveru a databáze. Bylo provedeno následující:

  1. restart serveru, kontrola nastartování - ok
  2. UCARP - provedeny testy při shutdown - ok
  3. aktualizace linuxu včetně kernelu - ok
  4. aktualizace vmwares tools
  5. test konzistence tabulek db - ok
  6. test disku - ok

23.01.2014[upravit | editovat zdroj]

Dne 23.01.2014 byla provedena plánovaná odstávka serveru od 8 30 - 11 hodin z důvodu aktualizace linuxu, kontroly činnosti serveru a databáze a navýšení RAM. Bylo provedeno následující:

  1. restart serveru, kontrola nastartování - ok
  2. navýšení RAM o 2 GB, tedy z 6 GB na 8 GB - ok
  3. UCARP - provedeny testy při shutdown - ok
  4. aktualizace linuxu - ok
  5. aktualizace vmwares tools
  6. test konzistence tabulek db - ok
  7. test mysql - ok
  8. test disku - ok

15.04.2014[upravit | editovat zdroj]

Dne 15.04.2014 byla provedena plánovaná odstávka serveru od 8 30 - 11 hodin z důvodu upgrade hardware serveru a odstranění poškození disku (chybné oblasti). Bylo provedeno následující:

  1. restart serveru, kontrola nastartování
  2. navýšení RAM o 4 GB, tedy z 8 GB na 12 GB
  3. navýšení CPU o 4 ks, tedy na 8 CPU celkem
  4. instalace dalšího virtuálního disku o kapacitě 50 GB
  5. oprava poškozeného disku - ok
  6. test HD - ok

8.7.2014[upravit | editovat zdroj]

Dne 8.7.2014 byla provedena plánovaná odstávka serveru od 8 30 - 9 hodin z důvodu navýšení RAM a kontroly serveru: Bylo provedeno následující:

  1. restart serveru, kontrola nastartování - ok
  2. test UCARP - ok
  3. navýšení RAM o 8 GB, tedy z 12 GB na 20 GB - ok
  4. kontrola konzistence db - ok
  5. aktualizace linuxu - ok

12.8.2014[upravit | editovat zdroj]

Dne 12.8.2014 byla provedena plánovaná odstávka serveru od 8 30 - 11 hodin z důvodu opravy replikací a kontroly serveru: Bylo provedeno následující:

  1. restart serveru, kontrola nastartování - ok
  2. test UCARP - ok
  3. oprava replikací
  4. kontrola konzistence db - ok
  5. aktualizace linuxu - ok

8.10.2014

Dne 8.10.2014 byla provedena plánovaná odstávka serveru od 8 30 - 12 hodin. Bylo provedeno následující:

  1. Instalace nového db serveru na wikidb.lf1.cuni.cz a provedení s tím souvisejících prací (replikace)

Pozn.: Narazili jsme na problémy, které jsme neočekávali. Dobu odstavení jsme překročili asi o 2-3 hodiny. Server byl odemknut a puštěn do běžného provozu ve 14 30 hod.

24.10.2014

Dne 24.10.2014 byla provedena plánovaná odstávka serveru od 8 30 - 10 hodin za účelem nastavení replikace.

5.3.2015

Dne 5.3.2015 bylo navýšeno instalované množství RAM z 20 GB na 32 GB jako předpoklad nadcházející instalace SQUIDU.

8.4.2015

Plánovaná odstávka od 8 30 hod do 12 hod.

1. Kontrola funkčnosti serveru - ok

2. Kontrola nastavení syn flood po restartu serveru - ok

3. Kontrola UCARP - nutno dokonfigurovat

4. Instalace SQUIDu, konfugurace a nastavení základních domén - ok

2.12.2015

Plánovaná odstávka od 8 30 hod do 12 hod.

1. Aktualizace OS na obou serverech - ok

2. Kontrola startu serveů - ok

3. Kontrola UCARPu - ok

4. Kontrola konzistence db struktur - ok

5. Kontrola diskových oblastí - ok

31.7.2017

Celodenní odstávka

1. Výměna aplikačního serveru - ok

2. Aktualizace db serveru - ok

6.3.2019

Plánovaná odstávka od 8 do 12 hod.

1. Aktualizace aplikačního serveru - ok

2. Aktualizace db serveru - ok

3. Test UCARP - ok

4. Je třeba dořešit problémy s certifikáty po přepnutí na wikiskripta-rep.lf1.cuni.cz.

22.5.2019

Plánovaná celodenní odstávka.

1. Výměna databázového serveru - přecházíme na FreeBSD v. 12 64 bit a z mysql na mariadb

2. Výměna aplikačního serveru - přecházíme na FreeBsd v. 12 64 bit s php 7.2

3. Přechod na Mediawiki 1.32

Citováno z „https://www.wikiskripta.eu/index.php?title=Nápověda:Dokumentace/Server_WikiSkript&oldid=427435“