OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
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: