Menu

mysqldump

MySQL error 1594

, , , , , , 0

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 сървъра ни. След като се настигне с мастър-а вече всичко трябва да е ок!

Това е! 🙂

MySQL split dump to different databases

, , 0

MySQL split dump to different databasesПривет,

Днес ми се наложи да възтановявам счупени бази (главно с InnoDB таблици) , като за целта имах общ бекъп, голям около 6GB. Една от базите ми беше много голяма, а останалите малки – проблема беше обаче точно с тях. За целта ми трябваше нещо което да направи: MySQL split dump to different databases , или да ми раздели този голям общ бекъп на отделни файлове за всяка една от базите, за да мога да си ги възтановя една по една.

За целта се разрових из нета и попаднах на няколко решения, като в този пост ще споделя за 2 от тях. Едното изкарва бекъп само за определна база, а второто за всички наведнъж.

Ето и първият вариянт :

sed -n '/^-- Current Database: `c20elenhen`/,/^-- Current Database: `/p' 20160628025005-db-all.sql > c20elenhen.sql

Накратко – желаната от мен база, която изках да изкарам от бекъпа се казва: c20elenhen , бекъп-а ми се казва : 20160628025005-db-all.sql , а файла в който искам да запиша всичко се казва: c20elenhen.sql  – бързо и лесно! 🙂

Вторият вариянт обаче повече ми харесва, чащото директно ми раздели всички бази по отделно, без да трябва да описвам всяка след всяка. Ето и perl скрипт-а:

#!/usr/bin/perl -w
#
# splitmysqldump - split mysqldump file into per-database dump files.

use strict;
use warnings;

my $dbfile;
my $dbname = q{};
my $header = q{};

while (<>) {

# Beginning of a new database section:
# close currently open file and start a new one
if (m/-- Current Database\: \`([-\w]+)\`/) {
if (defined $dbfile && tell $dbfile != -1) {
close $dbfile or die "Could not close file!"
}
$dbname = $1;
open $dbfile, ">>", "$1_dump.sql" or die "Could not create file!";
print $dbfile $header;
print "Writing file $1_dump.sql ...\n";
}

if (defined $dbfile && tell $dbfile != -1) {
print $dbfile $_;
}

# Catch dump file header in the beginning
# to be printed to each separate dump file.
if (! $dbname) { $header .= $_; }
}
close $dbfile or die "Could not close file!"

А схемата става по следният начин :

mac-mini: nikolay$ perl splitmysqldump.pl < 20160628025005-db-all.sql
Writing file c15mobileroundcube_dump.sql ...
Writing file c15roundcube_dump.sql ...
Writing file c1aps1_dump.sql ...
Writing file c1aps2_dump.sql ...
Writing file c1aps4_dump.sql ...
Writing file c1hdbox_dump.sql ...
Writing file c1luxbeton_dump.sql ...
Writing file c1newhdbox_dump.sql ...
Writing file c1newtester_dump.sql ...
Writing file c1paste_dump.sql ...
......

Това е общо взето…

MySQL innodb crash

, , , , , 0

MySQL innodb crashПривет,

В допълнение на поста ми от 12.12.2013 за MySQL innodb crash-a, искам да споделя че, този проблем отново ми се случи на същия Ubuntu сървър. Оказа се че innodb е много фин сторидж енджин на MySQL-а и явно е много податлив на crash. Пример : счупи се единия хард диск и се наложи да преместя тази виртуалка на друг дял, и след като го сторих, MySQL-а не искаше да тръгва вече.

Проблемът:

Грешката отново беше следната:
Още..