Cristian, for future reference, please always CC your emails regarding MySQL to
the appropriate list in addition to e-mailing the developer. Otherwise, if the
developer is sick or travelling, it will be a while before you get a response
>are there any plans to make the replication more customizable ?
>My idea would be a table like the grant-tables to tell MySQL which tables to bin-log.
>| Database | Table |
>| mydb1 | % |
>| mydb2 | table1|
>Then you would need a command 'flush replication' or so, to apply changes.
I know it's a lot of work, and I would try it myself if I had more time and
The problem with that is that it would make it replication slower (as it takes
more work to figure out that a certain table should not be replicated, but it is
much simpler for the whole database), and will not work very well for queries
that modify more than one table. If you do not want certain queries to be
replicated, you can currently do one of the following:
* give your clients the PROCESS privilege and exectue SET SQL_LOG_BIN = 0
before queries that should not be replicated
* create a separate database, no_repl_db, run master mysqld with
binlog-ignore-db=no_repl_db, and exectue use no_repl_db before queries that
should not be replicated ( in this case the tables should be referenced with
their full name including the name of the database
* create no_repl_db, use no_repl_db; run the slave with
>In the TODO is the point 'Fail safe replication' on place 1, hope it will be done soon
>For some cases it would be better if you would log actions and not querys. But it
> would surely kill the >performance.
Yes, you are right - the actions give you better granularity, but terrible
performance for queries that modify a lot of rows.
>AND the replication runs much better since I disabled the code with the 'goto err;'
> near line 928 in >slave.cc (3.23.26) ;)
In other words, just barge along if the data on the slave is inconsistent as if
nothing happened. This generally not a good idea - a query that succeeded on the
master should never fail on the slave. If it does, one should investigate why,
and fix the bug. This usually results from modifying the slave table under the
feet of the slave thread.
>BTW: It's cool that MySQL is so fast. Oracle 8i died as we tried to store our
> realtime-stockdata in it. 200 >inserts/second was too
>much for it. MySQL made it up to 3000 ;)
So did MySQL actually survive and just did not increase in throughput as you
kept increasing the load, or did it die? If it did, it would be nice to
investigate why - it should give messages if it is out of resources, and still
continue working the best it can.
>Only the replication fails now an then with something about >bogus-data :(
See my comments above - if your slave tables are thrown out of sync with the
master by some extrenal updates, you need to figure out who is doing that and
punish him :-) If you do not have any external updates, then it is a bug that we
need to find and fix. Another reason for this could be if you are using
>Christian "Maverick" Rabe
>Tel.: 03 37 01 5 29 16
>Fax.: 03 37 01 5 29 19
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <sasha@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA