Nápověda:Dokumentace/Server WikiSkript: Porovnání verzí

Z WikiSkript
Vizuální
m (+kat)
Řádek 5: Řádek 5:
== HW ==
== HW ==
Po hardwarové stránce se jedná o virtuální stroj na platformě VMware ESX 4.
Po hardwarové stránce se jedná o virtuální stroj na platformě VMware ESX 4.
HD – 50GB, RAM 6 GB, 4xCPU, ETH 1000 Mbitps, VM verze 8
HD – 50GB, RAM 8 GB, 4xCPU, ETH 1000 Mbitps, VM verze 8
*Za virtuální HW odpovídá Ivan Pešek (ipese(at)lf1.cuni.cz), telefon 2 2496 4101.
*Za virtuální HW odpovídá Ivan Pešek (ipese(at)lf1.cuni.cz), telefon 2 2496 4101.


Verze z 23. 1. 2014, 10:59

Server WikiSkript běží na virtuálním serveru dek-debian-wiki.lf1.cuni.cz na IP adrese 195.113.49.4. Jeho 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

Po hardwarové stránce se jedná o virtuální stroj na platformě VMware ESX 4. HD – 50GB, RAM 8 GB, 4xCPU, 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

Softwarově se jedná o
  • OS – Debian v. 6.0 sqeeze, 64 bit, plně aktualizovaný
  • SQL – MySQL server v. 5.1.63
  • PHP – PHP v. 5.3.3-7
  • WIKI – MediaWiki v. 1.16.0
  • 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

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

  • 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

Monitoring serveru

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

Problémy SQL

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

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

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í

  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í

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

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 http://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: http://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 http://dev.mysql.com/doc/mysql/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 http://www.mysql.com/doc/en/Crashing.html 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í

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!

Pavel.dusek(at)googlewave.com:

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:

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: http://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

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

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

30.04.2010

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

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

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

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

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

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

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

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

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

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

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

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

27.01.2011

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

28.04.2011

Dne 28.04.2011 byla provedena aktualizace OS serveru.

20.10.2011

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

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

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

11.4.2012

  • 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

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

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

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

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

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
Citováno z „https://www.wikiskripta.eu/index.php?title=Nápověda:Dokumentace/Server_WikiSkript&oldid=249485“