Banner
Home News Feeds Planet MySQL
Newsfeeds
Planet MySQL
Planet MySQL - http://www.planetmysql.org/

  • HeidiSQL 9.2 released
    This is a new release with some new features and many bugfixes and enhancements. Get it from the download page. Changelog: * New feature: Add support for JSON grid export * New feature: Add support for Markdown Here grid export * New feature: Support new command line parameter "n", or "nettype", which takes an integer, representing the protocol number (0=mysql tcpip, ...). * New feature: Add support for connecting to Microsoft Azure Servers * New feature: Add edit box + updown buttons for limiting the size of exported INSERT queries in bytes. * New feature: Display creation time, last alter time, comment and start time of scheduled events. * New feature: Online help document available. Various "Help" buttons in relevant dialogs link to this document. * Bugfix: Dropping functions and procedures on PostgreSQL now with required parameters list * Bugfix: Size bars in "Database" tab on PostgreSQL now with correct values * Bugfix: Loading full grid data on PostgreSQL did not work on text columns * Bugfix: Fix microseconds in MSSQL date/time data types, hidden in data and query grids. * Bugfix: Use ISO 8601 date/time format on MSSQL * Bugfix: PostgreSQL: Fix wrong order of columns shown in indexes, and show normal indexes also * Bugfix: Do not uppercase ENUM values in procedure parameter datatypes * Bugfix: Fix crash when right-clicking a database, following by a click on "Drop" * Bugfix: Version conditional disabling for "Create new" menu items in MySQL mode only * Bugfix: TEXT data type has a maximum length of 65k for MySQL only. Introduce other values for MSSQL and PostgreSQL. * Bugfix: Fix memory leak in TfrmTableTools.SaveSettings * Bugfix: Let longer data type matches win over shorter ones, especially important on PostgreSQL * Bugfix: Make TPGConnection.FetchDbObjects compatible to pre-9.0 servers on PostgreSQL * Bugfix: Fix non working addition of new columns in MySQL * Bugfix: Detect xid type (oid 28) as integer. * Bugfix: Detect character type (oid 1042) as char, not varchar. * Bugfix: Detect aclitem[] type (oid 1034) as unknown, not text. * Bugfix: Fix detection of PostgreSQL data type INTERVAL as VARCHAR. * Enhancement: Automatic storing of settings in portable mode * Enhancement: Optimize query for getting total row count on PostgreSQL * Enhancement: Add support for microsecond precision of MSSQL date/time types in table editor, show these in "Length/Set" column * Enhancement: Add a help button to the quite non-intuitive controls on the export dialog * Enhancement: Add support for JSON data type on PostgreSQL * Enhancement: Add support for HIERARCHYID data type on MSSQL * Enhancement: Increase various default values for window dimensions, for reasonable look and feel for new users * Enhancement: Add "Rename" context menu item in session tree. * Enhancement: Use local number formatting in grids by default * Enhancement: Use transparent background for NULL cells by default * Enhancement: Support columns with a string literal as default value plus an ON UPDATE CURRENT_TIMESTAMP clause. * Enhancement: Increase compatibility when getting procedure body on MSSQL. * Enhancement: Remove duplicates from recent file list pulldown. * Enhancement: Translate connected/disconnected words in status bar * Enhancement: Set focus on filter box when SQL help dialog opens. * Enhancement: Update gettext unit * Enhancement: Make search/replace dialog resizable * Enhancement: Activate "Clear filter" button after applying text to filter memo. * Enhancement: Gracefully remove superfluous WHERE keyword from data grid filter, so other places like the previously modified "More filters" menu do not add a second WHERE. * Enhancement: Use existing data grid WHERE filter to filter values from quick filter > "More values". * Enhancement: Remove outdated details in readme file, and redirect to official help page instead. * Enhancement: Detect all array style types on PostgreSQL as unknown type, e.g. TEXT[]. * Enhancement: Pass column or argument name to NativeToNamedColumnType(), as a hint for the user. * Enhancement: Support quoted datatypes in TDBConnection.GetDatatypeByName, coming from TDBConnection.ParseTableStructure

  • Error reading GTIDs from binary log: -1
    Wonder how MySQL Slave server will act, when disk full condition occurs? Before in our articles we use only single MySQL server. Now think about replication topology, where slave server has problem with full partition. Firstly we will enable Binary Log/GTID on Slave side and will ensure that the changes also applied to binary log on Slave side: # BINARY LOGGING # # server_id = 2 log_bin = /opt/mysql/datadir/mysql-bin log_bin_index = /opt/mysql/datadir/mysql-bin expire_logs_days = 14 sync_binlog = 1 binlog_format = row relay_log = /opt/mysql/datadir/mysql-relay-bin log_slave_updates = 1 read_only = 1 gtid-mode = on enforce-gtid-consistency = true master-info-repository = TABLE relay-log-info-repository = TABLE slave-parallel-workers = 15 binlog-checksum = CRC32 master-verify-checksum = 1 slave-sql-verify-checksum = 1 binlog-rows-query-log_events = 1 When disk full condition comes up, error log will be filled as follows: 2015-05-01 04:42:10 2033 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000002' at position 557, relay log '/opt/mysql/datadir/mysql-relay-bin.000001' position: 4 2015-05-01 04:50:50 7f3b79865700 InnoDB: Error: Write to file ./test1/sales.ibd failed at offset 184549376. InnoDB: 1048576 bytes should have been written, only 688128 were written. InnoDB: Operating system error number 0. InnoDB: Check that your OS and file system support files of this size. InnoDB: Check also that the disk is not full or a disk quota exceeded. InnoDB: Error number 0 means 'Success'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html 2015-05-01 04:50:51 2033 [ERROR] /opt/mysql/bin/mysqld: The table 'sales' is full 2015-05-01 04:50:51 2033 [ERROR] Slave SQL: Worker 14 failed executing transaction '328e26e9-ea51-11e4-8023-080027745404:242' at master log mysql-bin.000002, end_log_pos 275717680; Could not execute Write_rows event on table test1.sales; The table 'sales' is full, Error_code: 1114; handler error HA_ERR_RECORD_FILE_FULL; the event's master log mysql-bin.000002, end_log_pos 275717680, Error_code: 1114 2015-05-01 04:50:51 2033 [Warning] Slave SQL: ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756 2015-05-01 04:50:51 2033 [Note] Error reading relay log event: slave SQL thread was killed 2015-05-01 04:50:51 2033 [Warning] Slave SQL: ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756 2015-05-01 04:50:51 2033 [Warning] Slave SQL: ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756 2015-05-01 04:50:52 2033 [Warning] Disk is full writing '/opt/mysql/datadir/mysql-relay-bin.000003' (Errcode: 28 - No space left on device). Waiting for someone to free space... Interesting thing is OS error number which is equal to 0. And 0 equals to “success”. After if you try disable binary log/GTID and store only relay-log information in my.cnf as follows: # BINARY LOGGING # # server_id = 2 #log_bin = /opt/mysql/datadir/mysql-bin #log_bin_index = /opt/mysql/datadir/mysql-bin #expire_logs_days = 14 #sync_binlog = 1 #binlog_format = row relay_log = /opt/mysql/datadir/mysql-relay-bin #log_slave_updates = 1 read_only = 1 #gtid-mode = on #enforce-gtid-consistency = true master-info-repository = TABLE relay-log-info-repository = TABLE #slave-parallel-workers = 15 #binlog-checksum = CRC32 #master-verify-checksum = 1 #slave-sql-verify-checksum = 1 #binlog-rows-query-log_events = 1 If you try to start there will be some interesting errors in error log: 2015-05-01 05:05:09 2698 [ERROR] /opt/mysql/bin/mysqld: Found a Gtid_log_event or Previous_gtids_log_event when @@GLOBAL.GTID_MODE = OFF. 2015-05-01 05:05:14 2698 [ERROR] Error in Log_event::read_log_event(): 'read error', data_len: 8178, event_type: 30 2015-05-01 05:05:14 2698 [Warning] Error reading GTIDs from binary log: -1 2015-05-01 05:05:15 2698 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. 2015-05-01 05:05:15 2698 [Note] Slave I/O thread: connected to master 'repl@192.168.1.164:3307',replication started in log 'mysql-bin.000002' at position 204643802 2015-05-01 05:05:16 2698 [ERROR] Slave I/O: The slave IO thread stops because the master has @@GLOBAL.GTID_MODE ON and this server has @@GLOBAL.GTID_MODE OFF, Error_code: 1593 2015-05-01 05:05:16 2698 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000002', position 204643802 2015-05-01 05:05:16 2698 [Note] Event Scheduler: Loaded 0 events 2015-05-01 05:05:16 2698 [Note] /opt/mysql/bin/mysqld: ready for connections. Version: '5.6.24-debug' socket: '/opt/mysql/datadir/mysqld-new.sock' port: 3307 Shahriyar Rzayev's MySQL 2015-05-01 05:05:16 2698 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000002' at position 274388137, relay log '/opt/mysql/datadir/mysql-relay-bin.000003' position: 274387894 2015-05-01 05:05:16 2698 [ERROR] Slave SQL: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF. Error_code: 1781 2015-05-01 05:05:16 2698 [Warning] Slave: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF. Error_code: 1781 2015-05-01 05:05:16 2698 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000002' position 274388137 Errors about disabled GTID is normal and it must be here as usual. But must interesting is: [ERROR] Error in Log_event::read_log_event(): 'read error', data_len: 8178, event_type: 30 [Warning] Error reading GTIDs from binary log: -1 [Warning] Error reading GTIDs from binary log: -1. Related BUG report -> #72437 If you have another issue path related to slave server’s disk usage, will be interesting to hear from you. The post Error reading GTIDs from binary log: -1 appeared first on Azerbaijan MySQL UG.

  • LinkBenchX: benchmark based on arrival request rate
    An idea for a benchmark based on the “arrival request” rate that I wrote about in a post headlined “Introducing new type of benchmark” back in 2012 was implemented in Sysbench. However, Sysbench provides only a simple workload, so to be able to compare InnoDB with TokuDB, and later MongoDB with Percona TokuMX, I wanted to use more complicated scenarios. (Both TokuDB and TokuMX are part of Percona’s product line, in the case you missed Tokutek now part of the Percona family.)Thanks to Facebook – they provide LinkBench, a benchmark that emulates the social graph database workload. I made modifications to LinkBench, which are available here: https://github.com/vadimtk/linkbenchX. The summary of modifications isInstead of generating events in a loop, we generate events with requestrate and send the event for execution to one of available Requester thread.At the start, we establish N (requesters) connections to database, which are idle by default, and just waiting for an incoming event to execute.The main output of the benchmark is 99% response time for ADD_LINK (INSERT + UPDATE request) and GET_LINKS_LIST (range SELECT request) operations.The related output is Concurrency, that is how many Requester threads are active during the time period.Ability to report stats frequently (5-10 sec interval); so we can see a trend and a stability of the result.Also, I provide a Java package, ready to execute, so you do not need to compile from source code. It is available on the release page at https://github.com/vadimtk/linkbenchX/releasesSo the main focus of the benchmark is the response time and its stability over time.For an example, let’s see how TokuDB performs under different request rates (this was a quick run to demonstrate the benchmark abilities, not to provide numbers for TokuDB).First graph is the 99% response time (in milliseconds), measured each 10 sec, for arrival rate 5000, 10000 and 15000 operations/sec:or, to smooth spikes, the same graph, but with Log 10 scale for axe Y: So there are two observations: the response time increases with an increase in the arrival rate (as it supposed to be), and there are periodical spikes in the response time.And now we can graph Concurrency (how many Threads are busy working on requests)… …with an explainable observation that more threads are needed to handle bigger arrival rates, and also during spikes all available 200 threads (it is configurable) become busy.I am looking to adopt LinkBenchX to run an identical workload against MongoDB. The current schema is simpleCREATE TABLE `linktable` ( `id1` bigint(20) unsigned NOT NULL DEFAULT '0', `id2` bigint(20) unsigned NOT NULL DEFAULT '0', `link_type` bigint(20) unsigned NOT NULL DEFAULT '0', `visibility` tinyint(3) NOT NULL DEFAULT '0', `data` varchar(255) NOT NULL DEFAULT '', `time` bigint(20) unsigned NOT NULL DEFAULT '0', `version` int(11) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (link_type, `id1`,`id2`), KEY `id1_type` (`id1`,`link_type`,`visibility`,`time`,`id2`,`version`,`data`) ) ENGINE=TokuDB DEFAULT CHARSET=latin1; CREATE TABLE `counttable` ( `id` bigint(20) unsigned NOT NULL DEFAULT '0', `link_type` bigint(20) unsigned NOT NULL DEFAULT '0', `count` int(10) unsigned NOT NULL DEFAULT '0', `time` bigint(20) unsigned NOT NULL DEFAULT '0', `version` bigint(20) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`id`,`link_type`) ) ENGINE=TokuDB DEFAULT CHARSET=latin1; CREATE TABLE `nodetable` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `type` int(10) unsigned NOT NULL, `version` bigint(20) unsigned NOT NULL, `time` int(10) unsigned NOT NULL, `data` mediumtext NOT NULL, PRIMARY KEY(`id`) ) ENGINE=TokuDB DEFAULT CHARSET=latin1;I am open for suggestions as to what is the proper design of documents for MongoDB – please leave your recommendations in the comments.The post LinkBenchX: benchmark based on arrival request rate appeared first on MySQL Performance Blog.

  • MariaDB 5.5.43 now available
    Download MariaDB 5.5.43 beta Release Notes Changelog What is MariaDB 5.5? MariaDB APT and YUM Repository Configuration Generator The MariaDB project is pleased to announce the immediate availability of MariaDB 5.5.43. This is a Stable (GA) release. See the Release Notes and Changelog for detailed information on this release and the What is MariaDB 5.5? page in the MariaDB Knowledge Base for general information about the MariaDB 5.5 series. Thanks, and enjoy MariaDB!

  • Testing MySQL with “read-only” filesystem
    From previous articles about “disk full” conditions, you have some taste of testing MySQL with such approach: 1. Testing Disk Full Conditions 2. Using GDB, investigating segmentation fault in MySQL But there is still untouched topic, about read-only mounted file system and how MySQL will act in such condition. In real life, i have encountered such situation that something happened with Linux server and file system suddenly goes to read-only mode. Buffer I/O error on device sdb1, logical block 1769961 lost page write due to I/O error on sdb1 sd 0:0:1:0: timing out command, waited 360s sd 0:0:1:0: Unhandled error code sd 0:0:1:0: SCSI error: return code = 0x06000008 Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK mptscsih: ioc0: attempting task abort! (sc=ffff8100b629a6c0) sd 0:0:1:0: command: Write(10): 2a 00 00 d8 15 17 00 04 00 00 mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8100b629a6c0) Aborting journal on device sdb1. ext3_abort called. EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only __journal_remove_journal_head: freeing b_committed_data EXT3-fs error (device sdb1) in ext3_new_inode: Journal has aborted ext3_abort called. EXT3-fs error (device sdb1): ext3_remount: Abort forced by user ext3_abort called. EXT3-fs error (device sdb1): ext3_remount: Abort forced by user There was no error message of course because of read-only partition. That’s why we have no chance to detect why MySQL did not start, until we examine OS level issues. In contrast Oracle handles this condition: [root@bsnew home]# su - oracle -bash-3.2$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 7 11:35:10 2014 Copyright (c) 1982, 2013, Oracle. All rights reserved. ERROR: ORA-09925: Unable to create audit trail file Linux-x86_64 Error: 30: Read-only file system Additional information: 9925 ORA-09925: Unable to create audit trail file Linux-x86_64 Error: 30: Read-only file system Additional information: 9925 Of course if you change error log file path to working path there will be messages: 2015-04-28 08:04:16 7f27a6c847e0 InnoDB: Operating system error number 30 in a file operation. InnoDB: Error number 30 means 'Read-only file system'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html 2015-04-28 08:04:16 1486 [ERROR] InnoDB: File ./ibdata1: 'create' returned OS error 130. Cannot continue operation 150428 08:04:17 mysqld_safe mysqld from pid file /home/error_log_dir/mysqld-new.pid ended But it is not useful at this moment, instead, there should be some message while trying starting MySQL directly to STDOUT. If you have more test paths check related feature request and add them: #72259 The post Testing MySQL with “read-only” filesystem appeared first on Azerbaijan MySQL UG.

Banner

 

Copyright © 2001 - 2013 K-Factor Technologies, Inc.



Site Meter

a href=