October 2010 - discuss - lists.mariadb.org

Re: [Maria-discuss] Per-db binlogging
by Weldon Whipple 14 Dec '10

14 Dec '10

Sergei, Thank you very much for your reply! A later post by Henrik Ingo seems to say that I should cc maria-discuss(a)lists.launchpad.net. I'll try it and see if it bounces--I THINK I'm registered with launchpad.net :-) Let me know if sending to both lists annoys anyone, and I will quit the cc :-) See my responses below On Wed, Sep 15, 2010 at 1:53 PM, Sergei Golubchik <serg(a)askmonty.org> wrote: > Hi, Weldon! > > On Sep 13, Weldon Whipple wrote: <snip/> >> Is it plausible to identify all places where a binlog addition might >> occur? In those places, if the singleton USER_BIN_LOG_MRG exists, ask >> it if the current DB is being binlogged. If so, send the request to >> the DB_BIN_LOG instance. > > By "addition" you mean when an event is written to binlog? Yes! (exactly)--any event relating to that database that is written to binlog. (Hmm ... I wonder if there might ever be more "global" events that should be written ... Maybe we don't care about them??). Also, since these databases are "tied" to a user on a box, we probably don't care about renaming a DB ... > See where mysql_bin_log.write is called. Excellent information! (I was hoping it might be that easy ???). If I succeed in making a DB_BINLOG class derive from MYSQL_BIN_LOG (with an instance of DB_BINLOG for each database that is currently binlogging), I could--in theory, at least--just call something like db_binlog->write () at those places. > >> Questions I Have. >> ---------------- >> >> 1. I notice that binlog is in the list of engines and plugins >> (displayed by SHOW ...). The bottom of log.cc has >> "mysql_declare_plugin(binlog)". Do I need one for db_plugin? >> (probably not?) > > depends. > binlog needs to be declated a plugin, to be able to pretent being a > storage engine, to be able to force two phase commit (2PC). > > 2PC is used to commit or rollback a transaction atomically in more than > one engine. And MySQL only uses 2PC when a transaction spans more than > one engine. But we want a transaction to be committed in the engine and > written to a binlog - and it should be done atomically too. So, binlog > pretends to be an engine, pretends to participate in a transaction, > which forces MySQL to use 2PC which can guarantee that a transaction > is either committed and written to a binlog - or not committed and not > written. Reliably, even if MySQL crashes in the middle. > > So, if you don't use innodb, or don't use > innodb_flush_log_at_trx_commit=1 or don't use sync_binlog=1 > you probably don't need to support 2PC as your setup is not crash proof > anyway. > > If you care about innodb<->binlog consistency in the presence of > crashes, you should support 2PC in your binlog, as explained above. We DO have a small percentage of innodb databases. If 2PC commits (rolls back, etc.) atomically to more than one engine, does that mean TWO (only)? ... or could it happen for three (specifically, innodb, MYSQL_BIN_LOG's binlog, and DB_BIN_LOG's binlog)? The two kinds of binlog files would have the same format (except that one is for only one database). Are they considered two storage engines/plugins? (I notice that the "mysql_declare_plugin(binlog)" declaration is at the bottom of log.cc. Most of the other storage engines' corresponding declarations are in files in the storage subdirectories. If I were to need a "mysql_declare_plugin(db_binlog)" declaration, could it also go at the bottom of log.cc? ... Or (since a DB_BINLOG is AKO [a kind of] MYSQL_BIN_LOG [in the OO sense]), are MYSQL_BIN_LOGs and DB_BINLOGs both kinds of binlog plugins ...? >> 2. I've diagrammed the binary log event taxonomy--the 24 classes that >> inherit from Log_event (in log_event.cc/h). That was my main >> motivation for wanting to inherit from MYSQL_BIN_LOG. > > Was that a question? :) No. Just justification for my desire to simplify by having DB_BINLOG extend the MYSQL_BIN_LOG class. (I realize that I MIGHT have to add "virtual" in front of a method or two--possibly. Hopefully I would need to make no--or minimal-- changes to MYSQL_BIN_LOG.) >> 3. On the other hand, I wonder if inheriting from MYSQL_BIN_LOG might >> be overkill for "master only" binlogging--without the >> slave/replication part of it. > > No, I think inheriting from MYSQL_BIN_LOG is correct. > At least it's much easier to build on existing binlogging than to > implement everything from scratch. Amen!! >> 4. What version should I be working on? (We're currently running >> 5.1.47.) What should I check out of bzr/launchpad? (Is that still >> what we're doing with the changes in ownership?) > > What version you plan to use? > If it'll be 5.1 - you have to work in 5.1, use lp:mysql-server/5.1 > branch: > > bzr branch lp:mysql-server/5.1 We TRY to keep as current as possible (at the company). At some point, we'll need to move to the next major release--whatever it ends up being. (Then there is also the unknown [to me] of MySQL vs. MariaDB ... :-) We'll use bzr branch lp:mysql-server/5.1 > >> 5. I see that THD is involved in binlogging. (Several THD methods are >> defined in log.cc.) Are there any caveats here? > > There is a binlog cache (or buffer) in THD that stores binlog events for > the current transaction. They all are written to disk together, when a > transaction is committed. You need to decide what you want to do when > the current database is changed in the middle of a transaction - what > binlog the transaction should be written to. By "the current database is changed", I imagine you refer to the "USE 'database';" command. That's a good question. I THINK we have decided to ignore (for the present, at least), queries (and also transactions?) that involve multiple databases. Because we are doing per-DB binlogging, if multiple databases are involved, we (almost) consider it an anomaly at our ISP ... (I'm thinking that we might need to consider THD's binlog cache only for transactions that involve innodb and no more than one database ...) >> 6. What files should I use? A new h/cc pair? ... or just add to the >> hierarchy in log.h/cc? > > As you like. > New pair of files is cleaner. But it may require you to move some > declarations from log.cc to a header file, or to make some static > functions extern. All my prototypes have just expanded what is in log.cc and log.h. (I came VERY close to creating db_binlog.cc/h, however, which I would have done in some of my past--non-MySQL--projects). However, noticing most of the logging hierarchy in the single log.cc/h pair, I decided the implementors must have done it for a reason, and have decided to follow suit--for now, at least. > >> What I've Implemented So Far (about 13 Prototypes). >> -------------------------------------------------- >> >> (PRELIMINARY NOTE:) >> >> Our initial plan was to call it "Per-User Binlogging". The user here >> is a cPanel [control panel] user. cPanel's database naming convention >> is to have all of a user's database names start with the username, >> followed by an underscore, followed by a distinctive database >> name. Thus all the commands above start with >> >> <verb> USER ... >> >> Originally most of them could end either "DATABASE <db>" or "USER >> <user>" (with user meaning cPanel user). Thus, in the original plan >> the first command above was: >> >> START USER BINLOG FOR (USER <user> | DATABASE <db>) >> >> We have realized that per-database binlogging is all we really need. >> We imagine that others in our situation might want something similar. >> Since not everyone uses cPanel, we should forget per[cPanel]-user >> binlogging, focusing on per-database binlogging. > > If every user is a different MySQL account - that it a different row in > the mysql.user table - than per-user binlogging is much cleaner and > better defined concept. > > A statement can affect more than one database (say, UPDATE db1.t1, > db2.t2 SET ...), the current database may be changed in the middle of > transaction, and so on. On the other hand, any statement or a > transaction is always executed in the context of as single user - you > cannot change user in the middle of transaction. (*) > > (*) changing security context only affect privileges, but not the > destination binlog. Actually (and this is because of the way cPanel does things--I have been "bitten" by this many times!!), each database has a (different) corresponding user in the mysql.user table (!!!). So (for example), if a user signs up with our ISP with a user name of elvispre every one of his (perhaps hundreds/thousands of) databases will have names something like: elvispre_friends elvispre_earlyyears elvispre_hitsongs . . . And (here's the surprising part)--each one of those databases will have a MATCHING ROW IN mysql.user!! So, for us to migrate our customer elvispre to another physical server, we DO (ultimately) need to binlog all of the databases/users that match/are like 'elvispre\_%'; . In some of my earlier prototypes, the START/FLUSH-LOCK/SHOW/UNLOCK/STOP commands have allowed for "like" clauses at the end. Maybe I need to go that route? ALL of my prototypes have had binlogging PER DATABASE. I wonder how difficult/feasible/desirable/useful it would be to create separate binlog files for databases (or users) whose name matches a "like" clause. ... Probably more important: Would this feature be of general interest to the MySQL user community at large? (... and, if so, should it be database- or user- or database_pattern- or user_pattern-based). (My initial idea is that per [single] database/user might be easiest to define/implement??) > > Regards, > Sergei Thanks again for your reply!! Weldon

2 4

Re: [Maria-discuss] How to lock individual tables in 1-db-per-file binlogging (Was: Re: Per-db binlogging)
by Weldon Whipple 29 Oct '10

29 Oct '10

Dmitry, Thank you very much for your response! (I apologize for the slowness of my reply. I've been fighting a cold for several days.) See below: On Thu, Oct 21, 2010 at 11:15 PM, Dmitry Lenev <Dmitry.Lenev(a)oracle.com> wrote: > Hello Weldon! > > * Weldon Whipple <weldon(a)whipple.org> [10/10/20 00:26]: >> Thanks for the great feedback. It got me looking at the capabilities >> of MySQL 5.5. >> >> It's POSSIBLE that the new syntax: >> >> FLUSH TABLES t1, t2, t3, ... , tn WITH READ LOCK >> >> is PRECISELY the functionality we need! >> >> Our (perl) migration script MIGHT (for example) do the following: >> >> Issue the following command (implemented by me ...): >> >> 1. START BINLOG FOR DATABASE <db>; >> >> (for each database a given user owns. [Hmmm... Maybe my implementation >> allows multiple <db> arguments. I need to check.] Each database would >> start binlogging to its own file. [We will configure--in my.cnf--the >> 1-database-per-file binlogs to be stored on a very fast solid-state >> drive.]) >> >> Then the script creates a list of all tables in all the user's >> databases being migrated to another server and issues the command (new >> to MySQL 5.5): >> >> 2. FLUSH TABLES t1, t2, t3, ..., tn WITH READ LOCK; >> >> (where the tables t1, t2, ..., tn are the tables being migrated.) >> >> Then issue the following command (implemented by me ...): > > AFAIU you also want to prohibit creation of tables in this database > after this point as otherwise you can't guarantee binlog stability. > Also what about non-table objects like stored routines - don't you > want to block their modification as well? The above statement won't > provide this as it locks only *existing* *tables*. > > OTOH in my opinion it should be fairly easy to implement functionality > that you need (i.e. blocking of all DDL and DML that changes data in > database) on the basis of FLUSH TABLES <table_list> WITH READ LOCK > implementation. You just need to take database-scope S metadata lock > in addition to locking and flushing all tables in database. Such lock > will block creation of new tables and any DDL on stored routines in > the database. Maybe I need to implement a new command (something like FLUSH DATABASE db WITH READ LOCK) that--conceptually, at least--read locks all the tables in the database (like FLUSH TABLES ... WITH READ LOCK) *as well as* blocks all DDL and DML that changes data in database. I'll look through the code and find where FLUSH TABLES ... WITH READ LOCK is implemented. If I can't figure out how to "take database-scope S metadata lock," I'll get back with you... (I suppose I'll need a corresponding UNLOCK DATABASES command as well.) I've observed (and read) that the read locks are held as long as the client connection remains open, and that the UNLOCK applies to all the locks created during the same connection that created the read locks. I guess that means that our migration tool will need to maintain the connection with mysqld while it dumps (or scp's, in the case of MyISAM tables) the database snapshot. (That shouldn't necessarily be a problem--it's just something we need to be aware of. It makes sense for it to work that way.) > >> >> BUG IDENTIFIED. >> <snip/> > I have taken the liberty to report this issue as bug #57649 > (http://bugs.mysql.com/bug.php?id=57649). > > Thanks for pointing it out! Thanks for reporting it. > >> >> QUESTION: >> I read that Larry Ellison stated (at a conference) that 5.5 would be >> out by year end. How likely is that? Our company generally waits for >> some point releases before changing our customer boxes to the next >> release. >> >> Should I try to back port those locks to 5.1 in the interim? ... or >> leave well enough alone? > > I don't think it makes sense to backport metadata locks to 5.1 as it is > likely to require back-porting of too much other changes from 5.5. > > OTOH implementing what you need on top of infrastructure already present > in 5.1 is likely to require significant efforts as well. > > So I think it is better to base your work on 5.5 tree. I agree. There are quite a few major changes in 5.5. I haven't noticed meta-data-locks (MDL) before. The PSI additions to the mutex and conditions also look new. (I'm sure I'm missing lots of other changes.) (Regarding the PSI_mutex_key, PSI_rwlock_key and similar additions: I've tried to follow the patterns in 5.5 as I added my own mutexes. I'm assuming [hoping?] that they work when multiple instances of an object all refer to the same-named PSI_xxx-key ??? ...) (Is there any externally available documentation on MySQL's use of PSI?) > > Best regards, > -- > Dmitry Lenev, Software Developer > Oracle Development SPB/MySQL, www.mysql.com > > Are you MySQL certified? http://www.mysql.com/certification Not that I know of. Weldon Whipple weldon(a)whipple.org

2 2

Re: [Maria-discuss] italian translation
by Bryan Alsdorf 26 Oct '10

26 Oct '10

Hi, On 09/14/2010 11:24 PM, Colin Charles wrote: > Hi! > > On 12 Sep 2010, at 07:51, Federico Razzoli wrote: > >> Hello. >> >> I appreciate so much your new Knowledge Base. The pages that are already on line >> are very clear and complete, as the MySQL docs. But, unlike the MySQL docs, the >> Knowledge Base has free licenses. For these reasons, I would like to translate >> into italian - which is my natural language. >> >> Am I allowed to do that? As far as I understand, both the licenses used (CC >> BY-SA and GNU FDL) allow translations, as long as they have the same licenses >> used by the original work. But I want to be sure before starting. >> >> I can't translate all the articles, so I'll only translate some of the most >> interesting documents. But, as the documentation grows, maybe I may try to set >> up a group of volounteers. We'll see. > > > You are absolutely allowed to do that. You can translate it to Italian with no issue at all > > Currently (and I think, by design) it seems that kb.askmonty.org will be in the English language. Bryan (CC'ed in this email) is the right person to help setup an instance for the Italian language (something like it.kb.askmonty.org) if you were planning on making a larger translation project. It would be great if you could harness a group of volunteers We actually want to setup a structure to support translations inside our KB, I just haven't had the time to design or implement it. My two concerns are how to properly display content in another language and how to keep translated articles up to date when the English version is updated (or vice versa). If you have any ideas, please let me know. > In the meantime however, as you'd like to just translate interesting documents, just go ahead, translate them, and it would rock if you'd point folk to the English version at the askmonty KB > > Good luck with your translation work and tell us if you need any help! Yes please let us know if there is anything we can do to help. I will try to work on supporting other languages soon since people are actually translating articles. Best Regards, -- Bryan Alsdorf, Lead Web Developer Monty Program AB. http://montyprogram.com

4 4

Re: [Maria-discuss] How to lock individual tables in 1-db-per-file binlogging (Was: Re: Per-db binlogging)
by Weldon Whipple 19 Oct '10

19 Oct '10

Davi, Sergei (and everyone else), Thanks for the great feedback. It got me looking at the capabilities of MySQL 5.5. It's POSSIBLE that the new syntax: FLUSH TABLES t1, t2, t3, ... , tn WITH READ LOCK is PRECISELY the functionality we need! Our (perl) migration script MIGHT (for example) do the following: Issue the following command (implemented by me ...): 1. START BINLOG FOR DATABASE <db>; (for each database a given user owns. [Hmmm... Maybe my implementation allows multiple <db> arguments. I need to check.] Each database would start binlogging to its own file. [We will configure--in my.cnf--the 1-database-per-file binlogs to be stored on a very fast solid-state drive.]) Then the script creates a list of all tables in all the user's databases being migrated to another server and issues the command (new to MySQL 5.5): 2. FLUSH TABLES t1, t2, t3, ..., tn WITH READ LOCK; (where the tables t1, t2, ..., tn are the tables being migrated.) Then issue the following command (implemented by me ...): 3. SHOW DATABASE BINLOG STATUS; which shows--for each database being binlogged to its own file: a. the database name b. whether binlogging is active c. the name of the current binlog file d. the binlog position in that file. The script captures the coordinates, then 4. Creates a copy of the database(s) using mysqldump or scp/tar/gzip, etc. (MyISAM databases will probably just be copied "raw," because it is much faster. Innodb will probably have to use mysqldump or something similar.) 5. UNLOCK TABLES: On the new server, the copied/mysqldump'ed files will be used to bring up the mysql on the new server. At some future time--hopefully SOON--the tables could be locked again. For any where the coordinates have changed: The binlog file(s) would be copied to the new server, "played" by mysqlbinlog, and the new server would be brought online on the new box and taken offline on the old. When the migration is determined to be complete, issue this command (implemented by me) on the old box: 6. STOP BINLOG FOR DATABASE <db>; for all the user's databases ... and the migration is done. QUESTIONS/ASSUMPTIONS: 1. In playing with the new FLUSH TABLES t1, t2, ..., tn command, I've noticed that if the connection drops, the locks are all unlocked. ... So our scripts will have to make sure the connection stays up. (ANY SUGGESTIONS?) 2. The UNLOCK TABLES command unlocks all the tables locked earlier in the same session. (So it doesn't need the variable argument list of tables to unlock ...) A post on dev.mysql.com shows the following possible sequence of commands: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; SYSTEM xfs_freeze -f /var/lib/mysql; SYSTEM YOUR_SCRIPT_TO_CREATE_SNAPSHOT.sh; SYSTEM xfs_freeze -u /var/lib/mysql; UNLOCK TABLES; EXIT; (The FLUSH TABLES command would correspond to #2 above. SHOW MASTER STATUS would correspond to #3 above. UNLOCK TABLES would correspond to #5 above. The SYSTEM commands would have to be replaced by our own commands/scripts.) Would running (sub-)scripts from SYSTEM commands inside MySQL be sufficient to hold the locks? BUG IDENTIFIED. I noticed the following mysqld-crashing bug--in 5.5.6 rc as well as the one I modified: 1. FLUSH TABLES t1, t2, t3, ..., tn WITH READ LOCK; 2. FLUSH TABLES; The second FLUSH TABLES (with no added tokens) crashes at mdl.cc:1563 : DBUG_ASSERT(mdl_request->type != MDL_EXCLUSIVE || is_lock_owner(MDL_key::GLOBAL, "", "", MDL_INTENTION_EXCLUSIVE)); because is_lock_owner() returns NULL when FLUSH TABLES is called immediately after FLUSH TABLES [with additional args]; QUESTION: I read that Larry Ellison stated (at a conference) that 5.5 would be out by year end. How likely is that? Our company generally waits for some point releases before changing our customer boxes to the next release. Should I try to back port those locks to 5.1 in the interim? ... or leave well enough alone? Thanks in advance for your feedback/help/advice!! We.don Whipple On Mon, Oct 18, 2010 at 12:48 PM, Davi Arnaut <davi.arnaut(a)oracle.com> wrote: > On 10/18/10 3:16 PM, Weldon Whipple wrote: >> >> Well, I finished a working prototype that does everything except the >> locking and unlocking of databases. Someone mentioned that it's now >> possible to lock individual tables. Would you--anyone--be willing to >> point me toward places in the 5.5 code that use that >> locking/unlocking? >> > > Do you want to lock the database, or individual tables, or both? Anyway, > take a look at mysql_rm_db as the locking is all very similar. Roughly, the > algorithm of a DROP DATABASE is: > > // Protect against other schema operations > lock_schema_name("db1"); > // Build list of tables in the db1 directory > table_list = .. > // Initialize metadata lock request > table_list->mdl_request.init(MDL_key::TABLE, > table_list->db, > table_list->table_name, MDL_EXCLUSIVE); > // Lock tables > lock_table_names(thd, tables, NULL ...) > // Remove from cache and drop the table... > > The best thing at this point is to study (and debug) a similar statement and > understand how metadata locks work (mdl prefix) or how tables are > open/locked. > > Regards, > > Davi > > -- > MySQL Internals Mailing List > For list archives: http://lists.mysql.com/internals > To unsubscribe: http://lists.mysql.com/internals?unsub=weldon@whipple.org > >

1 0

Re: [Maria-discuss] How to lock individual tables in 1-db-per-file binlogging (Was: Re: Per-db binlogging)
by Weldon Whipple 18 Oct '10

18 Oct '10

Davi, Thanks for the pointers! I'd like to lock an entire database. (I guess I can iterate through the tables in database if that's the only way. [I suppose there might be possible locking issues to deal with ...]) I'll look at the source you recommend ... Weldon weldon(a)whipple.org On Mon, Oct 18, 2010 at 12:48 PM, Davi Arnaut <davi.arnaut(a)oracle.com> wrote: > On 10/18/10 3:16 PM, Weldon Whipple wrote: >> >> Well, I finished a working prototype that does everything except the >> locking and unlocking of databases. Someone mentioned that it's now >> possible to lock individual tables. Would you--anyone--be willing to >> point me toward places in the 5.5 code that use that >> locking/unlocking? >> > > Do you want to lock the database, or individual tables, or both? Anyway, > take a look at mysql_rm_db as the locking is all very similar. Roughly, the > algorithm of a DROP DATABASE is: > > // Protect against other schema operations > lock_schema_name("db1"); > // Build list of tables in the db1 directory > table_list = .. > // Initialize metadata lock request > table_list->mdl_request.init(MDL_key::TABLE, > table_list->db, > table_list->table_name, MDL_EXCLUSIVE); > // Lock tables > lock_table_names(thd, tables, NULL ...) > // Remove from cache and drop the table... > > The best thing at this point is to study (and debug) a similar statement and > understand how metadata locks work (mdl prefix) or how tables are > open/locked. > > Regards, > > Davi > > -- > MySQL Internals Mailing List > For list archives: http://lists.mysql.com/internals > To unsubscribe: http://lists.mysql.com/internals?unsub=weldon@whipple.org > >

1 0

[Maria-discuss] How to lock individual tables in 1-db-per-file binlogging (Was: Re: Per-db binlogging)
by Weldon Whipple 18 Oct '10

18 Oct '10

Thanks, Sergei and everyone else, for your feedback/ideas! Well, I finished a working prototype that does everything except the locking and unlocking of databases. Someone mentioned that it's now possible to lock individual tables. Would you--anyone--be willing to point me toward places in the 5.5 code that use that locking/unlocking? I'm interested in sharing the changes with the community if there is any interest. (Any suggestions about whether I should prefer launchpad versus forge.mysql.com or some other place to share? [I once owned a project on SourceForge--I think it's still there, but not very active ...]. :-) A few comments in response to your comments: On Thu, Sep 16, 2010 at 6:34 AM, Sergei Golubchik <serg(a)askmonty.org> wrote: > Hi, Weldon! > > On Sep 15, Weldon Whipple wrote: >> >> > See where mysql_bin_log.write is called. >> >> Excellent information! (I was hoping it might be that easy ???). If I >> succeed in making a DB_BIN_LOG class derive from MYSQL_BIN_LOG (with an >> instance of DB_BIN_LOG for each database that is currently binlogging), >> I could--in theory, at least--just call something like >> db_binlog->write () at those places. > > Better make this write method virtual and implement it in your derived > class. I did implement it as a derived class, but it was a bit more work than just reimplementing the ::write() method. (I use separate instances of DB_BINLOG--the derived class--for each database that is binlogging to its separate binlog file [sequence].) I had to have a few additional methods (extremely small) to set up for opening files named <database>-bin.<seq#>, <database>-bin.index, etc. I also maintain a db_binlog.info file that remembers the databases being binlogged across restarts. One major change was in the way the global MYSQL_BIN_LOG class is referenced. In the original code, it comes into existence at the top of binlog.cc. Before I started making my modifications, I changed MYSQL_BIN_LOG to be a pointer to MYSQL_BIN_LOG, declared in mysqld.cc (and extern'ed in mysqld.h). At the point in mysqld.cc where mysql_bin_log is first referenced I "new" the global instance of MYSQL_BIN_LOG*. I went through all the files that reference mysql_bin_log and made the necessary changes so that mysql_bin_log works as a pointer. (Example: Change "mysql_bin_log.is_active()" to "mysql_bin_log->is_active().) Also, before, referencing mysql_bin_log*, I always make sure it is non-NULL ... Then I made my changes for 1 db-per-file binlogging, using #ifdef HAVE_DB_BINLOG/#endif blocks to allow building with or without 1-db-per-file binlogging. As I'm typing this post, I'm running mysql-test-run.pl on a build without HAVE_DB_BINLOG defined and it seems to be passing all the tests. I need to write additional test cases for when HAVE_DB_BINLOG is defined ... Thanks in advance for ideas/suggestions (as well as for the ideas in the past). Weldon Whipple weldon(a)whipple.org (I'll leave the conversations below to help refresh your memory on this thread's past.) > >> >> Questions I Have. >> >> ---------------- >> >> >> >> 1. I notice that binlog is in the list of engines and plugins >> >> (displayed by SHOW ...). The bottom of log.cc has >> >> "mysql_declare_plugin(binlog)". Do I need one for db_plugin? >> >> (probably not?) >> > >> > depends. >> > binlog needs to be declated a plugin, to be able to pretent being a >> > storage engine, to be able to force two phase commit (2PC). >> > >> > 2PC is used to commit or rollback a transaction atomically in more >> > than one engine. And MySQL only uses 2PC when a transaction spans >> > more than one engine. But we want a transaction to be committed in >> > the engine and written to a binlog - and it should be done >> > atomically too. So, binlog pretends to be an engine, pretends to >> > participate in a transaction, which forces MySQL to use 2PC which >> > can guarantee that a transaction is either committed and written to >> > a binlog - or not committed and not written. Reliably, even if MySQL >> > crashes in the middle. >> > >> > So, if you don't use innodb, or don't use >> > innodb_flush_log_at_trx_commit=1 or don't use sync_binlog=1 you >> > probably don't need to support 2PC as your setup is not crash proof >> > anyway. >> > >> > If you care about innodb<->binlog consistency in the presence of >> > crashes, you should support 2PC in your binlog, as explained above. >> >> We DO have a small percentage of innodb databases. If 2PC commits >> (rolls back, etc.) atomically to more than one engine, does that mean >> TWO (only)? ... or could it happen for three (specifically, innodb, >> MYSQL_BIN_LOG's binlog, and DB_BIN_LOG's binlog)? > > See http://en.wikipedia.org/wiki/Two-phase_commit_protocol > > It's two phases, not two engines, any number of engines can participate > in a transaction. > > But! All of them but one have to support two-phase commit. Binlog does > not support it. Apparently, DB_BIN_LOG will not support it either - > adding two-phase commit support to binlog will surely be beyond the > scope of your work. > > It means, you cannot have InnoDB, binlog, and DB_BIN_LOG to participate > in a two-phase commit. But you can disable MYSQL_BIN_LOG altogether and > only use DB_BIN_LOG - in that case you can have a two-phase commit > between DB_BIN_LOG and InnoDB. > >> The two kinds of binlog files would have the same format (except that >> one is for only one database). Are they considered two storage >> engines/plugins? > > If you want to write to both - yes. A transaction will need to be > written to both independently, so you want them to be in sync, and MySQL > uses 2PC to synchronize different data storages. > > You can solve that by > > 1) not using MYSQL_BIN_LOG. In this case there's only InnoDB and > DB_BIN_LOG to keep in sync, and InnoDB can do 2PC. > > 2) not making DB_BIN_LOG independent from MYSQL_BIN_LOG. For example, > everything is written to binlog only. Then you have a background > thread (or even a separate process) that reads binlog and writes your > per-db binlogs. In that case you have only InnoDB and MYSQL_BIN_LOG > to keep in sync, and MySQL already does that. Your background thread > is only catching up, it is allowed to fall behind. > >> (I notice that the "mysql_declare_plugin(binlog)" declaration is at >> the bottom of log.cc. Most of the other storage engines' corresponding >> declarations are in files in the storage subdirectories. If I were to >> need a "mysql_declare_plugin(db_binlog)" declaration, could it also go >> at the bottom of log.cc? ... Or (since a DB_BIN_LOG is AKO [a kind of] >> MYSQL_BIN_LOG [in the OO sense]), are MYSQL_BIN_LOGs and DB_BIN_LOGs >> both kinds of binlog plugins ...? > > if you want to have two plugins in one file you still need to use one > mysql_declare_plugin(), not two. See example at the end of > http://www.packtpub.com/article/look-inside-mysql-daemon-plugin > > Regards, > Sergei >

1 0

[Maria-discuss] WL #47
by Oleg Tsarev 13 Oct '10

13 Oct '10

Hello Maria! https://code.launchpad.net/~percona-dev/percona-server/release-5.1.49-12-rnt When i build this branch: cd Percona-Server/ && ./BUILD/autorun.sh && ./configure --prefix=/usr/local/mysql --exec-prefix=/usr/local/mysql --bindir=/usr/local/mysql/bin --sbindir=/usr/local/mysql/bin --sysconfdir=/etc --datadir=/usr/local/mysql/share --includedir=/usr/local/mysql/include --libdir=/usr/local/mysql/lib --libexecdir=/usr/local/mysql/bin --with-client-ldflags=-all-static --localstatedir=/var/lib/mysql --sharedstatedir=/usr/local/mysql/com --mandir=/usr/local/mysql/man --infodir=/usr/local/mysql/share/info --enable-shared --enable-static --enable-assembler --enable-local-infile --with-mysqld-user=mysql --with-unix-socket-path=/var/lib/mysql/mysql.sock --with-pic --with-extra-charsets=complex --with-ssl --enable-thread-safe-client --with-readline --without-plugin-ndbcluster --without-plugin-maria --without-plugin-innobase --with-plugin-innodb_plugin --with-plugin-partition --with-plugin-csv --with-plugin-archive --with-plugin-blackhole --with-plugin-federated --without-embedded-server --without-bench --with-zlib-dir=bundled --with-big-tables && make -j3 And then run tests: cd mysql-test && ./mysql-test-run main.ctype_cp932_binlog_stm I get test error: worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009 main.ctype_cp932_binlog_stm [ fail ] Found warnings/errors in server log file! Test ended at 2010-10-13 08:02:25 line 101013 18:02:25 [ERROR] Error in Log_event::read_log_event(): 'Event too big', data_len: 50724864, event_type: 0 ^ Found warnings in /mnt/data/home/oleg.tsarev/12687/Percona-Server/mysql-test/var/log/mysqld.1.err ok - saving '/mnt/data/home/oleg.tsarev/12687/Percona-Server/mysql-test/var/log/main.ctype_cp932_binlog_stm/' to '/mnt/data/home/oleg.tsarev/12687/Percona-Server/mysql-test/var/log/main.ctype_cp932_binlog_stm/' ------------------------------------------------------------ The servers were restarted 0 times Spent 0.000 of 1 seconds executing testcases mysql-test-run: WARNING: Got errors/warnings while running tests, please examine '/mnt/data/home/oleg.tsarev/12687/Percona-Server/mysql-test/var/log/warnings' for details. Completed: Failed 1/1 tests, 0.00% were successful. Failing test(s): main.ctype_cp932_binlog_stm I found, what reason of this bug - our patch wl47.patch. I try to fix this bug, but i know replication not enough for this. Do you know about this trouble with WL #47? Best regards, Oleg --- Oleg Tsarev, Software Engineer, Percona Inc.

1 0

[Maria-discuss] improving the thread/connection pool
by MARK CALLAGHAN 11 Oct '10

11 Oct '10

I think more work needs to be done on the MariaDB thread/connection pool. Does a worklog exist for that? The problems are: * multi-core performance * stalled threads stall the pool This is based on my review and testing of the feature in MySQL 6.0 and quickly browsing the code in MariaDB. I also fixed multi-core performance as a proof of concept but don't have access to that patch. The multi-core performance problem occurs because only one event_base instance is used (see sql/scheduler.cc). Note that memcache uses one per CPU core. This is a big source of mutex contention. An additional problem is that EPOLLONESHOT is not used. I don't know if libevent supports that yet. Were it used one less interaction with libevent would be needed per query. I reported the performance issue at http://bugs.mysql.com/bug.php?id=42288 An interesting decision when there are multiple event_base instances is whether the mapping between an event_base instance and connections is fixed. If it is fixed then there is less libevent work to do per-query and there will be less mutex contention. But if connections cannot migrate between event_base instances per query then there will be cases where too many pending queries wait for one and no pending queries exist for others. I think that stalls are another problem to fix. When a user connection blocks on a row lock wait or another internal locks (and calls THD::enter_cond), then this is an opportunity to count this connection as not running and schedule another thread. This isn't a trivial problem to fix because it might require a new thread to be created. There is also the issue of what to do when another connection has been scheduled. In that case does the thread that just became runnable get to run immediately? If it was just granted a row lock or other lock then we want it to run right away. But that might cause X+1 threads to be running in the thread pool when the limit is X. The difference between X and X+1 is small. But this could lead to 2*X threads running. What is the limit? -- Mark Callaghan mdcallag(a)gmail.com

1 0