RE: ndb_restore is not restoring users and grants
By default, the mysql users/privileges tables are MyISAM, not ndbcluster. ndb_mgm backup won't backup anything other than ndbcluster tables. The --restore-privilege-tables only works if you've converted those user and privileges tables to ndbcluster. From the manual: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-programs-ndb-restore.html#option_ndb_restore_restore-privilege-tables --restore-privilege-tables ndb_restore does not by default restore distributed MySQL privilege tables (MySQL Cluster NDB 7.2.0 and later). This option causes ndb_restore to restore the privilege tables. This works only if the privilege tables were converted to NDB before the backup was taken. I have been using this setup and it works well: http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-privilege-distribution.html It basically creates backups of the user and privileges tables, then converts them to ndbcluster. This allows you to back them up through ndb_mgm and also allows you to use the same users/privileges across all the SQL nodes in the cluster. Hope this helps. -Original Message- From: Bheemsen Aitha [mailto:pgb...@motorola.com] Sent: Tuesday, October 30, 2012 12:09 AM To: mysql@lists.mysql.com Subject: ndb_restore is not restoring users and grants Hi, I was able to backup my cluster using ndb_mgm and also restore using ndb_restore. However, when everything looks fine after restore, I see that users and grants are not restored. So, does ndb_restore restore all databases including information_schema and mysql databases, plus users and grants? Am I missing something? Do I need to do anything after restore step? here are the commands I used for restore. ndb_restore -c hostname -s -n 1 -m -b 3 -r --restore-privilege-tables=true --backup_path=/opt/app/mysql_data01/ndb_backup/BACKUP/BACKUP-3/ ndb_restore -c hostname -s -n 2 -b 3 -r --restore-privilege-tables=true --backup_path=/opt/app/mysql_data02/ndb_backup/BACKUP/BACKUP-3/ I really appreciate any help on this. Thanks -bheem Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LBI may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Dumping drupal databases
* Johan De Meersman vegiv...@tuxera.be [121031 07:10]: Given the different location of the datafiles and assuming the actual drupal does work, I'm starting to suspect that whatever installer you used created a second instance of mysql. Your drupal configfile should hold the necessary data to connect to it. You are correct. Running on 3307. (from settings.php) But even loging into that instance was not showing me the drupal databases - so I was stumped! I would guess that was because the 3307 instance was using the system-wide my.cnf instead of the drupal my.cnf. I could not see from documentation how to invoke mysql or mysqldump with a specific my.cnf. See my response to your other email. thanks Johan -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Dumping drupal databases
* Johan De Meersman vegiv...@tuxera.be [121031 07:10]: Tim Johnson t...@akwebsoft.com wrote: * Ananda Kumar anan...@gmail.com [121030 09:48]: why dont u create a softlink From /opt/local/var/db/mysql5/ to /opt/local/var/db/mysql5/ ??? I can try that, but I am doing things to MySQL that I have never done before and I am reluctant to risk clobbering a complex development environment that has nothing to do with drupal. After all, I am just playing with drupal. I'd welcome your elaboration or a second opinion. If I'm right about the second instance, that will cause the files to be opened by both daemons. Which is rather on the bad side of things. Sounds like good judgement on your part. As I have already posted to the ML, I was forced to use the drupal backup_migrate module. When in drupal do as the drupals do. cheers -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Dumping drupal databases
Am 31.10.2012 16:34, schrieb Tim Johnson: * Johan De Meersman vegiv...@tuxera.be [121031 07:10]: Given the different location of the datafiles and assuming the actual drupal does work, I'm starting to suspect that whatever installer you used created a second instance of mysql. Your drupal configfile should hold the necessary data to connect to it. You are correct. Running on 3307. (from settings.php) But even loging into that instance was not showing me the drupal databases - so I was stumped! I would guess that was because the 3307 instance was using the system-wide my.cnf instead of the drupal my.cnf. I could not see from documentation how to invoke mysql or mysqldump with a specific my.cnf. See my response to your other email. thanks Johan you MUST NOT use localhost if you want to connect to a different mysqld-port because localhost is unix-socket mysql -h 127.0.0.1 --port=3307 -u username -p signature.asc Description: OpenPGP digital signature
RE: what is stored in /var/lib/mysql_log/ ?
The 2 (possibly more) iblog files are necessary for the inner workings of InnoDB. They do not change in size. They should not (normally) be removed or otherwise tampered with. No useable data is stored there -- that is, they cannot be used for any form of disaster recovery. Tunable things for InnoDB can be found in my.cnf (my.ini). They can be viewed (mostly) via SHOW VARIABLES LIKE 'innodb%'; Current status: SHOW GLOBAL STATUS LIKE 'Innodb%'; SHOW ENGINE INNODB STATUS; All of MySQL (not just InnoDB) needs tmp space for _some_ queries. It is normally not be this same directory, but it is probably harmless if it is. -Original Message- From: walter harms [mailto:wha...@bfs.de] Sent: Sunday, October 28, 2012 2:05 PM To: mysql@lists.mysql.com Subject: Re: what is stored in /var/lib/mysql_log/ ? Am 28.10.2012 21:50, schrieb Reindl Harald: Am 28.10.2012 21:29, schrieb walter harms: hi list, on my system this this directory contains ib_logfile0/ib_logfile1, so far no problem. From the documentation i had the impression that this is everything and the files size should not change. but it seems that immodb also uses this space for temp space, do they make a copy of ib_logfile here ? please provide a directory listing so that anybody get a clue what you are speaking about! sorry, I tend to forget that no everyone has the same configuration :( on my system /var/lib/mysql_log -rw-rw 1 mysql mysql 268435456 Oct 28 19:20 ib_logfile0 -rw-rw 1 mysql mysql 268435456 Oct 19 23:03 ib_logfile1 but i guess i just found what is going on: innodb_log_group_home_dir=/var/lib/mysql_log tmpdir=/var/lib/mysql_log I was always looking for innodb related configuration/problems but i guess the strange files that appeared (and related problems) where perhaps caused by tmpdir :) ntl, thx re, wh -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: what is stored in /var/lib/mysql_log/ ?
Am 31.10.2012 17:31, schrieb Rick James: The 2 (possibly more) iblog files are necessary for the inner workings of InnoDB. They do not change in size. They should not (normally) be removed or otherwise tampered with. No useable data is stored there -- that is, they cannot be used for any form of disaster recovery. Tunable things for InnoDB can be found in my.cnf (my.ini). They can be viewed (mostly) via SHOW VARIABLES LIKE 'innodb%'; Current status: SHOW GLOBAL STATUS LIKE 'Innodb%'; SHOW ENGINE INNODB STATUS; Hi Rick, thx for your help. I have found the root cause that was not related to immodb. It was that tmpdir was pointing to the same space. This were no problem for a long time then something happended, the system was optimizing and was running out of space causing a table corruption (why can a failed optimisation cause a table corruption ?) re, wh All of MySQL (not just InnoDB) needs tmp space for _some_ queries. It is normally not be this same directory, but it is probably harmless if it is. -Original Message- From: walter harms [mailto:wha...@bfs.de] Sent: Sunday, October 28, 2012 2:05 PM To: mysql@lists.mysql.com Subject: Re: what is stored in /var/lib/mysql_log/ ? Am 28.10.2012 21:50, schrieb Reindl Harald: Am 28.10.2012 21:29, schrieb walter harms: hi list, on my system this this directory contains ib_logfile0/ib_logfile1, so far no problem. From the documentation i had the impression that this is everything and the files size should not change. but it seems that immodb also uses this space for temp space, do they make a copy of ib_logfile here ? please provide a directory listing so that anybody get a clue what you are speaking about! sorry, I tend to forget that no everyone has the same configuration :( on my system /var/lib/mysql_log -rw-rw 1 mysql mysql 268435456 Oct 28 19:20 ib_logfile0 -rw-rw 1 mysql mysql 268435456 Oct 19 23:03 ib_logfile1 but i guess i just found what is going on: innodb_log_group_home_dir=/var/lib/mysql_log tmpdir=/var/lib/mysql_log I was always looking for innodb related configuration/problems but i guess the strange files that appeared (and related problems) where perhaps caused by tmpdir :) ntl, thx re, wh -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: index innodb
1. Secondary indexes (but not the PRIMARY KEY) requires additional disk space. A secondary index implicitly includes copies the field(s) of the PRIMARY KEY; this is how it can get to the actual data row. Finding a row via a secondary key involves two BTree lookups -- one in the secondary index, one in the primary key index (which has the data with it). 2. With file_per_table, that is in the .ibd; without file_per_table that is in ibdata1. Probably the identical amount of space either way. file_per_table is almost always the better way to go. However, it is awkward to convert a big existing system, since it is not easy to free up the space already taken by ibdata1. -Original Message- From: Pothanaboyina Trimurthy [mailto:skd.trimur...@gmail.com] Sent: Tuesday, October 30, 2012 6:35 AM To: mysql@lists.mysql.com Subject: index innodb hi lists 1. does the indexes require additional storage other than the table space storage. 2. is there any performance difference will be there, if we go for innodb_file_per_table. -- 3murthy -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: what is stored in /var/lib/mysql_log/ ?
Am 31.10.2012 19:47, schrieb walter harms: thx for your help. I have found the root cause that was not related to immodb. It was that tmpdir was pointing to the same space. This were no problem for a long time then something happended, the system was optimizing and was running out of space causing a table corruption (why can a failed optimisation cause a table corruption ?) because running out of disk space is a condition which is hard to test in any combination and should never happen signature.asc Description: OpenPGP digital signature
MySQL Thread Pool Plugin + Percona Server?
Hey, I'm looking to combine the benefits of the MySQL Thread Pool Plugin and Percona-Server. All the benchmarks show that the Thread Pool Plugin handles higher concurrency much better then just setting innodb_thread_concurrency. Alas Percona server has many tweaks that improve performance. Does anyone have any experience running Percona Server (obviously 5.5) with the Thread Pool Plugin? I got it running but was wondering if there's any caveats.. S
RE: what is stored in /var/lib/mysql_log/ ?
Oh, another issue... If you have your disk partitioned, and the tmpdir is pointing to a small partition, you could run out of room for that reason. I sometimes find a tiny boot partition (not a terrible idea), plus partitions for /tmp, /var /usr, and maybe others. (Or C:, D:, etc, if you are that type of person.) Hence, I _dislike_ splitting disks into separate filesystems. -Original Message- From: Reindl Harald [mailto:h.rei...@thelounge.net] Sent: Wednesday, October 31, 2012 11:56 AM To: mysql@lists.mysql.com Subject: Re: what is stored in /var/lib/mysql_log/ ? Am 31.10.2012 19:47, schrieb walter harms: thx for your help. I have found the root cause that was not related to immodb. It was that tmpdir was pointing to the same space. This were no problem for a long time then something happended, the system was optimizing and was running out of space causing a table corruption (why can a failed optimisation cause a table corruption ?) because running out of disk space is a condition which is hard to test in any combination and should never happen
Re: what is stored in /var/lib/mysql_log/ ?
personally i use ONLY vmware-guests for any production servers because HA/Failover and unified managmenent and a really easy way to resize drives for /var/log, /vbar/cache, /tmp and hwatever mountpoint holds data - all seperated from /boot and rootfs so it is no problem to use a own DISk for /tmp or configure the mysql-temp-fodler to a folder on a large enough disk it is really simple to calculate - largest table + 50% for mysqltemp running out of disk space is simply the result of a config mistake or missing to watch growing data Am 31.10.2012 22:13, schrieb Rick James: Oh, another issue... If you have your disk partitioned, and the tmpdir is pointing to a small partition, you could run out of room for that reason. I sometimes find a tiny boot partition (not a terrible idea), plus partitions for /tmp, /var /usr, and maybe others. (Or C:, D:, etc, if you are that type of person.) Hence, I _dislike_ splitting disks into separate filesystems. -Original Message- From: Reindl Harald [mailto:h.rei...@thelounge.net] Sent: Wednesday, October 31, 2012 11:56 AM To: mysql@lists.mysql.com Subject: Re: what is stored in /var/lib/mysql_log/ ? Am 31.10.2012 19:47, schrieb walter harms: thx for your help. I have found the root cause that was not related to immodb. It was that tmpdir was pointing to the same space. This were no problem for a long time then something happended, the system was optimizing and was running out of space causing a table corruption (why can a failed optimisation cause a table corruption ?) because running out of disk space is a condition which is hard to test in any combination and should never happen signature.asc Description: OpenPGP digital signature
Re: Dumping drupal databases
* Reindl Harald h.rei...@thelounge.net [121031 08:12]: Am 31.10.2012 16:34, schrieb Tim Johnson: * Johan De Meersman vegiv...@tuxera.be [121031 07:10]: Given the different location of the datafiles and assuming the actual drupal does work, I'm starting to suspect that whatever installer you used created a second instance of mysql. Your drupal configfile should hold the necessary data to connect to it. You are correct. Running on 3307. (from settings.php) But even loging into that instance was not showing me the drupal databases - so I was stumped! I would guess that was because the 3307 instance was using the system-wide my.cnf instead of the drupal my.cnf. I could not see from documentation how to invoke mysql or mysqldump with a specific my.cnf. See my response to your other email. thanks Johan you MUST NOT use localhost if you want to connect to a different mysqld-port because localhost is unix-socket mysql -h 127.0.0.1 --port=3307 -u username -p I get access denied when I do that. thanks -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Dumping drupal databases
Am 01.11.2012 01:54, schrieb Tim Johnson: * Reindl Harald h.rei...@thelounge.net [121031 08:12]: you MUST NOT use localhost if you want to connect to a different mysqld-port because localhost is unix-socket mysql -h 127.0.0.1 --port=3307 -u username -p I get access denied when I do that. thanks don't get me wrong - but do you have any clue about what you are doing? replace username with the username drupal is using enter the password drupal is using you got MANY options in thsi thread * let point your default mysqld-datadir to the one the drupal setup used and export the data, after that restore /etc/my.cnf as it is now * stop ANY mysqld instance and copy the db-folder to your used instance * connect to the instance as asid with 127.0.0.1 if you are not able or/and willing to do any of these 3 options i am really out of hope that you should do whatever you believe is your job by missing basic understanding signature.asc Description: OpenPGP digital signature
Re: Dumping drupal databases
* Reindl Harald h.rei...@thelounge.net [121031 17:22]: Am 01.11.2012 01:54, schrieb Tim Johnson: * Reindl Harald h.rei...@thelounge.net [121031 08:12]: you MUST NOT use localhost if you want to connect to a different mysqld-port because localhost is unix-socket mysql -h 127.0.0.1 --port=3307 -u username -p I get access denied when I do that. thanks don't get me wrong - but do you have any clue about what you are doing? Did you not note that I have a solution? I am clearly aware of the options that you outline below. Let it go. You are ahead of me on your knowledge base and clearly you are trying to help everybody. I no longer need your help so don't waste your time on me. (this time) :) Maybe I will need you help again some day. In the meantime, good luck and keep up the good work! -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
