mirror of
https://github.com/MariaDB/server.git
synced 2026-01-06 05:22:24 +03:00
ec72bda592
now by default, FLUSH, OPTIMIZE, ANALYZE, REPAIR commands are written to the binlog, unless the new NO_WRITE_TO_BINLOG keyword was used : OPTIMIZE NO_WRITE_TO_BINLOG table t; Previously these commands were never written to the binlog, but there are 2 reasons to change this : - the RENAME TABLE in MERGE table bug (#175) on slave - the possible "differently optimised queries may lead to different updates on the master and slave" bug, until we have automatic ORDER BY. FLUSH LOGS/SLAVE/MASTER/TABLES WITH READ LOCK are never written to the binlog. New test for the new logging behaviour. Other small change : reload_acl_and_cache() and reset_slave() don't send their errors themselves, this is more usual. mysql-test/mysql-test-run.sh: rpl_flush_tables.test generates 'table xx is open on rename'. This is normal and done on purpose, so don't report it. sql/lex.h: New keyword NO_WRITE_TO_BINLOG sql/mysql_priv.h: reload_acl_and_cache() now decides if we want to write the FLUSH command to the binlog or not (FLUSH MASTER, FLUSH SLAVE, FLUSH TABLES WITH READ LOCK, FLUSH LOGS cannot go into the binlog). sql/mysqld.cc: updated for new prototype of reload_acl_and_cache(). sql/sql_lex.h: New boolean no_write_to_binlog in the lex structure. sql/sql_parse.cc: reload_acl_and_cache() now does not send its errors itself; it saves the error and the caller sends it. FLUSH, OPTIMIZE, ANALYZE, REPAIR commands don't write to the binlog if the NO_WRITE_TO_BINLOG keyword was used. sql/sql_repl.cc: reset_slave() does not send its errors himself. sql/sql_yacc.yy: New optional keyword NO_WRITE_TO_BINLOG for OPTIMIZE/ANALYZE/REPAIR/FLUSH : OPTIMIZE NO_WRITE_TO_BINLOG TABLE t; ANALYZE NO_WRITE_TO_BINLOG TABLE t; REPAIR NO_WRITE_TO_BINLOG TABLE t; FLUSH NO_WRITE_TO_BINLOG TABLE t;
This is a release of MySQL, a GPL (free) SQL database server (more licence information in the PUBLIC file and in the reference manual). Please read the "Upgrading from..." section in the manual first, if you are migrating from older versions of MySQL! The latest information about MySQL can be found at: http://www.mysql.com To see what it can do take a look at the features section in the manual. For installation instructions see the Installation chapter in the manual. For future plans see the TODO appendix in the manual. New features/bug fixes history is in the news appendix in the manual. For the currently known bugs/misfeatures (known errors) see the bugs appendix in the manual. For examples of SQL and benchmarking information see the bench directory. The manual mentioned above can be found in the Docs directory. The manual is available in the following formats: as plain ASCII text in Docs/manual.txt, in HTML format in Docs/manual_toc.html, as GNU Info in Docs/mysql.info and as PostScript in Docs/manual.ps. MySQL is brought to you by the MySQL team at MySQL AB For a list of developers and other contributors, see the Credits appendix in the manual. ************************************************************ IMPORTANT: Send bug (error) reports, questions and comments to the mailing list at mysql@lists.mysql.com Please use the 'mysqlbug' script when posting bug reports or questions about MySQL. mysqlbug will gather some information about your system and start your editor with a form in which you can describe your problem. Bug reports might be silently ignored by the MySQL maintainers if there is not a good reason included in the report as to why mysqlbug has not been used. A report that says 'MySQL does not work for me. Why?' is not considered a valid bug report. The mysqlbug script can be found in the 'scripts' directory of the distribution, that is '<where-you-installed-mysql>/scripts'.