Menu

dump

MySQL split dump to table

, , 0

Здравейте,

В продължение на поста MySQL split dump to different databases

от миналата година, днес ще споделя как бързо и лесно можем да извадим определена таблица от dump-a на MySQL базата ни. Разбира се ако базата ние малка можем да отворим този dump и да си копираме съдържанието на таблицата в текстов редактор, но когато базата ни е 100гб това няма да е възможно.

 

Тук идва на помощ sed и решението е :

sed -n -e '/CREATE TABLE.*`fc_company`/,/CREATE TABLE/p' 201709140001-db-CRM.sql > fc_company.sql

Тук нещата изглеждат напълно ясни, но да обесня :

  1. fc_company е таблицата която искаме да извадим
  2. 201709140001-db-CRM.sql е името на dump-а ни
  3. fc_company.sql е името на новият dump съдържащ само таблицата ни

Хубаво е да се прегледа след това самия fc_company.sql файл, тъй като sed понякога хваща и началото на други таблици и ги дропи 🙂 Такъв пример е ако имаме таблица fc_compay_new примерно.

Това е!

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

Това е! 🙂