The odds of a spurious collision with MD5 (128 bits) can be phrased this way:
If you have 9 Trillion different items, there is one chance in 9 Trillion that
two of them have the same MD5.
To phrase it another way, it is more likely to be hit by a meteor while winning
the mega-lottery.
>
There's an old saying, "If it ain't broke, don't fix it."
Why _might_ 5.6.x or 5.7.x be "better for you"? Sure there might be some
features you might want, might be some performance improvements that you might
notice, etc. And there might be some regressions that will bite you.
Fortunately,
Still more to this saga
Comment 1:
... HAVING x;
The expression ( x ) is evaluated as a true/false value, based on whether x is
nonzero (true) or zero (false). Your 'x' is MIN(date_time) , which is very
likely to be nonzero, hence TRUE. That is, the HAVING does nothing useful.
Comment 2:
Check your ~/.my.cnf and other places where configuration might be causing the
problem (such as "pager").
> -Original Message-
> From: Radoulov, Dimitre [mailto:cichomit...@gmail.com]
> Sent: Wednesday, September 18, 2013 7:32 AM
> To: zxycscj; mysql
> Subject: Re: All command has no cont
bugs.mysql.com
> -Original Message-
> From: Ben Clewett [mailto:b...@clewett.org.uk]
> Sent: Thursday, September 05, 2013 6:38 AM
> To: mysql@lists.mysql.com
> Subject: Core Dump
>
> Dear MySQL,
>
> Using 5.1.56, I have experienced this core dump. Is there anybody out
> there qualified
Assuming that your goal is to migrate an old database, perhaps the things that
will bite you the fastest:
* TYPE=MyISAM --> ENGINE=MyISAM.
* CHARACTER SETs -- no concept in until 4.1. Use DEFAULT CHARACTER SET=latin1
for now. Later you can figure out how to migrate to utf8. (Note that 5.5
d
Please provide SHOW CREATE TABLE and SHOW TABLE STATUS for each table.
It smells like there is an inconsistency in the datatype of facts.accounts.id
and what it is JOINing to.
Also provide the full SELECT.
How much RAM do you have?
> -Original Message-
> From: Johan De Meersman [mailto:v
" certain rows can no longer be found " -- Do CHECK TABLE. (It will take a
lng time.) It may tell you to REPAIR TABLE, which will also take a lng
time; but it will be necessary. (This is a strong reason for going to InnoDB.
But it will be 2x-3x bigger on disk.)
> -Original Messa
> I have to update the query every time.
Therein lies the difficulty with the schema design.
You could write a stored procedure to locate all the tables (use
information_schema.TABLES, etc) and build the UNION, and finally execute it.
The SP would have something very remotely like the foreach y
VIEWs are not well optimized. Avoid them.
The SlowLog will probably point to the worst query; we can help you improve it
(SHOW CREATE TABLE; SHOW TABLE STATUS; EXPLAIN)
Only minutes to go through 10 million records? Sounds good. It takes time to
shovel through that much stuff.
"Sending data
Monday, July 29, 2013 3:38 PM
> To: Rick James; will...@techservsys.com; mysql@lists.mysql.com
> Subject: RE: hypothetical question about data storage
>
> Rick James wrote:
> >
> >For MySQL + RAID, a Linux elevator strategy of 'deadline' or 'noop' is
&g
Most RAID controllers will happily do Elevator stuff like you mentioned.
So will Linux.
For MySQL + RAID, a Linux elevator strategy of 'deadline' or 'noop' is optimal.
(The default, 'cfq', is not as good.)
A RAID controller with multiple drives striped (and optionally parity-checked)
(RAID-5,
"Count the disk hits"
If you have a filesystem directory, consider that it is designed to handle
small numbers of files per directory. Consider that there is a limited cache
for directories, etc. Plus there is the inode (vnode, whatever) storage for
each file. I don't know the details (and i
> 4) 3 tables from the slaves are to be replicated back to the master
NO.
However, consider Percona XtraDb Cluster or MariaDB+Galera. They allow
multiple writable masters. But they won't let you be so selective about tables
not being replicated.
Here are the gotchas for Galera usage:
http:
I'm unclear on your task, but maybe this function will help:
http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_str-to-date
(It is confusing to have "dato" as both a column name and an alias.)
> -Original Message-
> From: Karl-Arne Gjersøyen [mailto:karlar...@gma
Either change it back, or delete the log files so that they will be built in
the new size. (Backup the entire tree, just in case.)
From: Manuel Arostegui [mailto:man...@tuenti.com]
Sent: Tuesday, July 23, 2013 1:05 PM
To: Rick James
Cc: Johan De Meersman; Luis H. Forchesatto; mysql list
Subject
Did you change innodb_log_file_size?
> -Original Message-
> From: Johan De Meersman [mailto:vegiv...@tuxera.be]
> Sent: Tuesday, July 23, 2013 9:57 AM
> To: Luis H. Forchesatto; mysql list
> Subject: Re: InnoDB problem.
>
> Eek.
>
> No immediate clue here, but maybe someone else does - s
For most, not all, production servers, these two are the 'right' settings:
query_cache_type = OFF
query_cache_size = 0
Both are needed to avoid some code paths from being unnecessarily followed.
(Maybe someday, that will be fixed, too.)
I recommend only 50M as the max for _size.
Here are
Another flavor to try:
SELECT COLUMN_NAME,
group_concat(db_tbl SEPARATOR ' ') as db_tbls,
group_concat(DISTINCT info SEPARATOR ' | ') as infos
FROM (
SELECT COLUMN_NAME,
concat(TABLE_SCHEMA, '.', TABLE_NAME) as db_tbl,
concat(COLUMN_TYP
See if you like this:
SELECT TABLE_SCHEMA as db, TABLE_NAME, COLUMN_NAME,
CHARACTER_SET_NAME, COLUMN_TYPE
FROM `COLUMNS`
ORDER BY 3,4,5;
You might be able to embellish on it to avoid consistent definitions, etc.
> -Original Message-
> From: Daevid Vincent [mailto:dae...
Or maybe the number of levels in the BTree?
Rule of Thumb: logarithm base 100
> -Original Message-
> From: Hartmut Holzgraefe [mailto:hart...@skysql.com]
> Sent: Monday, July 08, 2013 6:38 AM
> To: mysql@lists.mysql.com
> Subject: Re: how to get the levels of a table or a index in Mysql
What setting(s) did you change to move to the separate partition?
SHOW VARIABLES LIKE '%bin%';
SHOW VARIABLES LIKE '%dir%';
(there may be other VARIABLES worth checking)
What steps did you take for the move? (Actually move bin.1? Start over? etc?)
Consider using expire_logs_days.
5.0
Set innodb_buffer_pool_size to 70% of _available_ ram. That may be 11G on your
16GB machine, unless you have a lot of other bulky stuff there. Do _not_ make
it so large that it leads to swapping. Swapping is much worse on performance
than shrinking the buffer_pool.
36 seconds for a single-ro
I once found a slowlog called simply "1". But I did not track down the cause.
Possibly it was a not-so-correct configuration script.
SHOW VARIABLES LIKE '%dir%';
ibdata1 grows (never shrinks) when data is added, ALTER is done, etc. It will
reuse free space within itself.
innodb_file_per_tab
Fetch rows_affected after each INSERT/UPDATE. Tally them in @variables, if you
like. The information is not (I think) available after COMMIT.
> -Original Message-
> From: Neil Tompkins [mailto:neil.tompk...@googlemail.com]
> Sent: Tuesday, July 02, 2013 4:30 AM
> To: [MySQL]
> Subject:
The particular example given here is unsafe and slow.
* Without an ORDER BY, you are not guaranteed that the chunks will be distinct.
* If there are any INSERTs/DELETEs between chunk copies, you will get
dups/missing rows for two reasons: the inserted/deleted rows, and the OFFSET
is not quite
FULLTEXT (at least the MyISAM version) has 3 gotchas:
ft_min_word_len=4, stopwords, and the 50% rule
> -Original Message-
> From: shawn green [mailto:shawn.l.gr...@oracle.com]
> Sent: Tuesday, July 02, 2013 10:21 AM
> To: mysql@lists.mysql.com
> Subject: Re: Full text search and & sign as
cgroups won't work for individual MySQL "users", only for mysqld as a whole.
Monitor the slowlog and help the naughty users fix their naughty queries.
> -Original Message-
> From: Rafał Radecki [mailto:radecki.ra...@gmail.com]
> Sent: Tuesday, July 02, 2013 3:07 AM
> To: mysql@lists.mysql
Prefer xfs on RHEL.
Certain stalls are inherent in older InnoDBs, but MariaDB 5.5 should have the
Percona fixes that greatly smoothed out that problem.
What kind of drives? A RAID controller with caching helps for datasets that
big.
innodb_flush_log_at_trx_commit = 1 is a big performance kill
> (`site_id`,`index_date`,`index_month`,`index_year`,`keyword`,`source`,`visits`,
>
> `bounced_visits`,`transactions`,`revenue`,`value_per_click`,`conversions`,`goal_value`);
May we see the SHOW CREATE TABLE? Some of this smells bad.
* It is almost always bad to split day/month/year into multip
Submit a bug:
http://bugs.mysql.com
Alas, you probably cannot provide a reproducible test case. Still, someone
might start at the code and discover a possible cause.
> -Original Message-
> From: Andy Wallace [mailto:awall...@ihouseweb.com]
> Sent: Wednesday, June 26, 2013 3:10 PM
> To: m
Switch to InnoDB so you won't have to repair after crashes.
Caution: InnoDB takes 2x-3x the disk space per table. Be sure to use
innodb_file_per_table=1.
" Repair by sort." is usually much faster than "repair by keycache"; you
probably got 'sort' because of this being big enough: "myisam_sort_
Yeah, why not flush them to disk on a clean shutdown, and periodically before
that?
> -Original Message-
> From: Dotan Cohen [mailto:dotanco...@gmail.com]
> Sent: Sunday, June 23, 2013 10:39 AM
> To: mysql.
> Subject: UPDATE_TIME for InnoDB in MySQL 5.7
>
> The MySQL 5.7 changelog mentio
SHOW GLOBAL STATUS LIKE 'Innodb%';
Then do some math -- usually dividing by Uptime.
That will give you some insight in how hard the I/O is working, and how full
the buffer_pool is.
> -Original Message-
> From: Rafał Radecki [mailto:radecki.ra...@gmail.com]
> Sent: Friday, June 21, 2013 4:
amed “logs/#sql-ib203” and
> appeared after MySQL crash?
>
> i know what happened but how get rid of these two bullshit files after
> *three years* not touched and used by mysqld
>
> Am 20.06.2013 21:28, schrieb Rick James:
> > #sql files are temp tables that vanish when the
#sql files are temp tables that vanish when the ALTER (or whatever) finishes.
If you find one sitting around, it sounds like a crash happened in the middle
of the ALTER.
> -Original Message-
> From: Reindl Harald [mailto:h.rei...@thelounge.net]
> Sent: Wednesday, June 19, 2013 12:19 PM
" Waiting for master to send event" -- just means that nothing is being
replicated at the moment.
The Yes+Yes says that things are running.
Seconds_behind_master = 0 says that the Slave is essentially caught up. NULL
means something is broken. >0 _may_ indicate a problem, or it may indicate a
"I'm the ORIGINAL Rick James, B" (And, I'm still alive.) LOL
If you are using PHP, you might want to stop at 31 bits per INT/SET. PHP seems
not to yet be in the 64-bit world.
> -Original Message-
> From: Daevid Vincent [mailto:dae...@daevid.com]
> S
Thinking out of the box... (And posting my reply at the 'wrong' end of the
email.)...
Are there fewer than 64 genres? Use a SET or BIGINT UNSIGNED.
> > > AND sg.`genre_id` IN (10,38)
> > > AND sg.`genre_id` NOT IN (22,61)
-->
AND genre & ((1<<10) | (1<<38
Soundex is the 'right' approach, but it needs improvement. So, find an
improvement, then do something like this...
Store the Soundex value in a column of its own, INDEX that column, and JOIN on
that column using "=". Thus, ...
* You have spent the effort to convert to Soundex once, not on every
UUID PRIMARY KEY (or even secondary index) --
Once the table gets big enough (bigger than RAM cache), each row INSERTed (or
SELECTed) will be a disk hit. (Rule of Thumb: only 100 hits/sec.) This is
because _random_ keys (like UUID) make caching useless. Actually, the slowdown
will be gradua
(To ramble in a slightly different direction...)
I claim that the world gained half a second when we went from "round time" to
"square time" a few decades ago. Before then, announcers on radio/tv would
look at their round-shape analog clock to see what time it was; they would
perform a ROUND()
g
event, an appointment (potentially in a diff timezone), train schedule, etc.
> -----Original Message-
> From: shawn green [mailto:shawn.l.gr...@oracle.com]
> Sent: Friday, May 24, 2013 6:50 AM
> To: mysql@lists.mysql.com
> Subject: Re: Bug in BETWEEN same DATETIME
>
>
Watch out for CAST(), DATE(), and any other function. In a WHERE clause, if
you hide an indexed column inside a function, the index cannot be used for
optimization.
INDEX(datetime_col)
...
WHERE DATE(datetime_col) = '2013-01-01'
will not use the index!
The workaround is messy, but worth
I use this; it keeps me out of trouble whether I am using
* MySQL's DATE vs DATETIME vs TIMESTAMP
* Sybase dates (to minute or to millisecond, hence :59:59 does not work)
* leap year
WHERE dt >= ?
AND dt < ? + INTERVAL ? DAY
I fill in the first two "?" with the same starting date.
> -
In query syntax, TRUE is the same as 1; FALSE is the same as 0.
A minor syntax note: ENUM('FALSE', 'TRUE') would require quotes when using it.
If you have multiple 'flags', consider the SET datatype. (Yeah, it is somewhat
clumsy.)
If you have installed 5.6, simply try BOOL or BOOLEAN. I susp
ext does less well with simultaneous IOPs than xfs.
> -Original Message-
> From: Manuel Arostegui [mailto:man...@tuenti.com]
> Sent: Wednesday, May 22, 2013 12:22 AM
> To: Rafał Radecki
> Cc: mysql@lists.mysql.com
> Subject: Re: Mysql server - which filesystem to choose? Is it really
> tha
The "fragmented" message is bogus. It says it to everyone. Almost no one
needs to OPTIMIZE their tables.
> -Original Message-
> From: Miguel González [mailto:miguel_3_gonza...@yahoo.es]
> Sent: Tuesday, May 21, 2013 2:03 PM
> To: mysql@lists.mysql.com
> Subject: fragmentation in innodb
Sorry, I can't address your specific question, but I have several other tips,
some of which may save a lot of space...
USING HASH -- ignored; presumably BTree is used instead.
What Version of MySQL? 5.5(?) can drop an InnoDB (only?) index live.
BTrees sometimes grow after any sort of copy/reor
Triggers "use" whatever code you put in them.
Recommendations for what?
> -Original Message-
> From: Aastha [mailto:aast...@gmail.com]
> Sent: Friday, May 10, 2013 11:55 AM
> To: mysql@lists.mysql.com
> Subject: Triggers
>
> If triggers use complex business rules and large transaction.
>
-05-07'.
What does the {} syntax do??
Contradictory:
where `Query1`.`Appointment_Provider_ID` in (9118, 9119, 60922, 9116,
47495)
and `Query1`.`Appointment_Provider_ID` = 60922;
The IN filter does nothing useful.
I think those changes will make the query run _much
1. MyISAM locks _tables_. That can cause other connections to be blocked.
Solution: switch to InnoDB. Caution: There are a few caveats when switching;
see
https://kb.askmonty.org/en/converting-tables-from-myisam-to-innodb/
2. As mentioned by Shawn, the Query Cache can be more trouble than it
MyISAM? Or InnoDB?
Lock_time perhaps applies only to table locks on MyISAM.
SHOW ENGINE InnoDB STATUS;
You may find some deadlocks.
Is Replication involved?
Anyone doing an ALTER?
> -Original Message-
> From: Robinson, Eric [mailto:eric.robin...@psmnv.com]
> Sent: Thursday, May 09, 201
You want to say either "Germany" or "Deutschland", depending on a
"language_code" somewhere?
Remove the strings you have in those tables now; add about 4 new tables, each
one paralleling the existing tables, but more rows and these columns:
* id (the PK of the existing table)
* language code (EN
> 1) Enable log-bin on master2 (slave that will be converted to a master)
That does not 'convert' it -- it makes it both a Master and a Slave (a "Relay").
The CHANGE MASTER is probably correct, but it is difficult to find the right
spot.
A simple way is to
1. Stop all writes everywhere.
2. Wait
WHERE id = UNHEX('36a461c81cab40169791f49ad65a3728')
> -Original Message-
> From: Martin Koch [mailto:m...@issuu.com]
> Sent: Tuesday, April 30, 2013 8:18 AM
> To: mysql@lists.mysql.com
> Subject: Long integer constant problem in views
>
> Hi List
>
> I have a table with a primary key
See also Percona XtraDB Cluster.
Will you nodes be in the same physical location? If so, what about floods,
earthquakes, etc?
"Clouds are ephemeral; data wants to persist"
> -Original Message-
> From: Andrew Morgan [mailto:andrew.mor...@oracle.com]
> Sent: Tuesday, April 30, 2013 12:36
OR would not show dups.
WHERE duespaid AND cat1 OR cat2
means
WHERE (duespaid AND cat1) OR cat2
That is probably not what you wanted -- add parens like
WHERE duespaid AND (cat1 OR cat2 ...)
But...
That is not a good way to build a schema. What will happen when you add
category9?
Plan A: Have
Please provide
SHOW CREATE TABLE cdsem_event_message_idx \G
EXPLAIN SELECT * FROM cdsem_event_message_idx where event_id in () \G
SHOW VARIABLES LIKE 'autocommit';
These can impact DELETE speed:
* secondary indexes
* whether event_id is indexed.
* disk type and speed -- ordin
Or
SELECT ... \G
(replace ';' with '\G')
> -Original Message-
> From: h...@tbbs.net [mailto:h...@tbbs.net]
> Sent: Wednesday, April 24, 2013 9:55 AM
> To: mysql list
> Subject: Re: how to list record in column (instead of a row)
>
> 2013/04/24 09:06 -0700, Rajeev Prasad
> t
ing the memory usage for MySQL is much harder:
> http://www.mysqlperformanceblog.com/2012/03/21/troubleshooting-mysql-
> memory-usage/
>
> 20.04.2013 00:26, Rick James:
>
> > What's the STATUS value of Threads_running? If it really is >
> "~60-100 conne
What's the STATUS value of Threads_running? If it really is "~60-100
connection threads", then there could be any of a few temp allocations for the
queries. Some allocations are per-subquery.
5.6 has a lot of new tricks for optimizing certain subqueries -- such as
testing out all possible ind
ze is probably the biggest
memory consumer, so it is the easiest way to shrink mysqld's footprint.
> -Original Message-
> From: Ilya Kazakevich [mailto:ilya.kazakev...@jetbrains.com]
> Sent: Wednesday, April 17, 2013 8:05 AM
> To: Rick James
> Cc: 'MySQL'
> Su
Sent: Tuesday, April 16, 2013 8:38 AM
> To: mysql@lists.mysql.com
> Subject: Re: Mesaure query speed and InnoDB pool
>
> Hi Rick,
> I thought you have to dedicate 70-80% of available RAM not a total RAM.
> Saying if I have 2 gig of RAM on my exclusively innodb box, and I
&
Run your query twice; take the second time. For most queries the first run
brings everything into cache, then the second gives you a repeatable, though
cached, timing.
Please provide EXPLAIN SELECT, SHOW CREATE TABLE, and we will critique your
indexes and query plan.
Handler* is another way t
An optimization (at least in InnoDB) is to delay updating the secondary
index(es). If you can provide a reproducible test case, it would probably be
worth filing a bug at bugs.mysql.com
> -Original Message-
> From: Andrés Tello [mailto:mr.crip...@gmail.com]
> Sent: Friday, April 05, 201
I would guess it would work.
Better to upgrade to RHEL 6.3.
> -Original Message-
> From: Keith Keller [mailto:kkel...@wombat.san-francisco.ca.us]
> Sent: Friday, April 05, 2013 6:46 AM
> To: mysql@lists.mysql.com
> Subject: Re: MySQL on RHEL4
>
> On 2013-04-05, Nitin Mehta wrote:
> >
> >
Richard, there is more to a system than number of queries.
Please post these in a new thread on http://forums.mysql.com/list.php?24 :
SHOW GLOBAL STATUS;
SHOW VARIABLES;
Ram size
I will do some analysis and provide my opinion.
> -Original Message-
> From: Manuel Arostegui [mailto:
gt; Am 24.03.2013 05:20, schrieb spameden:
> > > 2013/3/19 Rick James :
> > >>> you never have hosted a large site
> > >> Check my email address before saying that.
> > >
> > > :D
> >
> > as said, big company does not have only ge
ld [mailto:h.rei...@thelounge.net]
> Sent: Tuesday, April 02, 2013 2:00 PM
> To: mysql@lists.mysql.com
> Subject: Re: How to change max simultaneous connection parameter in
> mysql.
>
>
>
> Am 02.04.2013 22:56, schrieb Rick James:
> > I hear that nginx is very fas
.rei...@thelounge.net>>
> >
> > Am 24.03.2013 05:20, schrieb spameden:
> > > 2013/3/19 Rick James <mailto:rja...@yahoo-inc.com>>:
> > >>> you never have hosted a large site
> > >> Check my email address before saying that.
How often to OPTIMIZE?
The Short answer: Never.
The Long answer: A _few_ tables _may_ need OPTIMIZE _sometimes_.
One test: Is the "free" space (according to SHOW TABLE STATUS or equivalent
information_schema stuff) is > 10%, then OPTIMIZE. Maybe. However... That
math works OK for MyISAM,
Clustrix now has a software version of their auto-sharding system. (It used to
be that they only sold an 'appliance'.)
> -Original Message-
> From: Andrew Morgan [mailto:andrew.mor...@oracle.com]
> Sent: Monday, March 18, 2013 6:51 AM
> To: Mike Franon
> Cc:
> Subject: RE: mysql cluster
Possibly related:
http://ronaldbradford.com/blog/why-sql_mode-is-important-2011-06-01/
http://rpbouman.blogspot.com/2009/01/mysqls-sqlmode-my-suggestions.html
http://gabrito.com/post/when-installing-mysql-always-set-the-sql-mode
> -Original Message-
> From: h...@tbbs.net [mailto:h...@tbbs
ubject: Re: How to change max simultaneous connection parameter in
> mysql.
>
>
>
> Am 18.03.2013 21:01, schrieb Rick James:
> > 20 is plenty if your pages run fast enough
>
> it is not
> you never have hosted a large site
>
> > Excess clients after MaxClients
If you are running Apache with MaxClients set too high, that can cause the
problem. That Apache setting should be something like 20. (Other web servers
have similar settings.)
> -Original Message-
> From: Igor Shevtsov [mailto:nixofort...@gmail.com]
> Sent: Saturday, March 16, 2013 1:4
error.
> -Original Message-
> From: Reindl Harald [mailto:h.rei...@thelounge.net]
> Sent: Monday, March 18, 2013 12:15 PM
> To: mysql@lists.mysql.com
> Subject: Re: How to change max simultaneous connection parameter in
> mysql.
>
>
>
> Am 18.03.2013 19:26,
Check directory permissions, and check out the 'answers' in here:
http://forums.mysql.com/read.php?10,284776,284936
> -Original Message-
> From: Patrice Olivier-Wilson [mailto:b...@biz-comm.com]
> Sent: Monday, March 18, 2013 12:05 PM
> To: mysql@lists.mysql.com
> Subject: MySQL Error#: 20
select * from tab where anwer_timestamp in (select max(anwer_timestamp) from
tab where q_id in (select distinct q_id from tab) group by q_id);
That query will be extremely slow if you have lots of data. This is because
the construct "in (select...)" is not optimized (until version 5.6).
select
What language are you using?
In Perl, there is
$sth->more_results;
> -Original Message-
> From: Girish Talluru [mailto:girish.dev1...@gmail.com]
> Sent: Wednesday, March 13, 2013 5:24 AM
> To: mysql@lists.mysql.com
> Subject: How to return resultset from MySQL Stored Procedure using
> p
A lot of details are missing...
Engine: MyISAM? InnoDB? other?
Let's see the SELECT.
If InnoDB, let's see the transaction, if it is part of such.
If InnoDB, which (COMPACT, etc) are you using.
You are asking about a single row with the 500MB, correct?
In general, each reques
, 2013 2:46 PM
> To: Rick James
> Cc: mysql@lists.mysql.com
> Subject: Re: auto_increment field behavior
>
> 2013/3/13 Rick James :
> > What settings? (innodb_autoinc_lock_mode comes to mind, but there
> may
> > be others.)
> Hi, Rick.
>
> Many thanks for t
What settings? (innodb_autoinc_lock_mode comes to mind, but there may be
others.)
It is acceptable, by the definition of AUTO_INCREMENT, for it to burn the
missing 15K ids.
> -Original Message-
> From: spameden [mailto:spame...@gmail.com]
> Sent: Tuesday, March 12, 2013 2:34 PM
> To: m
What do _you_ mean by " a new High Availability solution"?
See also Percona Cluster. It uses InnoDB (XtraDB), so that might be zero
change for you. Oops, except that you should check for errors after COMMIT.
> -Original Message-
> From: Johan De Meersman [mailto:vegiv...@tuxera.be]
> S
If it is MyISAM and there is some form of corruption, you might get the symptom
you see. Do CHECK TABLE.
information_schema has the same "flaw" in row count as SHOW TABLE STATUS for
InnoDB.
> -Original Message-
> From: Stillman, Benjamin [mailto:bstill...@limitedbrands.com]
> Sent: Tue
It is safer to have the Slave be a newer version.
> -Original Message-
> From: Reindl Harald [mailto:h.rei...@thelounge.net]
> Sent: Thursday, February 21, 2013 10:30 AM
> To: mysql@lists.mysql.com
> Subject: Re: replication fails after upgrade to 5.6
>
>
>
> Am 21.02.2013 19:11, schrie
* Smells like some huge LONGTEXTs were INSERTed, then DELETEd. Perhaps just a
single one of nearly 500M.
* Yes, there is an impact on full table scans -- it has to step over the empty
spots. Or maybe not -- one big cow chip of 500MB would be easy to leap over.
* OPTIMIZE TABLE is the primary
They are both right. It is a matter of how many decimal places you want to
display:
mysql> SELECT 365 * 1.67 * ( 1 - 0.10);
+--+
| 365 * 1.67 * ( 1 - 0.10) |
+--+
| 548.5950 |
+--+
1 row in set (0.00 sec)
my
the other with precedence of commajoin vs explicit
JOIN.
From: Singer Wang [mailto:w...@singerwang.com]
Sent: Thursday, February 14, 2013 3:41 PM
To: Rick James
Cc: Mihail Manolov; Mike Franon; Akshay Suryavanshi;
Subject: Re: Upgrading form mysql 5.0.90 to 5.5 or 5.6
Its a very pedantic case, but
ilto:mihail.mano...@liquidation.com]
> Sent: Thursday, February 14, 2013 3:30 PM
> To: Rick James
> Cc: Singer Wang; Mike Franon; Akshay Suryavanshi;
>
> Subject: Re: Upgrading form mysql 5.0.90 to 5.5 or 5.6
>
> The ones that didn't work for me required table rearrangement in
Singer, do you have some examples?
> -Original Message-
> From: Singer Wang [mailto:w...@singerwang.com]
> Sent: Thursday, February 14, 2013 2:59 PM
> To: Mihail Manolov
> Cc: Mike Franon; Akshay Suryavanshi;
> Subject: Re: Upgrading form mysql 5.0.90 to 5.5 or 5.6
>
> There are queries
> Is it in read only mode?
Furthermore, are all users logging in as non-SUPER users? Note: root bypasses
the readonly flag!
> -Original Message-
> From: Manuel Arostegui [mailto:man...@tuenti.com]
> Sent: Thursday, February 14, 2013 1:55 PM
> To: Robert Citek
> Cc: mysql
> Subject: Re:
ursday, February 14, 2013 2:59 PM
> To: Rick James
> Cc: mysql
> Subject: Re: slave replication with lots of 'duplicate entry' errors
>
> On Thu, Feb 14, 2013 at 5:46 PM, Rick James
> wrote:
> >> Is it in read only mode?
> > Furthermore, are all users logg
Ditto. I would mysqldump 5.0, load it onto a 5.5 (or 5.6) box that you have as
a slave of the 5.0 master. The load may uncover some issues. Testing reads
may uncover issues. The replication stream will test the writes; it may
uncover issues.
After being comfortable with that, build new slav
AES encryption is weak because it is too easy for the hacker to get the
passphrase.
If you can somehow hide the passphrase behind 'root', you can at least prevent
a non-sudo user from seeing the data. Your web server starts as root, then
degrades itself before taking requests. If it can grab
As a Rule of Thumb, function evaluation time is not significant to the overall
time for running a query. (I see IF and CASE as 'functions' for this
discussion.)
Do you have evidence that says that IF is slower? Perhaps using BENCHMARK()?
> -Original Message-
> From: h...@tbbs.net [m
Do not try to dump or reload information_schema. It is derived meta
information, not real tables.
> -Original Message-
> From: Rafał Radecki [mailto:radecki.ra...@gmail.com]
> Sent: Monday, February 04, 2013 12:17 AM
> To: mysql@lists.mysql.com
> Subject: Mysqldump routines dump, problem
Meta info about the tables is stored in ibdata1. Hence, it is not possible to
copy just the .ibd file to another database or machine. 5.6.x will remedy this
with some export/import commands that do not involve reading/writing the rows
individually. (Ditto for moving partitions.)
(Sorry, I do
Percona or SkySQL may be able to step in and repair it (for $$$).
For the future, switching to XtraDB (as a plugin or as included in MariaDB) may
give you more resilience to such crashes.
> -Original Message-
> From: Larry Martell [mailto:larry.mart...@gmail.com]
> Sent: Friday, February
The hint of a change is in here (search for "secondary"):
http://jorgenloland.blogspot.co.uk/2012/12/favorite-mysql-56-features-optimizer.html
> -Original Message-
> From: Rick James
> Sent: Wednesday, January 30, 2013 1:08 PM
> To: 'Jeremy Chase'; mys
1 - 100 of 673 matches
Mail list logo
