Oracle 5.0 Reference Manual page 1732

| 14 |
+--------+
[967]
NAME_CONST()
same effect as the original statement that was executed on the master within a stored procedure.
The use of
NAME_CONST()
statements when the source column expressions refer to local variables. Converting these
references to
NAME_CONST()
on the master and slave servers, or names that are too long to be legal column identifiers. A
workaround is to supply aliases for columns that refer to local variables. Consider this statement
when has a value of 1:
myvar
CREATE TABLE t1 SELECT myvar;
That will be rewritten as follows:
CREATE TABLE t1 SELECT NAME_CONST(myvar, 1);
To ensure that the master and slave tables have the same column names, write the statement like
this:
CREATE TABLE t1 SELECT myvar AS myvar;
The rewritten statement becomes:
CREATE TABLE t1 SELECT NAME_CONST(myvar, 1) AS myvar;
• A statement to be logged might contain references to user-defined variables. To handle this,
MySQL writes a
SET
with the same value as on the master. For example, if a statement refers to a variable @my_var,
that statement will be preceded in the binary log by the following statement, where
value of
@my_var
SET @my_var = value;
• Procedure calls can occur within a committed or rolled-back transaction. Previously,
statements were logged even if they occurred within a rolled-back transaction. As of MySQL
5.0.12, transactional context is accounted for so that the transactional aspects of procedure
execution are replicated correctly. That is, the server logs those statements within the procedure
that actually execute and modify data, and also logs BEGIN, COMMIT, and
as necessary. For example, if a procedure updates only transactional tables and is executed
within a transaction that is rolled back, those updates are not logged. If the procedure occurs
within a committed transaction,
procedure that executes within a rolled-back transaction, its statements are logged using the same
rules that would apply if the statements were executed in standalone fashion:
• Updates to transactional tables are not logged.
• Updates to nontransactional tables are logged because rollback does not cancel them.
• Updates to a mix of transactional and nontransactional tables are logged surrounded by
and
ROLLBACK
• A stored procedure call is not written to the binary log at the statement level if the procedure is
invoked from within a stored function. In that case, the only thing logged is the statement that invokes
the function (if it occurs within a statement that is logged) or a
statement that is not logged). For this reason, care still should be exercised in the use of stored
functions that invoke a procedure, even if the procedure is otherwise safe in itself.
Binary Logging of Stored Programs
enables a logged standalone statement to be executed on a slave with the
[967] can result in a problem for
[967] expressions can result in column names that are different
statement to the binary log to make sure that the variable exists on the slave
on the master:
and
BEGIN
so that slaves will make the same changes and rollbacks as on the master.
1712
CREATE TABLE ... SELECT
statements are logged with the updates. For a
COMMIT
statement (if it occurs within a
DO
is the
value
CALL
statements
ROLLBACK
BEGIN