MariaDB Master/Slave replication met slave op Azure

[RoRoo]

Hopelijk is de topic title niet té cryptisch..

Ik ben een testcase aan het opbouwen.
1. CentOS 7 server in Datacenter met MariaDB en PowerDNS als NS1
2. CentOS 7 server op Azure met MariaDB en PowerDNS als NS2

Deze 2 mariaDB's heb ik in een master/slave constructie gebouwd volgens diverse tutorials op het www.
En eigenlijk werkt het perfect. tot na een x aantal minuten. na die x minuten repliceert de slave niet meer.
Ondanks dat "SHOW SLAVE STATUS;" gewoon aangeeft:
Slave_IO_Running: Yes
Slave_SQL_Running: Yess

Restart ik de slave mariadb, dan worden al mijn wijzigingen weer netjes overgenomen.

In mijn initiele lokale tests waarbij de servers in hetzelfde net zaten, had ik deze issues niet. Replicatie bleef werken.

Ik heb de "slave_net_timeout" op de NS2 my.cnf op 300 geplaatst om te kijken of ik daarmee wat dingen naar boven kreeg.

En nu zie ik inderdaad dat de boel gedisconnect wordt:
Slave_IO_State: Reconnecting after a failed master event read
en
Last_IO_Error: error reconnecting to master '[e-mail]:3306' - retry-time: 10 retries: 86400 message: Can't connect to MySQL server on 'ns1.fqdn.ext' (110)

Als ik hier nu 5 minuten op wacht komt ie soms wel weer online maar vaak ook pas na een herstart van de ns2 mariadb service.

Ik gok dat Azure wat roet in het eten gooit door sessies te killen als er niet continu data overheen loopt. Mijn SSH sessies vallen ook dood na een 5 tal minuten idle..
Heel irritant om logs te tailen en je sessie disconnects

Even om alles compleet te maken, de my.cnf v/d servers. Té leeg voor woorden verwacht ik.

Zijn er tweaks toe te passen waardoor ik die disconnects van Azure kan opvangen?

NS1

code:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

log-bin=mysql-bin
server-id=1
innodb_flush_log_at_trx_commit=1
sync_binlog=1

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

NS2

code:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

server-id               =       2
#log_slave_updates      =       1
log-bin
#relay-log              =       /var/log/mariadb/mariadb-relay-bin.log
slave_net_timeout       =       300

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

[Kees]

Je zou domweg een crontab kunnen maken die elke minuut de huidige tijd wegschrijft in een tabel of een daemon die dat elke seconde doet waardoor je wat data over de lijn forceert. Het hangt er ook helemaal vanaf hoeveel data je repliceert. Hebben we het over een paar kilobytes of een paar [G/T/P]bytes per dag?

Verder zou ik op de slave de master-retry-count op 0 zetten (oneindig) en hem regelmatig laten reconnecten als je nog steeds idle problemen hebt.

En als dat allemaal niet werkt en je vertraging geen groot probleem vind, zou je ook nog updates vanaf de master kunnen pushen naar de slave, bijvoorbeeld door in een crontab de logs op de master te flushen, de bestaande binlogs (minus de nieuwe) op de slave te draaien en te verwijderen indien succesvol. Maar de ingebakken replicatie is uiteraard handiger

[RoRoo]

Kees schreef op donderdag 15 oktober 2015 @ 13:54:
Je zou domweg een crontab kunnen maken die elke minuut de huidige tijd wegschrijft in een tabel of een daemon die dat elke seconde doet waardoor je wat data over de lijn forceert. Het hangt er ook helemaal vanaf hoeveel data je repliceert. Hebben we het over een paar kilobytes of een paar [G/T/P]bytes per dag?

Gaat hier echt om Kb's per dag..

Kees schreef op donderdag 15 oktober 2015 @ 13:54:
Verder zou ik op de slave de master-retry-count op 0 zetten (oneindig) en hem regelmatig laten reconnecten als je nog steeds idle problemen hebt.

Zat ik ook al aan te denken.. maar de 4068 waar ie nu op staat zou imho ook voldoende moeten zijn. Maar ik hou 'm zeker in gedachten.

Kees schreef op donderdag 15 oktober 2015 @ 13:54:
En als dat allemaal niet werkt en je vertraging geen groot probleem vind, zou je ook nog updates vanaf de master kunnen pushen naar de slave, bijvoorbeeld door in een crontab de logs op de master te flushen, de bestaande binlogs (minus de nieuwe) op de slave te draaien en te verwijderen indien succesvol. Maar de ingebakken replicatie is uiteraard handiger

Ik ben idd meer fan van de ingebakken replicatie

Nu met de huidige settings is de vertraging (tot nu toe) max 10 minuten. Daar kan ik nog wel mee leven. TTL's staan voor de meeste records al hoger.

[CAPSLOCK2000]

Een onbetrouwbaar netwerk zou je kunnen omzeilen met een VPN dat zelf voor keep-alive's zorgt.

[RoRoo]

CAPSLOCK2000 schreef op donderdag 15 oktober 2015 @ 16:26:
Een onbetrouwbaar netwerk zou je kunnen omzeilen met een VPN dat zelf voor keep-alive's zorgt.

Dat zou inderdaad een optie kunnen zijn, ik haal 'm dan persoonlijk liever weg bij Azure en breng ik 'm onder in een ander DC.

Maar... Tot op heden.... DB's nog steeds in sync.

[Kees]

Vertraging van max 10 minuten vind ik nog erg veel, tussen mijn db's (tientallen gb's per dag voor binlogs) had ik vandaag 2 'piekjes', namelijk 1s behind en 33s behind (maar daar ligt dan wel een redundant 10gbit netwerk tussen )

[RoRoo]

Kees schreef op donderdag 15 oktober 2015 @ 19:44:
Vertraging van max 10 minuten vind ik nog erg veel, tussen mijn db's (tientallen gb's per dag voor binlogs) had ik vandaag 2 'piekjes', namelijk 1s behind en 33s behind (maar daar ligt dan wel een redundant 10gbit netwerk tussen )

Haha ik denk dat ik als op dat netwerk zit deze problemen ook niet komen.

Azure is heel mooi en makkelijk om 'effe' te testen maar er zijn toch wel een aantal beperkingen waar ik toch heel veel moeite mee heb.

[kuch]
Geen console
[/kuch]