Pro začátek...
http://yoshinorimatsunobu.blogspot.com/2009 /08/great-performance-effect-of-fixing.html
Před InnoDB Pluginem 1.0.4 to bylo takto:
obtain mutex
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log and fsync, for commit-phase
release mutex
Na a po InnoDB Plugin 1.0.4 (a MySQL 5.5) je nyní:
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
obtain mutex
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log, for commit-phase
release mutex
fsync innodb log, for commit-phase
Jak vidíte, v nové verzi nic (kromě případu sync_binlog> 0) je fsync'd v kritické sekci. Tímto způsobem nyní funguje skupinové odevzdání a zajišťuje mnohem lepší souběžnou propustnost.
Například u předchozí „rozbité“ verze, pokud jste měli 100 souběžných odevzdání vláken, všechny fsyncy byly serializovány a vy byste získali 100 fsynců pro přípravu a dalších 100 fsynců pro odevzdání. Proto bylo skupinové potvrzení zcela přerušeno.
Nyní s novější implementací jsou fsyncs seskupeny v závislosti na souběžnosti transakcí a zároveň zajišťují pořadí operací mezi logem innodb a binlogem. To také znamená, že pokud existuje pouze jedno vlákno, nedochází k žádnému zvýšení výkonu.
Pokud jde o vaši otázku, když dojde k selhání poté, co je transakce zapsána do binlogu, ale před jejím zapsáním do protokolu transakcí - jsem na stejné stránce jako vy.
Pokud se server zhroutil před posledním krokem, existuje malá šance, že máte nesrovnalosti mezi protokolem innodb a binlogem (který může být před druhým), ale je zaručeno, že máte všechny informace o tom, co zkoumata v protokolu innodb, jak je zaznamenán ve fázi přípravy.
Nicméně, co dělat s nezávazným, je stále nedeterministické. Například pokud sync_binlog = 1 existuje šance, že slave přijal data, ale ještě plně nesynchronizoval binlog na masteru. Nemůžete jen zopakovat neúspěšnou transakci, protože již mohla být spuštěna na jednom z podřízených jednotek.
Což také znamená, že binlog může být kratší než protokol innodb a vrátí "Binární protokol [název_souboru] je kratší než jeho očekávaná velikost." jak je popsáno v oficiálním dokumentu, a musíte znovu postavit otroka od nuly. Nepříliš přátelské k lidem.
http://dev.mysql.com/doc/refman /5.1/cs/binary-log.html
Protože je zaručena konzistence z hlediska řazení operací nezávisle na innodb_support_xa nastavení (což je v rozporu s tím, co je uvedeno v oficiálním dokumentu na innodb_support_xa , možná proto, že o stock innodb 5.0.3 bylo napsáno daleko před opravou souběžnosti) a konzistence mezi logem innodb na hlavním a reléovým logem na slave není přísně zaručena ani s innodb_support_xa , nevidím žádný smysl v používání innodb_support_xa . Je děsivé neřídit se oficiálním doporučením, ale v mnoha bodech se zdá zastaralé a nesprávné.
Zajímalo by mě, jestli existuje nějaká korelace mezi innodb_flush_log_at_trx_commit nastavení a innodb_support_xa chování, když je první nastaveno na 2 nebo 0.
Jedním z praktických způsobů uvažování je, že převzetí služeb při selhání na slave zařízení je bezpečné – koneckonců neúspěšná transakce byla něco, co jste chtěli provést – ale nikdy se nevrací zpět k hlavnímu zařízení, protože v datech mohou být určité nesrovnalosti. Než z mastera uděláte nového slave, musíte plně zkopírovat data z podřízeného zařízení. Jinými slovy, když se zhroutil hlavní server, od té doby důvěřujte podřízenému – tímto způsobem se pro obnovu po havárii nemusíte potýkat s logem innodb.
Všimněte si také, že MySQL 5.5 podporuje semisynchronní replikaci, stejně jako „důvěřujte otrokovi“ – možná by vás to mohlo zajímat.
http://dev.mysql.com/doc/refman /5.5/en/replication-semisync.html