Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)Lepší info viz dole v threadu : #16
Řešení dotazu:
ps auxww |grep mysqlPokud ne, zkusím spustit, přesný postup nemohu napsat, jelikož jsi neuvedl distribuci, kterou používáš, ale nejčastějí takto :
/etc/init.d/mysqld starta podívat se do logu, který se nachází většinou ve :
cat /var/log/daemon.logV tomto logu se dozvíš, proč se nechce mysql spustit. Tak to sem kdyžak napiš.
root@node2:/var/run/mysqld# ps auxww |grep mysql
root 22794 0.0 0.0 13712 940 pts/7 S+ 22:44 0:00 grep --color=auto mysql
Při restartu mi to píše.
root@node2:/var/run/mysqld# /etc/init.d/mysql start
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql start
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start mysql
start: Job failed to start
cat /var/log/daemon.log toto jsme v var/log nenašel.
Feb 25 22:41:39 node2 postfix/anvil[5968]: statistics: max cache size 1 at Feb 25 22:31:39 Feb 25 22:45:32 node2 kernel: [16654089.519298] init: mysql main process (24213) terminated with status 1 Feb 25 22:45:32 node2 kernel: [16654089.519328] init: mysql main process ended, respawning Feb 25 22:45:33 node2 kernel: [16654090.415915] init: mysql post-start process (24214) terminated with status 1 Feb 25 22:45:33 node2 kernel: [16654090.530258] init: mysql main process (24250) terminated with status 1 Feb 25 22:45:33 node2 kernel: [16654090.530313] init: mysql main process ended, respawning Feb 25 22:45:34 node2 kernel: [16654091.453760] init: mysql post-start process (24251) terminated with status 1 Feb 25 22:45:34 node2 kernel: [16654091.571559] init: mysql main process (24425) terminated with status 1 Feb 25 22:45:34 node2 kernel: [16654091.571612] init: mysql respawning too fast, stopped
root@node2:/var/run/mysqld# 130225 23:00:58 mysqld_safe Logging to syslog.
130225 23:00:58 mysqld_safe Starting mysqld daemon with databases from /drbd/mysql/data
130225 23:00:58 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
[1]+ Dokončena mysqld_safe --user=mysql
/etc/mysql/my.cnfZdar Max
root@node2:~# cat /proc/drbd version: 8.3.11 (api:88/proto:86-96) srcversion: 71955441799F513ACA6DA60 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----- ns:425455 nr:6341312 dw:6766767 dr:74998805 al:118 bm:75 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0Zde výpis z mount
root@node2:~# mount /dev/sda1 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) configfs on /sys/kernel/config type configfs (rw) ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw) /dev/drbd0 on /drbd type ocfs2 (rw,_netdev,heartbeat=local)Výpis práv to by snad mělo být ok.
-rw-r----- 1 mysql mysql 18-rw-r----- 1 mysql mysql 18874368 úno 27 13:17 ibdata1 -rw-r----- 1 mysql mysql 5242880 úno 27 13:17 ib_logfile0 -rw-r----- 1 mysql mysql 5242880 úno 26 20:00 ib_logfile1 drwx------ 6 mysql mysql 3896 úno 26 00:42 mysql -rw-r----- 1 mysql mysql 6 úno 26 00:57 mysql_upgrade_info drwx------ 2 mysql mysql 3896 úno 26 00:05 performance_schema ........ atdJe doufám že jsem dodal to co je potřeba. Pokud né stačí napsat rád to dodám.
mysqld_safe --syslog
. Pokud nenaběhne tak kouknout do syslogu, případně ho sem postnout.
mysqldump --all-databases > alldb.sqlnebo případně s kompresí příkazem
mysqldump --all-databases -p | bzip2 -c > alldb.sql.bz2Kdybys potřeboval v něčem popostrčit, bude asi rychlejší, když mě kontaktuješ na jabberu, který mám v profilu.
Tam jde hlavně o to, zda ti nad těmi daty ve stejný okamžik na obou serverech běží MySQL. Protože pokud ano, tak vlatně oba servery zapisují do stejného úložiště, zapisují do stejných binlogů a přitom "o sobě neví". Nekonzistentní binární logy pak mohou zabránit v jejím spuštění, protože jej db obvykle po nekorektním ukončení potřebuje...
Pokud ti stačí jen "HA", tak nejjednodušší řešení je, mít prostě MySQL na jednom ze serverů vypnuté. A při výpadku jednoho serveru jej spustit na druhém. Toto můžeš automatizovat pomocí heartbeat, pacemaker anebo si na to udělat vlastní skript.
Nevím, jaký máš HW, ale jednou z dalších možností je využít replikaci, která je již v MySQL obsažena, tzn. že bys upustil od DRBD a replikaci dat ponechal přímo na MySQL. Máš na výběr mezi master-master a master-slave. První by pro tebe byla asi vhodnější, ale je celkem náročná, resp. výkonově závislá na latenci mezi servery. Master-slave je určitě rychlejší, je celkem jednoduché ze slave udělat master, ale už je složitější (resp. špatně se automatizuje) přepnutí do původního stavu.
Zálohovat MySQL jde jednoduše provádět dvěma způsoby: a) mysqldump - export obsahu databáze formou SQL příkazů. Jednoduché, funkční a ideální pro menší db. b) hot copy - prosté zkopírování datadir (db by ale měla být během kopírování zamčena jen pro čtení anebo zastavena) - vhodnější pro rozsáhlé db, kde bývají problémy se zamykáním a mysqldump trvá neúnosně dlouho
Pokud bys používal master-slave replikaci, tak jednoduše na slavu spustíš mysqldump a uděláš zálohu aniž bys zatěžoval ten master node. Zrovna tak by bylo možné použít hot copy a to jednoduše tak, že na slavu pozastavíš replikaci a zkopíruješ datadir.
Pokud bys používal master-master replikaci, tak opět můžeš použít na jednom ze serverů mysqldump, ale zbrzdíš tím všechny operace, které v tu chvíli nad db běží (na obou nodech díky zamykání). Hot copy se v tomto případě vůbec nehodí. Šlo by to asi řešit formou LVM snapshotů, ale to není úplně spolehlivé...
Jelikož používáš DRBD, je tu ještě jeden možný workaround a to pozastavit DRBD na jenom z nodů a remountnout jej v read-only režimu, potom snadno provedeš hot copy.
A jako poslední možnost, bez ohledu na to v jakém režimu oba nody běží, spustit ještě třetí mysql, které se bude replikovat z jednoho z nodů pomocí master-slave replikace. Toto je vhodné pokud máš třetí server určený pro zálohy a na něm potom provádět třeba právě ty dumpy.
Feb 28 10:50:41 node2 mysqld_safe: Starting mysqld daemon with databases from /drbd/mysql/data Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 [Note] Plugin 'FEDERATED' is disabled. Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: The InnoDB memory heap is disabled Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Mutexes and rw_locks use GCC atomic builtins Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Compressed tables use zlib 1.2.3.4 Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Initializing buffer pool, size = 128.0M Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Completed initialization of buffer pool Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: highest supported file format is Barracuda. Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Error: page 6 log sequence number 2424692490 Feb 28 10:50:41 node2 mysqld: InnoDB: is in the future! Current system log sequence number 2420826419. Feb 28 10:50:41 node2 mysqld: InnoDB: Your database may be corrupt or you may have copied the InnoDB Feb 28 10:50:41 node2 mysqld: InnoDB: tablespace but not the InnoDB log files. See Feb 28 10:50:41 node2 mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html Feb 28 10:50:41 node2 mysqld: InnoDB: for more information. Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Error: page 440 log sequence number 2425135360 Feb 28 10:50:41 node2 mysqld: InnoDB: is in the future! Current system log sequence number 2420826419. Feb 28 10:50:41 node2 mysqld: InnoDB: Your database may be corrupt or you may have copied the InnoDB Feb 28 10:50:41 node2 mysqld: InnoDB: tablespace but not the InnoDB log files. See Feb 28 10:50:41 node2 mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html Feb 28 10:50:41 node2 mysqld: InnoDB: for more information. Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Error: page 440 log sequence number 2425135360 Feb 28 10:50:41 node2 mysqld: InnoDB: is in the future! Current system log sequence number 2420826419. Feb 28 10:50:41 node2 mysqld: InnoDB: Your database may be corrupt or you may have copied the InnoDB Feb 28 10:50:41 node2 mysqld: InnoDB: tablespace but not the InnoDB log files. See Feb 28 10:50:41 node2 mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html Feb 28 10:50:41 node2 mysqld: InnoDB: for more information. Feb 28 10:50:41 node2 mysqld: 130228 10:50:41 InnoDB: Assertion failure in thread 140186747463488 in file fut0lst.ic line 83 Feb 28 10:50:41 node2 mysqld: InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA Feb 28 10:50:41 node2 mysqld: InnoDB: We intentionally generate a memory trap. Feb 28 10:50:41 node2 mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Feb 28 10:50:41 node2 mysqld: InnoDB: If you get repeated assertion failures or crashes, even Feb 28 10:50:41 node2 mysqld: InnoDB: immediately after the mysqld startup, there may be Feb 28 10:50:41 node2 mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to Feb 28 10:50:41 node2 mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html Feb 28 10:50:41 node2 mysqld: InnoDB: about forcing recovery. Feb 28 10:50:41 node2 mysqld: 09:50:41 UTC - mysqld got signal 6 ; Feb 28 10:50:41 node2 mysqld: This could be because you hit a bug. It is also possible that this binary Feb 28 10:50:41 node2 mysqld: or one of the libraries it was linked against is corrupt, improperly built, Feb 28 10:50:41 node2 mysqld: or misconfigured. This error can also be caused by malfunctioning hardware. Feb 28 10:50:41 node2 mysqld: We will try our best to scrape up some info that will hopefully help Feb 28 10:50:41 node2 mysqld: diagnose the problem, but since we have already crashed, Feb 28 10:50:41 node2 mysqld: something is definitely wrong and this may fail. Feb 28 10:50:41 node2 mysqld: Feb 28 10:50:41 node2 mysqld: key_buffer_size=8388608 Feb 28 10:50:41 node2 mysqld: read_buffer_size=131072 Feb 28 10:50:41 node2 mysqld: max_used_connections=0 Feb 28 10:50:41 node2 mysqld: max_threads=151 Feb 28 10:50:41 node2 mysqld: thread_count=0 Feb 28 10:50:41 node2 mysqld: connection_count=0 Feb 28 10:50:41 node2 mysqld: It is possible that mysqld could use up to Feb 28 10:50:41 node2 mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338486 K bytes of memory Feb 28 10:50:41 node2 mysqld: Hope that's ok; if not, decrease some variables in the equation. Feb 28 10:50:41 node2 mysqld:Feb 28 10:50:41 node2 mysqld: Feb 28 10:50:41 node2 mysqld: Thread pointer: 0x0 Feb 28 10:50:41 node2 mysqld: Attempting backtrace. You can use the following information to find out Feb 28 10:50:41 node2 mysqld: where mysqld died. If you see no messages after this, something went Feb 28 10:50:41 node2 mysqld: terribly wrong... Feb 28 10:50:41 node2 mysqld: stack_bottom = 0 thread_stack 0x30000 Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f7fc59fa569] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f7fc58c0be3] Feb 28 10:50:41 node2 mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f7fc4616cb0] Feb 28 10:50:41 node2 mysqld: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f7fc3c86445] Feb 28 10:50:41 node2 mysqld: /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f7fc3c89bab] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x5f4030)[0x7f7fc5aa2030] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x5e9177)[0x7f7fc5a97177] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x5e9e8c)[0x7f7fc5a97e8c] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x5eb833)[0x7f7fc5a99833] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x5d8265)[0x7f7fc5a86265] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x5a54b9)[0x7f7fc5a534b9] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f7fc58c3091] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x3048a1)[0x7f7fc57b28a1] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7f7fc57b5ec4] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x27f606)[0x7f7fc572d606] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x59b)[0x7f7fc5730ceb] Feb 28 10:50:41 node2 mysqld: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f7fc3c7176d] Feb 28 10:50:41 node2 mysqld: /usr/sbin/mysqld(+0x2793f5)[0x7f7fc57273f5] Feb 28 10:50:41 node2 mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Feb 28 10:50:41 node2 mysqld: information that should help you find out what is causing the crash. Feb 28 10:50:41 node2 mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Podívej se na práva /etc/mysql/my.cnf
. Měli by být nastavené na mysql:mysql
. Kdyby ani to nepomohlo, zkus zkopírovat my.cnf přímo do adresáře /etc/
.
Feb 28 19:40:52 node2 kernel: [243317.769747] init: mysql main process (18346) terminated with status 1
Feb 28 19:40:52 node2 kernel: [243317.769798] init: mysql main process ended, respawning
Feb 28 19:40:53 node2 kernel: [243318.693085] init: mysql post-start process (18347) terminated with status 1
Feb 28 19:40:53 node2 kernel: [243318.818904] init: mysql main process (18383) terminated with status 1
Feb 28 19:40:53 node2 kernel: [243318.818941] init: mysql main process ended, respawning
Feb 28 19:40:54 node2 kernel: [243319.735393] init: mysql post-start process (18384) terminated with status 1
Feb 28 19:40:54 node2 kernel: [243319.863507] init: mysql main process (18420) terminated with status 1
Feb 28 19:40:54 node2 kernel: [243319.863545] init: mysql respawning too fast, stopped
Mám soubor .frm a chtěl bych získat data zpět.
Tiskni
Sdílej: