Menu

dump

MySQL split dump to table

, , 0

Hello,

From my last post: MySQL split dump to different databases

from last year, today I will share how quickly and easily we can extract a dump table from our MySQL database. Of course, if we our database a small one, we can open this dump and copy the content of the table into a text editor, but when our base is 100GB it will not be possible.

 

Everything is thanks to sed  :

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

Here things seems to be quite clear, but I will clear them out:

  1. fc_company is the table which we want to get
  2. 201709140001-db-CRM.sql is the name of our dump
  3. fc_company.sql is the name of the new dump with our table

It is goot to check the fc_company.sql file, because sed gets the beggining of the next table and drops it 🙂 An example is if we have table fc_compay_new for example.

That’s it!

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

Това е! 🙂