Hi,
Wenn ich eine INSERT/UPDATE an den Master sende, gibt es dann eine möglichkeit herrauszufinden wann der Slave über diese änderung informiert wurde?
Auf dem Slave wartet ein Script an eine Semaphore..
Nun kommt am Master ein INSERT, jetzt sende ich an den Slave ein Signal das das Script die Semaphore passieren lässt, welches dann in der DB( also auf dem Slave) nach den neu eingefügten Daten schaut... Wenn der Slave aber zu dem Zeitpunkt noch nicht erfolgreich repliziert wurde hab ich quasi die Semaphore zu früh freigegeben..
Also das Singnal nach dem INSERT auf dem Master dürfte erst dann abgesendet werden, wenn der Slave repliziert wurde..
ich hoffe damit den sachverhalt einigermaßen hinreichend erklärt zu haben.. und bedanke mich schon mal im vorraus für die Antworten!!
so far
PS.. aktives Warten zählt nicht! ;-)
PS.PS.: am coolsten wär es dem mysql_query nen zusätzlichen Parameter zu übergeben, der den aufrufenden prozess solange blockt bis die replication soweit fertig ist... aber das gibt es wahrscheinlich nicht oder?
Frage zu Mysql Master-Slave Replication
Re: Frage zu Mysql Master-Slave Replication
Hi nochmal
Die Semaphore ist bisher eigentlich nur dazu da einen Long Poll Request zu starten.. also das aufgerufene Script solange zu blocken bis ein anderes Script, beim einfügen neuer daten(EVENTS), dann die entsprechende Semaphore freigibt und hiermit dann die daten an den Client ausgegeben werden.. Ich war bisher dabei zu probieren diese Long Poll requests ebenfalls von Master auf die Slaves weiter zuleiten(also httpd- nicht mysql-slaves), um sie dort an einer Semaphore warten zu lassen...
z.B.
Wenn nun Client X auf dem Master für Client Y(welcher auf Slave Z an einer Semaphore wartet) neue daten einfügt, ruft Client X ebenfalls ein release(V) der Semaphore für Client Y auf Slave Z auf. Nach dem release schaut Client Y dann in der Slave DB nach neuen daten.. welche aber nicht zwangläufig schon repliziert wurden..
Bin mir aber gerade nicht sicher ob es nicht doch sinvoller wäre die LongPoll Sema. zentral auf dem Master zu belassen?!?
genau da liegt mein Problem..einen geeigenete Methode finden um einen Datenstamm auf dem Slave frei zu geben.
Die Semaphore ist bisher eigentlich nur dazu da einen Long Poll Request zu starten.. also das aufgerufene Script solange zu blocken bis ein anderes Script, beim einfügen neuer daten(EVENTS), dann die entsprechende Semaphore freigibt und hiermit dann die daten an den Client ausgegeben werden.. Ich war bisher dabei zu probieren diese Long Poll requests ebenfalls von Master auf die Slaves weiter zuleiten(also httpd- nicht mysql-slaves), um sie dort an einer Semaphore warten zu lassen...
z.B.
Wenn nun Client X auf dem Master für Client Y(welcher auf Slave Z an einer Semaphore wartet) neue daten einfügt, ruft Client X ebenfalls ein release(V) der Semaphore für Client Y auf Slave Z auf. Nach dem release schaut Client Y dann in der Slave DB nach neuen daten.. welche aber nicht zwangläufig schon repliziert wurden..
Bin mir aber gerade nicht sicher ob es nicht doch sinvoller wäre die LongPoll Sema. zentral auf dem Master zu belassen?!?
anderseits dürfte dann mit Transaktionen auch die auslagerungen wie ich sie mir vorgestellt hatte funktionieren.Transaktionen werden ebenfalls als solches an den Slave übertragen.
Re: Frage zu Mysql Master-Slave Replication
Stiba wrote:PS.PS.: am coolsten wär es dem mysql_query nen zusätzlichen Parameter zu übergeben, der den aufrufenden prozess solange blockt bis die replication soweit fertig ist... aber das gibt es wahrscheinlich nicht oder?
Code: Select all
select master_pos_wait(...)[/quote]
Drei Parameter: Binlog Name, Binlog Position, Timeout.
Du bekommst die Binlog-Namen und Positionen auf dem Master mit dem entsprechenden Kommando (SHOW MASTER STATUS).
Re: Frage zu Mysql Master-Slave Replication
zunächst mal danke für die tipps..
allerdings habe ich mich mittlerweile dazu entschlossen das Event System bzw. seine DB auf einen eingenen Master zu partitionieren. Da die queries in dem Fall auch einerseits strikte INDEX SELECTS sind die nie mehr als 5 Events gleichzeitig zurück geben und anderer seits ein paar einfache INSERTS, dürfte der mysqld hiermit perfomance technisch locker klar kommen, also keine M-S Replikation mehr benötigen. Der neue Master ist nun also nur noch mit den Events beschäftigt, und hat nichts mehr mit der M-S Replikation des "alten" Masters an dem die Daten auch nicht zwangsläufig synchron verteilt sein müssen, zu tun.
vereinfacht sieht das nun in etwa so aus...
die Semaphore hab ich hierbei nur als einfache signal_waits beschrieben.....
Grüße
allerdings habe ich mich mittlerweile dazu entschlossen das Event System bzw. seine DB auf einen eingenen Master zu partitionieren. Da die queries in dem Fall auch einerseits strikte INDEX SELECTS sind die nie mehr als 5 Events gleichzeitig zurück geben und anderer seits ein paar einfache INSERTS, dürfte der mysqld hiermit perfomance technisch locker klar kommen, also keine M-S Replikation mehr benötigen. Der neue Master ist nun also nur noch mit den Events beschäftigt, und hat nichts mehr mit der M-S Replikation des "alten" Masters an dem die Daten auch nicht zwangsläufig synchron verteilt sein müssen, zu tun.
vereinfacht sieht das nun in etwa so aus...
die Semaphore hab ich hierbei nur als einfache signal_waits beschrieben.....
Code: Select all
http-request kommt am reverse Proxy an ->
{
if(Request ist Event (Insert oder Poll))
{
-> zum httpd der verbinung zu "neuen" master hat weiterleiten->
if(Request ist Event Insert)
{
EventDaten in neuen Master einfügen;
signal(SIGCONT, DB[user_pids[EventDaten["to_user_id"]]]);
}
else
{
signal_wait(SIGCONT);
echo SELECT * FROM events WHERE user_id=$myuser_id;
// -> daten werden in javascript beim client verarbeitet und der Long-Poll request erneuert
}
}
else
{
if(Request enthält nur DQL)
{
zum einem httpd weiterleiten der über seinen eingenen mysqld verfügt, welcher Slave des "alten" Masters ist
if(SESSION_DATA_CHANGED)
{
syncSessionDatawith_Master();
}
}
sonst
{
zum einem httpd weiterleiten der zu dem "alten" Mysql Master Connection hat (INSERTS,UPDATES etc)
if(SESSION_DATA_CHANGED)
{
syncSessionDatawith_corespondingSlave();
}
}
}
}