mirror of
https://github.com/MariaDB/server.git
synced 2025-01-16 20:12:31 +01:00
MariaDB server is a community developed fork of MySQL server. Started by core members of the original MySQL team, MariaDB actively works with outside developers to deliver the most featureful, stable, and sanely licensed open SQL server in the industry.
amazon-web-servicesdatabasefulltext-searchgalerageographical-information-systeminnodbjsonmariadbmysqlrdbmsrelational-databasessqlstorage-enginevector-database
378894b000
This is the main commit for Worklog tasks: * A more dynamic binlog format which allows small changes (1064) * Log session variables in Query_log_event (1063) Below 5.0 means 5.0.0. MySQL 5.0 is able to replicate FOREIGN_KEY_CHECKS, UNIQUE_KEY_CHECKS (for speed), SQL_AUTO_IS_NULL, SQL_MODE. Not charsets (WL#1062), not some vars (I can only think of SQL_SELECT_LIMIT, which deserves a special treatment). Note that this works for queries, except LOAD DATA INFILE (for this it would have to wait for Dmitri's push of WL#874, which in turns waits for the present push, so... the deadlock must be broken!). Note that when Dmitri pushes WL#874 in 5.0.1, 5.0.0 won't be able to replicate a LOAD DATA INFILE from 5.0.1. Apart from that, the new binlog format is designed so that it can tolerate a little variation in the events (so that a 5.0.0 slave could replicate a 5.0.1 master, except for LOAD DATA INFILE unfortunately); that is, when I later add replication of charsets it should break nothing. And when I later add a UID to every event, it should break nothing. The main change brought by this patch is a new type of event, Format_description_log_event, which describes some lengthes in other event types. This event is needed for the master/slave/mysqlbinlog to understand a 5.0 log. Thanks to this event, we can later add more bytes to the header of every event without breaking compatibility. Inside Query_log_event, we have some additional dynamic format, as every Query_log_event can have a different number of status variables, stored as pairs (code, value); that's how SQL_MODE and session variables and catalog are stored. Like this, we can later add count of affected rows, charsets... and we can have options --don't-log-count-affected-rows if we want. MySQL 5.0 is able to run on 4.x relay logs, 4.x binlogs. Upgrading a 4.x master to 5.0 is ok (no need to delete binlogs), upgrading a 4.x slave to 5.0 is ok (no need to delete relay logs); so both can be "hot" upgrades. Upgrading a 3.23 master to 5.0 requires as much as upgrading it to 4.0. 3.23 and 4.x can't be slaves of 5.0. So downgrading from 5.0 to 4.x may be complicated. Log_event::log_pos is now the position of the end of the event, which is more useful than the position of the beginning. We take care about compatibility with <5.0 (in which log_pos is the beginning). I added a short test for replication of SQL_MODE and some other variables. TODO: - after committing this, merge the latest 5.0 into it - fix all tests - update the manual with upgrade notes. client/Makefile.am: mysqlbinlog.cc depends slightly on sql/mysql_priv.h client/mysqlbinlog.cc: Make mysqlbinlog able to read the new binlog format, by seeking to the start and reading the first few events, to detect the format of the binlog. include/my_sys.h: a correct tell() for SEQ_READ_APPEND caches. mysys/mf_iocache2.c: a correct tell() for SEQ_READ_APPEND caches (my_b_tell() is not working for such caches). sql/ha_innodb.cc: we are getting rid of event lengthes here and there, which is good. sql/log.cc: Start events will have created==0 if generated by rotation (like in 3.23). In 5.0 we always write a Format_description_log_event at the beginning of every master's binary log and of every slave's relay log. We also add Rotate and Stop to relay logs (like there already was in master's binary logs). When we rotate a relay log, we write the previous relay log's Start event (the one which was sent from the master) to the beginning of the new log, so that we don't need the previous relay log to understand the new one; that's the purpose of MYSQL_LOG::description_event_for_queue. Removed logging of SET FOREIGN_KEY_CHECKS, because we handle it as flags in the Query event now. sql/log_event.cc: New event type: Format_description_log_event, to describe the log's format. read_log_event() needs to be passed this event to be able to read 5.0 events. Query_log_event has new members flags2 and sql_mode for replication of session variables (except charsets which are WL#1062) and SQL_MODE. flags2 is in fact a kind of copy of thd->options (&'d with a mask). Now with this replication of FOREIGN_KEY_CHECKS, SQL_AUTO_IS_NULL, UNIQUE_CHECKS and SQL_MODE work; with mysqlbinlog too. sql/log_event.h: Binlog version is changed to 4. New classes (details in sql/log_event.cc). Removing some useless #defines. sql/mysql_priv.h: Definition of SELECT_DISTINCT and others must be visible in client/mysqlbinlog.cc, so adding #ifdefs. sql/mysqld.cc: update for prototype change sql/slave.cc: When the slave opens a relay log, it reads the first few events to know the format. When slave I/O thread receives a Rotate from the master, it rotates its relay log (to avoid mixed format in the relay log). sql/slave.h: in the slave we avoid lengthes and rely on absolute positions instead; hence the introduction of future_group_master_log_pos and future_event_relay_log_pos (explained in code). sql/sql_class.cc: catalog in THD sql/sql_class.h: catalog, and new members in MYSQL_LOG sql/sql_repl.cc: When the master starts sending binlog to slave, it must first read the first few events to detect the binlog's format. Same for SHOW BINLOG EVENTS. |
||
---|---|---|
bdb | ||
BitKeeper | ||
BUILD | ||
Build-tools | ||
client | ||
cmd-line-utils | ||
dbug | ||
Docs | ||
extra | ||
heap | ||
include | ||
innobase | ||
isam | ||
libmysql | ||
libmysql_r | ||
libmysqld | ||
man | ||
merge | ||
myisam | ||
myisammrg | ||
mysql-test | ||
mysys | ||
netware | ||
NEW-RPMS | ||
os2 | ||
pstack | ||
regex | ||
scripts | ||
sql | ||
sql-bench | ||
sql-common | ||
SSL | ||
strings | ||
support-files | ||
tests | ||
tools | ||
VC++Files | ||
vio | ||
zlib | ||
.bzrignore | ||
.cvsignore | ||
acconfig.h | ||
acinclude.m4 | ||
config.guess | ||
config.sub | ||
configure.in | ||
depcomp | ||
install-sh | ||
ltconfig | ||
ltmain.sh | ||
Makefile.am | ||
missing | ||
mkinstalldirs | ||
mytest-old.c | ||
README |
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'.