proxmox

, , , , , , 0 comments

MySQL error 1594

MySQL error 1594Привет,

От известно време в един proxmox cluster ми се случва следното – при рестартиране на MySQL сървър работещ като slave, репликацията спира да работи, и връща грешка : MySQL error 1594.

Положението изглежда долу-горе така :

 

Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.188.223
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.002046
Read_Master_Log_Pos: 70104169
Relay_Log_File: mysql-relay-bin.001957
Relay_Log_Pos: 243
Relay_Master_Log_File: mysql-bin.004319
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1594
Last_Error: Relay log read failure: Could not parse relay log event entry.
The possible reasons are: the master's binary log is corrupted
(you can check this by running 'mysqlbinlog' on the binary log),
the slave's relay log is corrupted (you can check this by running
'mysqlbinlog' on the relay log), a network problem, or a bug in the
master's or slave's MySQL code. If you want to check the master's
binary log or slave's relay log, you will be able to know their names
by issuing 'SHOW SLAVE STATUS' on this slave.
Skip_Counter: 0
Exec_Master_Log_Pos: 70104169
Relay_Log_Space: 983411603
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1594

До сега решавах проблема, като dump-вах базата от мастър сървъра и я наливах на ново със съответните master_log_file позиция и master_log_pos. Базата ни обаче стана прекалено голяма, и подобен dump започна да отнема много време. За това се наложи да намерим алтернативен начин за разрешаване на този проблем.

Ето и начина!

За целта е нужна следната информация от:

show slave status \G;
Exec_Master_Log_Pos: 70104169
Relay_Master_Log_File: mysql-bin.004319

Напрактика това са последните актуални данни от мастър сървъра ни, преди слейва ни да спре да репликира.

За да оправим проблема пишем следното на слейв-а :

stop slave;
reset slave;
change master to master_log_file='mysql-bin.004319', master_log_pos= 70104169;
start slave;

И благодарение на mytop можем да наблюдаваме в реално време как върви синхронизацията на MySQL сървъра ни. След като се настигне с мастър-а вече всичко трябва да е ок!

Това е! 🙂

, , , 0 comments

qcow2: Image is corrupt; cannot be opened read/write

Привет,

Днес ще споделя за проблем който се случи на уеб сървъра на www.root.bg.

Бекъпа е фейлнал

Тази сутрин мейла за ежеседмичният бекъп на виртуалните машини включваше :

vzdump backup status : backup failed.

Оказа се, че бекъпа на web.root.bg е фейлнал:

104 web.root.bg FAILED 00:59:54 VM 104 not running

и сървъра е спрял.
Сутринта пуснах сървъра и тръгнах да търся причината за проблема от логовете.

Проблема се задълбочи

Реших да направя snapshot на работещата машина, но малко след като го пуснах се сетих, че нямам излишно място на proxmox сървъра за този snapshot, и за това го спрях.

Тук обаче нещо се обърка.

web-root:~# dmesg
-bash: dmesg: command not found
web-root:~# reboot
-bash: reboot: command not found
web-root:~# logout
-bash: /root/.bash_logout: Input/output error
-bash: /etc/bash.bash_logout: Input/output error

В терминала на машината излизаше, че reiserfs-a е крашнал и сървъра не реагираше на нищо.

Реших да го ресетна, но резултата не беше този който очаквах :

~# qm start 104
kvm: -drive file=/var/lib/vz/images/104/vm-104-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on: qcow2: Image is corrupt; cannot be opened read/write

 

qcow2: Image is corrupt; cannot be opened read/write

Възтановяване на системата

Опитах да поправя счупеният qcow2 диск като следвах стъпките от този сайт. За съжеление и това не помогна :

anna:/var/lib/vz/images/104# mv vm-104-disk-1.qcow2 bad_104.qcow2
anna:/var/lib/vz/images/104# qemu-nbd --connect=/dev/nbd0 bad_104.qcow2
Failed to blk_new_open 'bad_104.qcow2': qcow2: Image is corrupt; cannot be opened read/write
Бях в ситуация в която нямаше как да възтановя boot диск-а на web.root.bg.

Вариянтите бяха два:

  1. Инсталиране на нов линукс + всички пакети необходими за работа за сайта, piwik статистиката и wp админ панела.
  2. Възтановяване на системата от бекъп сървъра ми (FreeNAS)
Разбира се, писах за проблема на стената на сайта във facebook и twitter, както и в status.root.bg.

Реших да пробвам първо със стъпка 2, като си забазих втория qcow2 файл (където реално ми е /var на web.root.bg), за да нямам загуба на данни на базата и файловете на сайта.

 

Happy end

След 40 минути възтановяване на двата qcow2 файла, всичко мина успешно.
Върнах предварително запазеният ми vm-104-disk-2.qcow2 файл и пуснах машината – УРА – всичко тръгна по старо му!

Извода – винаги, ама винаги трябва да имаме бекъп!!

Бъдещ ъпгрейд към docker?

Това което смятам да направя следващата седмица, е да разделя web и database частта на сървъра в docker инстанции.

За целта ще направя нов виртуален сървър и ще започна тестовете там. В работата успешно внедрихме docker на няколко production инстанции и сме много доволни за сега от него.

Така че, здравей docker!

, , 0 comments

proxmox software watchdog

Привет,

В този пост ще споделя как бързо и лесно се пуска proxmox software watchdog.

proxmox software watchdog

Идеята е следната : имаме 4 сървъра обединени в proxmox cluster. Два от тях имат hardware watchdog модул, но другите два нямат.
За да работи HA при тях е необходим watchdog.

За да се активира proxmox software watchdog е нужно да направим следното :

1. Активира се softdog модула :

echo "softdog" >> /etc/modules

2. Чрез uname -r можем да видим с коя версия на линукс ядрото сме, и да редактираме следния файл :

vim /lib/modprobe.d/blacklist_pve-kernel-4.4.21-1-pve.conf

– в моят случай е версия 4.4.21-1-pve и трябва да закоментираме реда : blacklist softdog

#blacklist softdog

3. Рестартираме сървъра и проверяваме дали работи softdog модула чрез:

pluto:~# lsmod |grep softdog
softdog 16384 1

и последно дали работи watchdog-mux сървиса :

pluto:~# systemctl status watchdog-mux.service
● watchdog-mux.service - Proxmox VE watchdog multiplexer
Loaded: loaded (/lib/systemd/system/watchdog-mux.service; static)
Active: active (running) since Tue 2016-11-01 23:11:59 EET; 2 days ago
Main PID: 1167 (watchdog-mux)
CGroup: /system.slice/watchdog-mux.service
└─1167 /usr/sbin/watchdog-mux

Nov 01 23:11:59 pluto watchdog-mux[1167]: Watchdog driver 'Software Watchdog', version 0
Nov 04 10:14:25 pluto systemd[1]: Started Proxmox VE watchdog multiplexer.

Това е!

, , , , 0 comments

device is already in use

Здравейте,

Тази сутрин трябваше да направя live migration от ext3 към ext4 на един proxmox сървър, и в този пост искам да споделя преживяното:

device is already in use

Започнах процедурата като спазвах стъпките от https://debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem , но излезе следният проблем:

Първо при umount /dev/pve/data излезе :

umount: /var/lib/vz: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)

Използвах флаг-а -l при umount и продължих по стъпките.

При fsck.ext4 -yfD /dev/pve/data обаче възникна същия проблем :

moon:~# fsck.ext4 -yfD /dev/pve/data
e2fsck 1.42.12 (29-Aug-2014)
/dev/pve/data is in use.
e2fsck: Cannot continue, aborting.

За да разбера какво караше /dev/pve/data да е все още монтиран, трябваше да използвам командата fuser -m /dev/pve/data

И така разбрах следното :

moon:/var/lib# fuser -m /dev/pve/data
/dev/dm-2: 11657 11685 17558 22012 24655 26116 29357 34728 35034 35694 42784 46330 47645

Това бяха pid-овете на процесите задържащи /dev/pve/data .. спрях ги един по един и успях да продължа миграцията както следва :

moon:~# tune2fs -O extents,uninit_bg,dir_index /dev/pve/data
tune2fs 1.42.12 (29-Aug-2014)
moon:~# fsck.ext4 -yfD /dev/pve/data
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/pve/data: ***** FILE SYSTEM WAS MODIFIED *****
/dev/pve/data: 770019/482590720 files (0.3% non-contiguous), 1543788056/3860725760 blocks

Накрая монтирах на ново /dev/pve/data към /var/lib/vz и вече имах успешно мигрирана ext4 файлова система! Нито един файл не се затри през цялата операция! 🙂

Това е!

, , 0 comments

proxmox 4 lvm data

proxmox 4 lvm dataПривет,

От версия 4.2 насам, proxmox използват lvm-thin за data storage по подразбиране.

 

Lvm-thin може да е готино и да има много предимства, но на мен нещо не ми допадна.. и затова ми трябва начин да върна нещата по старо му – да монтирам /var/lib/vz като LVM2 дял и да го използвам за всичко.

Близкия месец ми се наложи да правя това на 3 сървъра, и ето че дойде време да го напиша и в блога като пост: proxmox 4 lvm data, за да не търся всеки път…

Ето стъпките :

1. Чрез командата lvs можем да видим, че дяла наистина е lvm-thin:

lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-a-tz-- 14.44t 0.00 0.42
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g

2. Изтриваме logical дяла чрез lvremove и го създаваме на ново чрез lvcreate:

lvremove pve/data
lvcreate --name data -l +100%FREE pve

3. Форматираме /dev/pve/data :

mkfs.ext4 /dev/pve/data

4. Добавяме /var/lib/vz във /etc/fstab за да може да се монтира автоматично при reboot:

vim /etc/fstab

и добавяме :

/dev/pve/data /var/lib/vz ext4 defaults 0 1

5. Монтираме чрез mount -a и ако всичко е ок, новият ни дял трябва да се е появил:

mount -a
df -h
Filesystem Size Used Avail Use% Mounted on
udev 10M 0 10M 0% /dev
tmpfs 51G 9.5M 51G 1% /run
/dev/dm-0 95G 1.2G 89G 2% /
tmpfs 126G 25M 126G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 126G 0 126G 0% /sys/fs/cgroup
/dev/fuse 30M 16K 30M 1% /etc/pve
/dev/mapper/pve-data 15T 9.7M 14T 1% /var/lib/vz

Ами това е! 🙂

1 2 3