Disadvantages of row-opracowanie

Disadvantages of row-based replication
• RBR tends to generate more data that must be logged. To replicate a DML statement (such as an
UPDATE or DELETE statement), statement-based replication writes only the statement to the binary
log. By contrast, row-based replication writes each changed row to the binary log. If the statement
changes many rows, row-based replication may write significantly more data to the binary log; this is
true even for statements that are rolled back. This also means that taking and restoring from backup
can require more time. In addition, the binary log is locked for a longer time to write the data, which
may cause concurrency problems.
• Deterministic UDFs that generate large BLOB values take longer to replicate with row-based
replication than with statement-based replication. This is because the BLOB column value is logged,
rather than the statement generating the data.
• You cannot examine the logs to see what statements were executed, nor can you see on the slave
what statements were received from the master and executed.
However, you can see what data was changed using mysqlbinlog with the options --base64-
output=DECODE-ROWS [359] and --verbose [365].
• For tables using the MyISAM storage engine, a stronger lock is required on the slave for INSERT
statements when applying them as row-based events to the binary log than when applying them as
statements. This means that concurrent inserts on MyISAM tables are not supported when using rowbased
replication.
... zobacz całą notatkę