Menu

replication

MySQL delayed replication

, , , 0

Привет,

Днес ще споделя как лесно се слага MySQL delayed replication (закъсняла репликация).

Идеята е проста – имаме слейв сървър който е винаги изостанал от мастъра си. Това се прави с цел, той да седи като онлайн бекъп, и ако без да искаме изтрием нещо от главния сървър като таблица или база (или пък някой кадърен девелопър е truncate-нал таблица но вместо на дев го е направил на лайв – случвало ми се е!! 🙂 ), да можем бързо да вземем информацията от този изостанал слейв.

Да подчерая, че тази функция я има във версия на MySQL 5.6 и нагоре.

Ето и как се прави това :

Още..

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 master-slave server

, , , 0

MySQL master-slave serverПривет,

Днес ми се наложи да направя промяна в един MySQL cluster, като трябваше да включа нов междинен master/slave сървър :

 

[master]->[master/slave]->slave
За тази цел смених master_host-а на „slave“ сървъра от „master“ на „master/slave“ и промених binlog-а и позицията.

Да, но се натъкнах на следният проблем:
master/slave сървъра продължаваше да взима актуални данни от master-a, но сам по себеси не обновяваше своята master позиция, и така slave сървъра изостана от master-a.

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

От документацията на MySQL разбрах, че този проблем се оправя с опцията :

log-slave-updates

която трябва да бъде добавена в my.cnf на сървъра играещ ролята на master/slave в секция [mysqld].

След рестарт на mysql демона, позицията взе да се променя и репликацията към slave тръгна.

mysql> show master status ;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 7582729 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Това е!!

MySQL Load Balancing with HaProxy

, , , , 0

Привет,

В работата ми се наложи да правя схема за MySQL Cluster (master-master-master) репликация с HaProxy отпред (MySQL Load Balancing with HaProxy) и в този пост ще опиша подробно как става това.
Ето и сценария:

Използвах 4 Ubuntu 14.04 сървъра :

MySQL Load Balancing with HaProxy

Инсталацията

MySQL cluster-a ни е съставен по следния начин :

node #1
hostname: mysql1
IP: 192.168.188.160

node #2
hostname: mysql2
IP: 192.168.188.161

node #3
hostname: mysql3
IP: 192.168.188.162
Още..

MySQL Replication Error 1594

, 0

Привет,

Днес ми се наложи да оправям проблем в репликацията на 3 master-master-slave сървъра, като грешката беше непозната за мен – а именно 1594.

MySQL Replication Error 1594

Проблемът:

MySQL Replication Error 1594

На единия master сървър след show slave status \G; излизаше следното:

Още..

Load More