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