Re: threads in cleaning up mode
Can it be a consequence of slow disk also? Best Regards, Geetanjali Mehra Senior Database Administrator On Tue, Apr 5, 2016 at 10:50 AM, geetanjali mehra < mailtogeetanj...@gmail.com> wrote: > Thanks to everyone for response. Any other views from any one is always > welcome. > > Best Regards, > Geetanjali Mehra > Senior Database Administrator > > > On Mon, Apr 4, 2016 at 7:51 PM, shawn l.green <shawn.l.gr...@oracle.com> > wrote: > >> >> >> On 4/2/2016 10:36 AM, geetanjali mehra wrote: >> >>> Hi to all, >>> >>> For many days, I am struggling with the problem of increasing history >>> list >>> length on mysql 5.6.29. Application that this server is running IOT >>> based. >>> Also, this server has so many threads running in sleeping mode. SHOW >>> ENGINE >>> INNODB STATUS shows all these threads in *cleaning up* mode. >>> I tried all the options to reduce history list length. But it is >>> constantly >>> increasing. >>> Below are the current settings of purge related threads: >>> >>> innodb_max_purge_lag | 100 | >>> | innodb_max_purge_lag_delay | 0 | >>> | innodb_purge_batch_size| 1 | >>> | innodb_purge_threads | 8 | >>> >>> Also, please let me know that whether cleaning up mode of threads and >>> history list length are correlated. >>> >>> Anty help? >>> >>> >>> Best Regards, >>> Geetanjali Mehra >>> Senior Database Administrator >>> >>> >> No, the "cleaning up" status and your ever-increasing history are not >> related. The "cleaning up" status is a very low-impact bug in our code. We >> simply forgot to reset a flag at the end of that section of the code. It is >> not indicative of any ongoing operations. >> >> What has happened is one of those idle threads (the sleeping ones) has >> opened a transaction but never committed it. That is why your history list >> is never shrinking. As was already said in another response, this is an >> indication of poor client-side transaction management. If you start a >> transaction, you must always terminate it or situations like yours will >> happen. (This is also one of the dangers if someone changes autocommit=0 >> and forgets to change it back.) >> >> >> -- >> Shawn Green >> MySQL Senior Principal Technical Support Engineer >> Oracle USA, Inc. - Integrated Cloud Applications & Platform Services >> Office: Blountville, TN >> >> Become certified in MySQL! Visit https://www.mysql.com/certification/ >> for details. >> >> -- >> MySQL General Mailing List >> For list archives: http://lists.mysql.com/mysql >> To unsubscribe:http://lists.mysql.com/mysql >> >> >
Re: threads in cleaning up mode
Thanks to everyone for response. Any other views from any one is always welcome. Best Regards, Geetanjali Mehra Senior Database Administrator On Mon, Apr 4, 2016 at 7:51 PM, shawn l.green <shawn.l.gr...@oracle.com> wrote: > > > On 4/2/2016 10:36 AM, geetanjali mehra wrote: > >> Hi to all, >> >> For many days, I am struggling with the problem of increasing history >> list >> length on mysql 5.6.29. Application that this server is running IOT based. >> Also, this server has so many threads running in sleeping mode. SHOW >> ENGINE >> INNODB STATUS shows all these threads in *cleaning up* mode. >> I tried all the options to reduce history list length. But it is >> constantly >> increasing. >> Below are the current settings of purge related threads: >> >> innodb_max_purge_lag | 100 | >> | innodb_max_purge_lag_delay | 0 | >> | innodb_purge_batch_size| 1 | >> | innodb_purge_threads | 8 | >> >> Also, please let me know that whether cleaning up mode of threads and >> history list length are correlated. >> >> Anty help? >> >> >> Best Regards, >> Geetanjali Mehra >> Senior Database Administrator >> >> > No, the "cleaning up" status and your ever-increasing history are not > related. The "cleaning up" status is a very low-impact bug in our code. We > simply forgot to reset a flag at the end of that section of the code. It is > not indicative of any ongoing operations. > > What has happened is one of those idle threads (the sleeping ones) has > opened a transaction but never committed it. That is why your history list > is never shrinking. As was already said in another response, this is an > indication of poor client-side transaction management. If you start a > transaction, you must always terminate it or situations like yours will > happen. (This is also one of the dangers if someone changes autocommit=0 > and forgets to change it back.) > > > -- > Shawn Green > MySQL Senior Principal Technical Support Engineer > Oracle USA, Inc. - Integrated Cloud Applications & Platform Services > Office: Blountville, TN > > Become certified in MySQL! Visit https://www.mysql.com/certification/ for > details. > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe:http://lists.mysql.com/mysql > >
threads in cleaning up mode
Hi to all, For many days, I am struggling with the problem of increasing history list length on mysql 5.6.29. Application that this server is running IOT based. Also, this server has so many threads running in sleeping mode. SHOW ENGINE INNODB STATUS shows all these threads in *cleaning up* mode. I tried all the options to reduce history list length. But it is constantly increasing. Below are the current settings of purge related threads: innodb_max_purge_lag | 100 | | innodb_max_purge_lag_delay | 0 | | innodb_purge_batch_size| 1 | | innodb_purge_threads | 8 | Also, please let me know that whether cleaning up mode of threads and history list length are correlated. Anty help? Best Regards, Geetanjali Mehra Senior Database Administrator
commands out of sync, you can't run this command now'
Hi all, Suddenly I have started getting below error from our web site: 'commands out of sync, you can't run this command now' This error is generated sometimes when opening a page ,and immediately after refreshing the page, error gone. Can you please help me to troubleshoot this issue, so that above error disappears permanently? Is it a database issue or application side issue? Best Regards, Geetanjali Mehra Senior Database Administrator
Re: Changing storage engine in dump file.
Thanks everyone for their reply. Best Regards, Geetanjali Mehra Senior Database Administrator On Wed, Aug 12, 2015 at 7:07 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.08.2015 um 15:07 schrieb geetanjali mehra: I am in the process of creating a new slave. On my master, there is a mix of innodb and myisam tables. I want all my tables to be created in innodb on slave. I have planned to change the value of storage engine from innodb to myisam in dump file itself using sed . Running that dump file on the slave will create all my tables with innodb. Is there any implications in doing so. Is this approach correct? Will I face any problem in syncing the slave? if you are asking for trouble do so otherwise replication is designed to be identical how do you imagine that working if there is only a single alter table on the master? how do you imagine row-based replication working in such a setup while statement-based replication is unsafe in many cases? sorry, but that sounds just crazy
Re: Changing storage engine in dump file.
I have already made this attempt. And really I stucked into some problems. I found lots of full text indexes created on the data directory . I don't know from where they come. We have never created full text indexes for that database. Slave also was not able to sync with its master. Now, I have restored all the things back by restoring mysqldump file as it was. Best Regards, Geetanjali Mehra Senior Database Administrator On Thu, Aug 13, 2015 at 10:31 PM, Singer Wang w...@singerwang.com wrote: Depending on the version of MySQL and InnoDB engine, the max key length can be 3072 for InnoDB.. On Wed, Aug 12, 2015 at 9:21 AM, Johan De Meersman vegiv...@tuxera.be wrote: - Original Message - From: geetanjali mehra mailtogeetanj...@gmail.com Subject: Changing storage engine in dump file. Is there any implications in doing so. Is this approach correct? Will I face any problem in syncing the slave? The first thing that occurs to me, is that the maximum key lenght for MyISAM is 1000 bytes, but for InnoDB it is only 786 bytes... Depending on your server version, InnoDB may not yet have fulltext indices, and even if it does, the behaviour is different from the MyISAM ones. You are likely to run into a myriad of tiny little differences, and it seems to me like a fairly bad plan. Why do you want this? -- Unhappiness is discouraged and will be corrected with kitten pictures. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Changing storage engine in dump file.
Hi, I am in the process of creating a new slave. On my master, there is a mix of innodb and myisam tables. I want all my tables to be created in innodb on slave. I have planned to change the value of storage engine from innodb to myisam in dump file itself using sed . Running that dump file on the slave will create all my tables with innodb. Is there any implications in doing so. Is this approach correct? Will I face any problem in syncing the slave? Thanks in advance.
Re: Starting mysql 5.7.7
Have u executed mysql_install_db? On 15-May-2015 1:31 pm, Jørn Dahl-Stamnes sq...@dahl-stamnes.net wrote: Hello, I have reinstalled a test server after a disk crash. I upgraded from an older Fedora Core (don't remember the version) to Fedora Core 21. Then I installed Mysql 5.7.7 from RPM. I'm able to start it but mysql does not use my /etc/my.cnf file and I do not find any other on my system. After doing a 'yum install ...' I started it without a my.cnf file. It seem to start OK and all the database files++ was added to /var/lib/mysql. Since I got a SSD disk where I want to locate the databases, I stopped mysql and moved the file to this disk and added links (just as I did on the old system). I removed all ib* files and added my myc.fn file (it contain info about ibdata files etc) and then tried to start it - no luck. Base on the entries in /var/log/messages, it does not seem to use the /etc/my.cnf file. There is also a few warnings which I'm not sure how to fix. Any suggestions what's wrong? My my.cnf file: # The MySQL server [mysqld] port= 3306 socket = /tmp/mysql.sock skip-external-locking key_buffer_size = 384M max_allowed_packet = 32M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M # Try number of CPU's*2 for thread_concurrency thread_concurrency = 16 max_connections = 50 log-bin=/var/mysql/mysql-bin server-id = 1 binlog_format=mixed # Innodb settings. # Open files. innodb_open_files = 2048 open_files_limit= 8096 innodb_data_home_dir= /data/mysql/data innodb_data_file_path = ibdata1:20G;ibdata2:20G;ibdata3:20G;ibdata4:20G:autoextend innodb_file_per_table = 0 innodb_autoextend_increment = 256 innodb_log_group_home_dir = /data/mysql/data # You can set .._buffer_pool_size up to 50 - 80 % # of RAM but beware of setting memory usage too high. innodb_buffer_pool_size = 25G # Set .._log_file_size to 25 % of buffer pool size innodb_log_file_size= 300M innodb_log_files_in_group = 2 innodb_log_buffer_size = 128M innodb_flush_log_at_trx_commit = 1 innodb_support_xa = 0 innodb_flush_method = O_DIRECT innodb_lock_wait_timeout= 50 innodb_fast_shutdown= 0 From /var/log/messages: May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.255284Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.256631Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.7- rc) starting as process 1528 ... May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.265686Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.266263Z 0 [Note] InnoDB: Uses event mutexes May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.21Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.267045Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3 May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.267432Z 0 [Note] InnoDB: Using Linux native AIO May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.268269Z 0 [Note] InnoDB: Number of pools: 1 May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.268804Z 0 [Note] InnoDB: Using CPU crc32 instructions May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.270686Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.298852Z 0 [Note] InnoDB: Completed initialization of buffer pool May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.353601Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.356077Z 0 [Note] InnoDB: Highest supported file format is Barracuda. May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.361383Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 1210467 May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.361927Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1210476 May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.362672Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 1210476 May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.363083Z 0 [Note] InnoDB: Database was not shutdown normally! May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.363456Z 0 [Note] InnoDB: Starting crash recovery. May 15 09:41:27 anakin mysqld: 2015-05-15T07:41:27.484951Z 0 [Note] InnoDB: Removed temporary tablespace data file: ibtmp1 May
Binary log in 5.6
Got a very strange situation, where I receive two similar DELETE statement in the same binary log position, due to which replication slave is stopped due to following error: Could not execute DELETE rows event on table db1.xyz.; Can't find record in 'xyz' , error code:1032. Following entry is found in the binary log: # at 28651234 #150423 12:21:03 server id 5170 end_log_pos 28651303 CRC32 0x0b496431 Delete_rows: table id 73 flags: STMT_END_F ### DELETE FROM `db1`.`xyz` ### WHERE ### @1=1040103520 ### @2='new' ### DELETE FROM `db1`.`xyz` ### WHERE ### @1=1040103520 ### @2='new' But, above record do exist in db1.xyz table on slave. Still, replication error on slave says: can't find record. Any idea on this. Best Regards, Geetanjali Mehra Senior Database Administrator
Re: mysqldump with single-transaction option.
So, in case of * NOT Innodb * storage engine, say MyISAM, will this dump be of any useful? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Consultant and Database Security Specialist On Tue, Oct 7, 2014 at 11:55 AM, yoku ts. yoku0...@gmail.com wrote: Hello, If you use any *NOT InnoDB* storage engine, you're right. mysqldump with --single-transaction doesn't have any consistent as you say. If you use InnoDB all databases and tables, your dumping process is protected by transaction isolation level REPEATABLE-READ. http://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_single-transaction Regards, 2014-10-07 12:52 GMT+09:00 geetanjali mehra mailtogeetanj...@gmail.com: It seems to me that once the read lock is acquired, only the binary log coordinates are read. Soon after binary log coordinates are read, lock is released. Is there anything else that happens here? It means that after lock is released, dump is made while the read and write activity is going on. This dump then, would be inconsistent. So, to make this dump a consistent one when restoring it, binary log will be applied starting from the binary log coordinates that has been read earlier. This is what I understand. Please correct me if my understanding is wrong. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Consultant and Database Security Specialist On Tue, Oct 7, 2014 at 6:22 AM, shawn l.green shawn.l.gr...@oracle.com wrote: Hello Geetanjali, On 9/23/2014 7:14 AM, geetanjali mehra wrote: Can anybody please mention the internals that works when we use mysqldump as follows: *mysqldump --single-transaction --all-databases backup_sunday_1_PM.sql* MySQL manual says: This backup operation acquires a global read lock on all tables at the beginning of the dump (using *FLUSH TABLES WITH READ LOCK http://dev.mysql.com/doc/refman/5.6/en/flush.html*). As soon as this lock has been acquired, the binary log coordinates are read and the lock is released. If long updating statements are running when the FLUSH http://dev.mysql.com/doc/refman/5.6/en/flush.html statement is issued, the backup operation may stall until those statements finish. After that, the dump becomes lock-free and does not disturb reads and writes on the tables. Can anyone explain it more? Please. Which part would you like to address first? I have a feeling it's more about how FLUSH TABLES WITH READ LOCK works but I want to be certain before answering. Yours, -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: mysqldump with single-transaction option.
It seems to me that once the read lock is acquired, only the binary log coordinates are read. Soon after binary log coordinates are read, lock is released. Is there anything else that happens here? It means that after lock is released, dump is made while the read and write activity is going on. This dump then, would be inconsistent. So, to make this dump a consistent one when restoring it, binary log will be applied starting from the binary log coordinates that has been read earlier. This is what I understand. Please correct me if my understanding is wrong. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Consultant and Database Security Specialist On Tue, Oct 7, 2014 at 6:22 AM, shawn l.green shawn.l.gr...@oracle.com wrote: Hello Geetanjali, On 9/23/2014 7:14 AM, geetanjali mehra wrote: Can anybody please mention the internals that works when we use mysqldump as follows: *mysqldump --single-transaction --all-databases backup_sunday_1_PM.sql* MySQL manual says: This backup operation acquires a global read lock on all tables at the beginning of the dump (using *FLUSH TABLES WITH READ LOCK http://dev.mysql.com/doc/refman/5.6/en/flush.html*). As soon as this lock has been acquired, the binary log coordinates are read and the lock is released. If long updating statements are running when the FLUSH http://dev.mysql.com/doc/refman/5.6/en/flush.html statement is issued, the backup operation may stall until those statements finish. After that, the dump becomes lock-free and does not disturb reads and writes on the tables. Can anyone explain it more? Please. Which part would you like to address first? I have a feeling it's more about how FLUSH TABLES WITH READ LOCK works but I want to be certain before answering. Yours, -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
mysqldump with single-transaction option.
Can anybody please mention the internals that works when we use mysqldump as follows: *mysqldump --single-transaction --all-databases backup_sunday_1_PM.sql* MySQL manual says: This backup operation acquires a global read lock on all tables at the beginning of the dump (using *FLUSH TABLES WITH READ LOCK http://dev.mysql.com/doc/refman/5.6/en/flush.html*). As soon as this lock has been acquired, the binary log coordinates are read and the lock is released. If long updating statements are running when the FLUSH http://dev.mysql.com/doc/refman/5.6/en/flush.html statement is issued, the backup operation may stall until those statements finish. After that, the dump becomes lock-free and does not disturb reads and writes on the tables. Can anyone explain it more? Please. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Consultant and Database Security Specialist
PAM authentication plugin
Hi all, I am trying to implement PAM authentication plugin. I am using Server version: 5.6.15-enterprise-commercial-advanced. I am following these steps: mysql show variables like '%plugin%'; +---++ | Variable_name | Value | +---++ | plugin_dir| /usr/lib/mysql/plugin/ | +---++ mysql INSTALL PLUGIN authentication_pam SONAME 'authentication_pam.so'; Query OK, 0 rows affected (0.00 sec) I verified the same using *show plugins* command. It is there. [root@host1 pam.d]# *cat /etc/pam.d/mysql* #%PAM-1.0 authinclude password-auth account include password-auth [root@host1 pam.d]# *cat password-auth * #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so md5 shadow nullok try_first_pass use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so authrequired/usr/lib/mysql/plugin/authentication_pam.so # useradd user1 # passwd user1 mysql create user user1 identified with authentication_pam as 'mysql'; Query OK, 0 rows affected (0.00 sec) [root@host1 ~]# mysql -uuser1 -puser1 --enable-cleartext-plugin Warning: Using a password on the command line interface can be insecure. ERROR 1045 (28000): Access denied for user 'user1'@'localhost' (using password: YES) [root@host1 ~]# Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Consultant and Database Security Specialist
Re: next-key lock
Thanks to all, Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Thu, Sep 4, 2014 at 2:36 PM, Akshay Suryavanshi akshay.suryavansh...@gmail.com wrote: Hi Geeetanjali, I retried the scenario you mentioned, however I am getting consistent locking results on both unique and non-unique index, the preceding records are getting updated however just the next record is being locked next-key locking. If I try to insert a new record after the next key it is getting inserted. I wonder how it is different in your situation. All I can say for now is InnoDB indexes are not ordered, so unsure exactly if 20 falls just right after the gap. Also did you delete the records from 7 through 19 or they are just not inserted in your test table, because that it wont be a gap, for the index records they are just values 6 and 20 which might sit next to each other in the innodb page. There are multiple blogs by experts on how the locking internals work, http://dom.as/2011/07/03/innodb-index-lock/ https://www.facebook.com/note.php?note_id=479123255932 https://blogs.oracle.com/mysqlinnodb/entry/introduction_to_transaction_locks_in http://dev.mysql.com/doc/internals/en/innodb-user-records.html In the User Records part of a page, you'll find all the records that the user inserted. There are two ways to navigate through the user records, depending whether you want to think of their organization as an unordered or an ordered list. An unordered list is often called a heap. If you make a pile of stones by saying whichever one I happen to pick up next will go on top -- rather than organizing them according to size and colour -- then you end up with a heap. Similarly, InnoDB does not want to insert new rows according to the B-tree's key order (that would involve expensive shifting of large amounts of data), so it inserts new rows right after the end of the existing rows (at the top of the Free Space part) or wherever there's space left by a deleted row. But by definition the records of a B-tree must be accessible in order by key value, so there is a record pointer in each record (the next field in the Extra Bytes) which points to the next record in key order. In other words, the records are a one-way linked list. So InnoDB can access rows in key order when searching. Hope this helps. Cheers!!! Akshay On Thu, Sep 4, 2014 at 9:48 AM, geetanjali mehra mailtogeetanj...@gmail.com wrote: Dear Akshay, Thanks for you reply, You are really great. Now , one more confusion. mysql create table test.new as select id,name from City; Query OK, 4079 rows affected (0.18 sec) Records: 4079 Duplicates: 0 Warnings: 0 mysql select * from new limit 15; ++---+ | id | name | ++---+ | 1 | Kabul | | 2 | Qandahar | | 3 | Herat | | 4 | Mazar-e-Sharif| | 5 | Amsterdam | | 6 | Rotterdam | |11|hhh | | 20 | ´s-Hertogenbosch | | 21 | Amersfoort| | 22 | Maastricht| | 23 | Dordrecht | | 24 | Leiden| | 25 | Haarlemmermeer| | 26 | Zoetermeer| | 27 | Emmen | | 28 | Zwolle| Now, *Session 1* *Session 2* mysql begin; Query OK, 0 rows affected (0.01 sec) mysql select * from new where id between 9 and 15 for update; ++--+ | id | name | ++--+ | 11 | hhh | ++--+ 1 row in set (0.00 sec) mysql begin; Query OK, 0 rows affected (0.00 sec) mysql insert into new values(17,'fff'); (session is hanging) mysql insert into new values(18,'fff'); (session is hanging) mysql insert into new values(19,'fff'); (session is hanging). mysql insert into new values(20,'fff'); Query OK, 1 row affected (0.00 sec) mysql insert into new values(21,'fff'); Query OK, 1 row affected (0.01 sec) mysql insert into new values(8,'fff'); (session hang) mysql mysql insert into new values(7,'fff'); (session hang) mysql insert into new values(6,'fff'); (session hang) mysql insert into new values(5,'ggg'); Query OK, 1 row affected (0.00 sec) I tried the above scenario with index and without index. Without index it is showing the same behaviour as before. Using non-unique index, it is not locking the next value (20)immediately after the gap. But it is locking a row with id=6, the value immediately before the gap. Can you explain me the same? When I tried the same scenario with unique index, this is what I got from another session: mysql insert into new values(20,'jjj'); (hang) mysql insert into new values(6,'jjj'); ERROR 1062 (23000): Duplicate entry '6' for key 'idx1' Here it is locking 20 , but not 6. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database
Re: next-key lock
This is what I am doing. mysql select * from new; +--+--+ | c1 | c2 | +--+--+ |5 |5 | | 10 | 10 | | 15 | 15 | | 20 | 20 | | 30 | 30 | +--+--+ Now, Session 1 mysql begin; Query OK, 0 rows affected (0.00 sec) mysql select * from new where c1 between 10 and 25 for update; +--+--+ | c1 | c2 | +--+--+ | 10 | 10 | | 15 | 15 | | 20 | 20 | +--+--+ 3 rows in set (0.00 sec) mysqlbegin; mysql insert into new values(29,29); (session is hanging) mysql insert into new values(31,31); (session is hanging The last value on my table is 30. Still it is not allowing me to insert 31. I tried the scenario without index on column c1 and then with non-unique index on column c1 and then unique index. I am getting the same result. It seems that it is putting up lock on complete table. The scenario is working fine only when I made c1 primary key. After making c1 primary key, I am able to insert value higher than 30. Can you please try the same scenario at your end? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Tue, Sep 2, 2014 at 1:53 PM, Akshay Suryavanshi akshay.suryavansh...@gmail.com wrote: Hello Geetanjali, Apologies if I have confused you with the normal Select notation. I meant to write with repeatable-read mode in mind, but looks like that is not an issue, since you already tested this scenario with that isolation mode. Moving further to the original issue. Do you have an index on column c1. Is the query Select * from new where c1 between 12 and 17 for update; using index ? If there is no index on the particular column, then InnoDB locks out whole table from other transactions. Which is the case you mentioned. Also this can be dangerous. Once you have indexed the column checkout the innodb status, you will see the necessary locking. Also try updating values beyond the boundary values. So most important fact to know here is the involvement of secondary indexes to introduce record locking, gap locking, and how their absence will affect the transaction. As to Why this is happening ? It should be understood that in InnoDB secondary keys are appended to PRIMARY index, so if there is no index to search the records PRIMARY index values cannot be filtered. In absence of secondary indexes a full scan is needed. And finally Innodb table is one big Index (Clustered table). *By default, InnoDB operates in REPEATABLE READ http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html#isolevel_repeatable-read transaction isolation level and with theinnodb_locks_unsafe_for_binlog http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows.* So Index scan above is infact a Full-table-scan (full index scan) Please try it out and let me know if you observe any difference. Cheers!!! Akshay On Tue, Sep 2, 2014 at 11:59 AM, geetanjali mehra mailtogeetanj...@gmail.com wrote: Dear Akshay, ASFIK, normal selects are always non-locking read and they do not put any locks. Select..., Select..where..,Select where..between Does above select statement will use next-key locking and/or gap locking? I dont think so. Please correct me if I am wrong. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Fri, Aug 29, 2014 at 11:46 AM, Akshay Suryavanshi akshay.suryavansh...@gmail.com wrote: Geetanjali, There is a difference between next-key locking, gap locking and locking reads. Next-key locking and gap-locking are used with normal Selects statement in Innodb, whereas locking reads wont release a lock on the whole column until transaction completed, and not just selected values. May be you can try your example with SELECT... LOCK IN SHARE MODE; Cheers!!! Akshay Suryawanshi On Fri, Aug 29, 2014 at 11:22 AM, geetanjali mehra mailtogeetanj...@gmail.com wrote: Thanks for your reply. I read those docs. Still my doubt is at the same stage. Please clarify the same to me. Should not other sessions be allowed to insert the rows beyond that range.? As far as I understand, Innodb brought the concept of next-key locks so as to prevent phantom problem. So, it is clear to me that issuing the below query Select * from new where c1 between 12 and 17 for update; will not allow other sessions to insert any value between 12 and 17. But if i am trying to insert 20 from other session, it is not allowed. Why this is so? The session is hanging. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Thu, Aug 28
Re: next-key lock
Dear Akshay, Thanks for you reply, You are really great. Now , one more confusion. mysql create table test.new as select id,name from City; Query OK, 4079 rows affected (0.18 sec) Records: 4079 Duplicates: 0 Warnings: 0 mysql select * from new limit 15; ++---+ | id | name | ++---+ | 1 | Kabul | | 2 | Qandahar | | 3 | Herat | | 4 | Mazar-e-Sharif| | 5 | Amsterdam | | 6 | Rotterdam | |11|hhh | | 20 | ´s-Hertogenbosch | | 21 | Amersfoort| | 22 | Maastricht| | 23 | Dordrecht | | 24 | Leiden| | 25 | Haarlemmermeer| | 26 | Zoetermeer| | 27 | Emmen | | 28 | Zwolle| Now, *Session 1* *Session 2* mysql begin; Query OK, 0 rows affected (0.01 sec) mysql select * from new where id between 9 and 15 for update; ++--+ | id | name | ++--+ | 11 | hhh | ++--+ 1 row in set (0.00 sec) mysql begin; Query OK, 0 rows affected (0.00 sec) mysql insert into new values(17,'fff'); (session is hanging) mysql insert into new values(18,'fff'); (session is hanging) mysql insert into new values(19,'fff'); (session is hanging). mysql insert into new values(20,'fff'); Query OK, 1 row affected (0.00 sec) mysql insert into new values(21,'fff'); Query OK, 1 row affected (0.01 sec) mysql insert into new values(8,'fff'); (session hang) mysql mysql insert into new values(7,'fff'); (session hang) mysql insert into new values(6,'fff'); (session hang) mysql insert into new values(5,'ggg'); Query OK, 1 row affected (0.00 sec) I tried the above scenario with index and without index. Without index it is showing the same behaviour as before. Using non-unique index, it is not locking the next value (20)immediately after the gap. But it is locking a row with id=6, the value immediately before the gap. Can you explain me the same? When I tried the same scenario with unique index, this is what I got from another session: mysql insert into new values(20,'jjj'); (hang) mysql insert into new values(6,'jjj'); ERROR 1062 (23000): Duplicate entry '6' for key 'idx1' Here it is locking 20 , but not 6. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Wed, Sep 3, 2014 at 10:59 PM, Akshay Suryavanshi akshay.suryavansh...@gmail.com wrote: Can you try the same on a big table, I think optimizer is choosing a FTS over an index lookup. On Wed, Sep 3, 2014 at 8:25 PM, geetanjali mehra mailtogeetanj...@gmail.com wrote: This is what I am doing. mysql select * from new; +--+--+ | c1 | c2 | +--+--+ |5 |5 | | 10 | 10 | | 15 | 15 | | 20 | 20 | | 30 | 30 | +--+--+ Now, Session 1 mysql begin; Query OK, 0 rows affected (0.00 sec) mysql select * from new where c1 between 10 and 25 for update; +--+--+ | c1 | c2 | +--+--+ | 10 | 10 | | 15 | 15 | | 20 | 20 | +--+--+ 3 rows in set (0.00 sec) mysqlbegin; mysql insert into new values(29,29); (session is hanging) mysql insert into new values(31,31); (session is hanging The last value on my table is 30. Still it is not allowing me to insert 31. I tried the scenario without index on column c1 and then with non-unique index on column c1 and then unique index. I am getting the same result. It seems that it is putting up lock on complete table. The scenario is working fine only when I made c1 primary key. After making c1 primary key, I am able to insert value higher than 30. Can you please try the same scenario at your end? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Tue, Sep 2, 2014 at 1:53 PM, Akshay Suryavanshi akshay.suryavansh...@gmail.com wrote: Hello Geetanjali, Apologies if I have confused you with the normal Select notation. I meant to write with repeatable-read mode in mind, but looks like that is not an issue, since you already tested this scenario with that isolation mode. Moving further to the original issue. Do you have an index on column c1. Is the query Select * from new where c1 between 12 and 17 for update; using index ? If there is no index on the particular column, then InnoDB locks out whole table from other transactions. Which is the case you mentioned. Also this can be dangerous. Once you have indexed the column checkout the innodb status, you will see the necessary locking. Also try updating values beyond the boundary values. So most important fact to know here is the involvement of secondary indexes to introduce record locking, gap locking, and how their absence will affect the transaction. As to Why this is happening ? It should be understood
Re: next-key lock
Dear Akshay, ASFIK, normal selects are always non-locking read and they do not put any locks. Select..., Select..where..,Select where..between Does above select statement will use next-key locking and/or gap locking? I dont think so. Please correct me if I am wrong. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Fri, Aug 29, 2014 at 11:46 AM, Akshay Suryavanshi akshay.suryavansh...@gmail.com wrote: Geetanjali, There is a difference between next-key locking, gap locking and locking reads. Next-key locking and gap-locking are used with normal Selects statement in Innodb, whereas locking reads wont release a lock on the whole column until transaction completed, and not just selected values. May be you can try your example with SELECT... LOCK IN SHARE MODE; Cheers!!! Akshay Suryawanshi On Fri, Aug 29, 2014 at 11:22 AM, geetanjali mehra mailtogeetanj...@gmail.com wrote: Thanks for your reply. I read those docs. Still my doubt is at the same stage. Please clarify the same to me. Should not other sessions be allowed to insert the rows beyond that range.? As far as I understand, Innodb brought the concept of next-key locks so as to prevent phantom problem. So, it is clear to me that issuing the below query Select * from new where c1 between 12 and 17 for update; will not allow other sessions to insert any value between 12 and 17. But if i am trying to insert 20 from other session, it is not allowed. Why this is so? The session is hanging. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Thu, Aug 28, 2014 at 2:26 AM, shawn l.green shawn.l.gr...@oracle.com wrote: On 8/26/2014 1:12 AM, geetanjali mehra wrote: Hello to all, In repeatable read isolation level, when we issue: Select * from new where c1 between 12 and 17 for update; this range will be locked by innodb by using next-key locks. But, why is is preventing any other session to insert any value beyond that range; any value above the range and any value below the range. I am unable to understand this. I believe you are confusing gap locking (the space between the values) and next-key locking (the space after the range). http://dev.mysql.com/doc/refman/5.6/en/innodb-record-level-locks.html See also: http://dev.mysql.com/doc/refman/5.6/en/innodb-next-key-locking.html http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist Yours, -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: purge thread
Could you please put some more light on it? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Thu, Aug 28, 2014 at 2:09 AM, shawn l.green shawn.l.gr...@oracle.com wrote: Hello Geetanjali, On 8/26/2014 1:16 AM, geetanjali mehra wrote: I want to understand how to tune innodb_max_purge_lag http://dev.mysql.com/doc/refman/5.5/en/innodb- parameters.html#sysvar_innodb_max_purge_lag when history list length is high. Could anyone explain me. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist This setting not related to the history value. It is there to help control the gap between these two values of the InnoDB status report Trx id counter 0 290328385 Purge done for trx's n:o 0 290315608 undo n:o 0 17 What is the current transaction compared what is the oldest transaction that still has aged copies of data left in the data area of the tablespace. The difference between those two values is the purge backlog Yours, -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: fragmentation in innodb index
Thanks to all, Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Fri, Aug 29, 2014 at 11:59 AM, Hartmut Holzgraefe hart...@skysql.com wrote: On 08/29/2014 08:15 AM, geetanjali mehra wrote: But after doing *optimize table*, the value inside data_free is still the same. If there is no change in the value of data_free, then what *optimize table* does here? Without seeing actual values I can only give an educated guess: * If you are not using innodb_file_per_table then data_free is for the whole table space, not just the individual table you're looking at. Even if that table was fragmented before running OPTIMIZE the overall unallocated storage space within the table space won't change much ... * If you have innodb_file_per_table=1 and you are seeing data_free values round about 4MB what you're seeing is simply pre-allocated space. See also the last paragraph on http://dev.mysql.com/doc/refman/5.6/en/innodb-multiple-tablespaces.html File-per-table tablespace files are auto-extending regardless of the value of innodb_autoextend_increment. The initial extensions are by small amounts, after which extensions occur in increments of 4MB. So unless you have innodb_file_per_table set and see data_free values substantially larger than 4MB there's nothing to worry about ... -- Hartmut Holzgraefe, Principal Support Engineer (EMEA) SkySQL - The MariaDB Company | http://www.skysql.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: fragmentation in innodb index
Could you please answer these questions also. What does data_free field from SHOW TABLE STATUS shows? When should we run optimize table for innodb tables? I read various blogs. They said data_free shows free space inside the innodb tables. But after doing *optimize table*, the value inside data_free is still the same. If there is no change in the value of data_free, then what *optimize table* does here? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Thu, Aug 28, 2014 at 2:21 AM, shawn l.green shawn.l.gr...@oracle.com wrote: Hello Geetanjali, On 8/26/2014 1:11 AM, geetanjali mehra wrote: Hello to all, I want to know whether my innodb index is fragemented. Is it possible to know? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist Just like every other piece of data stored in an InnoDB tablespace, the index data is stored in pages. At maximum capacity, 15KB of the 16KB assigned to each page can consist of data. At worst, about half of a 16K page will contain data. This is because each page is one leaf in a BTREE structure. If you add data to a page and you would exceed that 15K limit, we would need to split that page. That means that each page (the existing page and the one we just created) will now have a near-equal share of the data that was on the original page. That empty space is reused as much as possible to avoid another page split. If removing data from a table makes it possible to combine two adjacent leaves in the B-tree, we will. The page that once held the extra information is marked as 'available' and it can be filled with more index information later or filled with actual table data. A page is a page is a page. InnoDB decides what goes on a page. So... Is an index ever fragmented? No (depending on your definition of fragmentation) Will there ever be some free space within the index tree? Always. Can index pages be scattered (non-contiguous) within a tablespace file? Yes. Will rebuilding a table ensure that the index pages are made contiguous? No. Do these same answers apply to the actual data stored on a table? Yes. http://dev.mysql.com/doc/refman/5.6/en/innodb-file-defragmenting.html http://dev.mysql.com/doc/refman/5.6/en/innodb-file-space.html Does that help? -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: next-key lock
Thanks for your reply. I read those docs. Still my doubt is at the same stage. Please clarify the same to me. Should not other sessions be allowed to insert the rows beyond that range.? As far as I understand, Innodb brought the concept of next-key locks so as to prevent phantom problem. So, it is clear to me that issuing the below query Select * from new where c1 between 12 and 17 for update; will not allow other sessions to insert any value between 12 and 17. But if i am trying to insert 20 from other session, it is not allowed. Why this is so? The session is hanging. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist On Thu, Aug 28, 2014 at 2:26 AM, shawn l.green shawn.l.gr...@oracle.com wrote: On 8/26/2014 1:12 AM, geetanjali mehra wrote: Hello to all, In repeatable read isolation level, when we issue: Select * from new where c1 between 12 and 17 for update; this range will be locked by innodb by using next-key locks. But, why is is preventing any other session to insert any value beyond that range; any value above the range and any value below the range. I am unable to understand this. I believe you are confusing gap locking (the space between the values) and next-key locking (the space after the range). http://dev.mysql.com/doc/refman/5.6/en/innodb-record-level-locks.html See also: http://dev.mysql.com/doc/refman/5.6/en/innodb-next-key-locking.html http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist Yours, -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
next-key lock
Hello to all, In repeatable read isolation level, when we issue: Select * from new where c1 between 12 and 17 for update; this range will be locked by innodb by using next-key locks. But, why is is preventing any other session to insert any value beyond that range; any value above the range and any value below the range. I am unable to understand this. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist
fragmentation in innodb index
Hello to all, I want to know whether my innodb index is fragemented. Is it possible to know? Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist
purge thread
I want to understand how to tune innodb_max_purge_lag http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_max_purge_lag when history list length is high. Could anyone explain me. Best Regards, Geetanjali Mehra Senior Oracle and MySQL DBA Corporate Trainer and Database Security Specialist
blob data types
I want to know where does MyISAM and innodb stores its BLOB data ; inside the table or outside the table. I tried to understand BLOB using MySQL online docs but failed. Geetanjali Mehra Oracle and MySQL DBA Corporate Trainer
Re: blob data types
Is it possible to move blob data type values out of table and keep it in separate page, keeping BLOB the part of the table. Geetanjali Mehra Oracle and MySQL DBA Corporate Trainer On Mon, May 26, 2014 at 3:26 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 26.05.2014 11:40, schrieb geetanjali mehra: I want to know where does MyISAM and innodb stores its BLOB data ; inside the table or outside the table. I tried to understand BLOB using MySQL online docs but failed. inside the table, it's just a field type
Re: New to MySQL
use rpm -i --replacefiles MySQL-server*.rpm On Mon, Mar 3, 2014 at 11:30 AM, Asma rabe asma.r...@gmail.com wrote: I installed my sql using RPM as follows: rpm -i MySQL-server-5.6.16-1.el6.x86_64.rpm I got the following errors file /usr/share/mysql/czech/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 file /usr/share/mysql/danish/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 file /usr/share/mysql/dutch/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 file /usr/share/mysql/english/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 file /usr/share/mysql/estonian/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 file /usr/share/mysql/french/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 file /usr/share/mysql/german/errmsg.sys from install of MySQL-server-5.6.16-1.el6.x86_64 conflicts with file from package mysql-libs-5.1.61-1.el6_2.1.x86_64 When i tested if the server has installed or not bin/mysqlshow -bash: bin/mysqlshow: No such file or directory Any help is appreciated . Best Regards, Rabe On Fri, Feb 28, 2014 at 1:36 AM, Johan De Meersman vegiv...@tuxera.be wrote: - Original Message - From: Asma rabe asma.r...@gmail.com Subject: Re: New to MySQL so,Is it recommended to install RPM bundle which has compatlibs, MySQL serveretc rather than installing the server only? The Server should suffice; the Bundle is merely a convenient way to download ALL the RPMs in one go. -- Unhappiness is discouraged and will be corrected with kitten pictures. -- Geetanjali Mehra Oracle DBA Corporate Trainer Koenig-solutions Moti Nagar,New Delhi
Re: Install mysql server using RPM
issue: mysql at the command prompt and let me know. also post the output of ls /var/lib On Mon, Mar 3, 2014 at 1:53 PM, Asma rabe asma.r...@gmail.com wrote: Hi all, I am trying installing Mysql server using RPM bundle rpm -i MySQL-server-5.6.16-1.el6.x86_64.rpm rpm -i MySQL-client-5.6.16-1.el6.x86_64.rpm next i would like to start the server, i followed the mysql docs: The server RPM places data under the /var/lib/mysql directory. The RPM also creates a login account for a user named mysql (if one does not exist) to use for running the MySQL server, and creates the appropriate entries in /etc/init.d/ to start the server automatically at boot time. (This means that if you have performed a previous installation and have made changes to its startup script, you may want to make a copy of the script so that you do not lose it when you install a newer RPM. when i checked /var/lib i found non for mysql,Any idea?? Thank you very much in advance. Best Regards, Rabe -- Geetanjali Mehra Oracle DBA Corporate Trainer Koenig-solutions Moti Nagar,New Delhi
Re: New to MySQL
Thanks for responding. MySQL installation ,here, do not require mysql-libs package. As far as I know, there is no harm on using this command. I too got the same problem, and I didn't face any problem after removing this package. This package is installed by default and not needed here. So, this command is very safe. On Mon, Mar 3, 2014 at 7:49 PM, Johan De Meersman vegiv...@tuxera.bewrote: - Original Message - From: geetanjali mehra mailtogeetanj...@gmail.com Subject: Re: New to MySQL use rpm -i --replacefiles MySQL-server*.rpm While that will work, it really shouldn't happen. I'm a Debian man myself, so I don't know wether it's a problem with the packages or if you simply don't need the -libs package when installing the server. I would, however, suggest using Rug, Zypper or a similar advanced package manager instead of barebones RPM, as those will actually find and install any necessary dependencies, too. -- Unhappiness is discouraged and will be corrected with kitten pictures. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- Geetanjali Mehra Oracle DBA Corporate Trainer Koenig-solutions Moti Nagar,New Delhi
