Stored Program Binary Logging +--------+ CREATE TABLE t1 SELECT myvar; CREATE TABLE t1 SELECT NAME_CONST(myvar, 1); CREATE TABLE t1 SELECT myvar AS myvar; CREATE TABLE t1 SELECT NAME_CONST(myvar, 1) AS myvar; NAME_CONST()  enables a logged standalone statement to be executed on a replica with the same effect as the original statement that was executed on the source within a stored procedure. The use of  NAME_CONST()  can result in a problem for  CREATE TABLE ... SELECT  statements when the source column expressions refer to local variables. Converting these references to NAME_CONST()  expressions can result in column names that are different on the source and replica 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  myvar  has a value of 1: This is rewritten as follows: To ensure that the source and replica tables have the same column names, write the statement like this: The rewritten statement becomes: •A statement to be logged might contain references to user-defined variables. To handle this, MySQL writes a  SET  statement to the binary log to make sure that the variable exists on the replica with the same value as on the source. For example, if a statement refers to a variable  @my_var , that statement is preceded in the binary log by the following statement, where  value  is the value of  @my_var  on the source: SET @my_var =  value ; •Procedure calls can occur within a committed or rolled-back transaction. 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  ROLLBACK  statements 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,  BEGIN  and  COMMIT  statements are logged with the updates. For a 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  BEGIN  and ROLLBACK  so that replicas make the same changes and rollbacks as on the source. •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  DO  statement (if it occurs within a statement that is not logged). For this reason, care should be exercised in the use of stored functions that invoke a procedure, even if the procedure is otherwise safe in itself. 4760