Unsafe Statement Problem

Moin,
ich hoffe ihr könnt mir weiterhelfen und zwar habe ich kleines Problem mit einem Unsafe Statement und da ich ehrlich gesagt kein Experte auf dem Gebiet DB bin, dachte ich frag mal wo sich Leute rumtreiben die es besser wissen

Und zwar geht es darum Datenpaare Anhand von zwei Identifikatoren zu finden
die involvierten felder sind

Field | Type | Null | Key | Default | Extra
data_id | int(15) | NO | PRI | NULL | auto_increment
art_nr | varchar(20) | YES | | NULL |
farbweg_verf | varchar(10) | YES | | NULL |
pair_helper | varchar(200) | YES | | NULL |

Es geht darum dort wo art_nr und farbweg_verf identisch sind die data_id im Feld pair_helper zu hinterlegen.

Die Funktion die das zur Zeit erledigt sieht wie folgt aus:

update\
`pictures` P1 join `pictures` AS P2 ON\
P1.art_nr=P2.art_nr and\
P1.farbweg_verf=P2.farbweg_verf and\
P1.data_id<>P2.data_id and\
P1.art_nr <>'' and P1.farbweg_verf <>''\
set P1.pair_helper = P2.data_id

Wenn ich das ganze allerdings ausführe bekomme ich eine Warnung:

Warning: Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statements writing to a table with an auto-increment column after selecting from another table are unsafe because the order in which rows are retrieved determines what (if any) rows will be written. This order cannot be predicted and may differ on master and the slave.
set P1.pair_helper = P2.data_id """)

Hoffe hier kann mir Jemand weiterhelfen was getarn werden muss damit es vernünftig läuft.

 

Das würde ich schon mal anders machen. Verknüpfe beide Felder und vergleich, ob der String dann gleich ist. Aber das ist eine andere Baustelle, weil:

Du machst offensichtlich Replikation mit MySQL, und zwar Statement-basiert. Das ist so ziemlich das wackeligste Konstrukt, was die Menschheit je gebaut hat. Ein 50-stöckiges Kartenhaus ist dageben ein Bunker. Jedes Rollback, jede nicht vollendete Transaktion auf dem Master läßt die Replikation scheitern. FAIL by Design.

Du hast mehrere Lösungen:

• vergiß MySQL
• vergiß Relikation mit MySQL
• stelle auf Row-Level-Replaikation um
• verwende eine stabil und robust funktionierende Datenbank.

 

Mhm erstmal danke, denke ich.
Also mysql zu vergessen kommt nicht in frage, hab nun wirklich keine lust nur deswegen da ne komplett neue datenbank reinzupflicken. Punkt 1 & 4 sind identisch oder?

Wie geschrieben hab leider nicht allzuviel Ahnung von Datenbanken, das letzte mal in der Schule und das ist ein paar Jahre her, den query hab ich auch nur von einem bekannten, der es zumindest etwas besser kann als ich.

Was genau ist Row-Level-Replikation oder meinst du Low-Level?
Auch was genau müsste ich dann anders machen?

Wie genau wäre denn das Stichwort, dann würde ich schauen ob ich das nicht via SQLAlchemy lösen kann, dann müsste ich mich nicht damit außeinandersetzen.

 

Deine Entscheidung. Vermutlich wirst Du es früher oder später bereuen.

So gesehen ja.

Wie hast es geschafft, da 'ne Replikation aufzubauen?

http://www.linuxtopia.org/online_bo...base_reference_guide/replication-sbr-rbr.html

Die Config.

Wie genau wäre denn das Stichwort, dann würde ich schauen ob ich das nicht via SQLAlchemy lösen kann, dann müsste ich mich nicht damit außeinandersetzen.[/QUOTE]

Du mußt die Konfiguration der Server (Master, Slave) anpassen. Betreibst Du das zu Hause, ist das gehostet? Hast Du jemand, der Dir dabei hilft? Du wirst Hilfe brauchen, ...

 

Ne denke nicht das ich bereuen werde, zumindest nicht so bald. Die Applikation rennt ja ohne Probleme, die benutzt auch schon komplett SQLAlchemy der Part mit der replikation ist nur beim import script drin das alle paar tage läuft und schaut ob es neue daten gibt die in die datenbank sollen.

Und eigentlich soll es nicht mehr als gleiche bilder finden also vorder und rückseite, erkennbar an zwei identischen einträgen in 2 columns, zumindest wenn vorhanden und bei jedem in die column pair_helper die data_id des jeweils anderen schreiben.
Dann schaut die Webapplikation im Datensatz nach und gibt dann ggf. noch das passende Gegenstück mit aus.
Hätte nicht gedacht dass das so ein Akt wird, vielleicht sollte ich es doch mit ein paar schönen schleifen lösen, wenn das in mysql so kompliziert ist, leidet zwar die ausführungszeit des scripts drunter aber was solls, wenns dafür keine nervige mail mit warnung gibt

Und nope hab niemanden der mir damit hilft ist so ein ein-mann-projekt na ja abgesehen von dem oben genannten und noch einem anderen sql query von einem bekannten.

Das ganze läuft inner root vm im Netz (gentoo)
das ist auch der grund warum ich bei mysql und nicht wie ursprünglich geplant mariadb geblieben bin.
Die vm hat nur 512 mb ram und mysql ist wesentlich begnügsamer was das angeht als andere

 

ich sehe da leichte Widersprüche ;-)

 

Wie dem auch sei - die Fehlermeldung ist relativ eindeutig und damit auch, an welcher Schraube Du drehen mußt. Oder?

 

Der update process der Applikation ist ja eigenständig und für mich daher kein eigentlicher Bestandteil der Applikation als solches, die funktioniert ja wunderbar

Na ja wäre sie für mich eindeutig, hätte ich mich hier sicher nicht registriert um zu fragen wie man das ganze löst.

Aber so wie es aussieht wird mir nichts anderes übrig bleiben als das ganze nicht irgendwie hybrid mäßig zu lösen, schade hatte gedacht das es da ne mysql nativ lösung für gibt, die ohne warnung oder eingriffe in irgendwelche configs auskommt.

 

Was bitte an "Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. " hast Du nicht verstanden? Da IST ein Eingriff in die Config nötig. Oder ignoriere es halt. Völlig egal, knallt ja sowieso. Irgendwann. MySQL.

Habe fertig.