not really
* it is unlikely that you have 1:4 relations key/data
* you have sql-statement overhead even for tinyint 1
* you have overhead to escape data
Am 16.02.2013 00:55, schrieb Akshay Suryavanshi:
> Harald,
>
> I somewhat dont agree with your statement of mysqldump backup size being way
>
Harald,
I somewhat dont agree with your statement of mysqldump backup size being
way bigger than the actual datasets, just beacuse its SQL plain text. What
I can tell you is, mysqldump files would be significantly smaller than the
total dataset size, because it doesnt contain "index data". So, if
well, that is why i never in my life will dump and import
large databases - never, for no money on the world
backups of whole servers are done with replication and
restored with rsync if needed but why in the world would
someone export large datasets with dependencies to a PLAIN
TEXTFILE and pray
I can't even imagine an SQL dump of a 400GB database would restore anyway.
How long would that take? 3 weeks?
Might want to dump the data to CSV files and the schema to an SQL file if
you want a full dump/restore.
On Fri, Feb 15, 2013 at 4:54 PM, Reindl Harald wrote:
> "our database is 400 GB,
"our database is 400 GB, mysqldump is 600MB" was not a typo and you
honestly believed that you can import this dump to somewhat?
WTF - as admin you should be able to see if the things in front
of you are theoretically possible before your start any action
and 1:400 is impossible, specially because
Your right I am going to run another mysqldump, maybe something
happened and pick this up next week..
Thanks all.
On Fri, Feb 15, 2013 at 5:03 PM, Keith Murphy wrote:
> Something doesn't add up. If the data set is 400 GB then your dump has to
> bigger than 600 mb. That is better than a 400:1 rat
Something doesn't add up. If the data set is 400 GB then your dump has to
bigger than 600 mb. That is better than a 400:1 ratio. Maybe the dump isn't
working correctly or your data set is much smaller? If the dump output is
less than a gig I would just edit it with something like vi and look at the
Am 15.02.2013 22:55, schrieb Mike Franon:
> I am having a real hard time upgrading just from 5.0.96 to 5.1
>
> I did a full mysqldump and then restore the database, keep in mind our
> database is 400 GB, mysqldump is 600MB file, about 30 minutes into the
> restore get this error on one table on
I am having a real hard time upgrading just from 5.0.96 to 5.1
I did a full mysqldump and then restore the database, keep in mind our
database is 400 GB, mysqldump is 600MB file, about 30 minutes into the
restore get this error on one table on an insert:
ERROR 1064 (42000) at line 1388: You have
While it might be GA I would not recommend that you deploy it for a while.
... at least several point releases. There will be new bugs uncovered as it
moves out to a wider audience.
Upgrade to 5.5 (through 5.1) first as it is quite proven. Slave 5.6 off it
and test. Be patient. Save yourself some
Thanks everyone for suggestions.
I am doing this on a test box with a copy of our db before doing this
on production db servers.
I just upgraded from 5.0 to 5.1, and ran mysql_upgrade
and see I have a few tables with the following error:
error: Table upgrade required. Please do "REPAIR TAB
From: "Alex Keda"
To: mysql@lists.mysql.com;
Sent: 6:37 Piątek 2013-02-15
Subject: MySQL 5.1: incorrect arithmetic calculation
( ... cut ...)
>
> but, my desktop calculator gives the result 548.60
>
1. your desktop calculator is wrong
2. correct result is 548.595, variations (548.59 and 548
Hey list,
I've got another peculiar thing going on :-) Let me give you a quick summary of
the situation first: we host a number of Drupal sites, each site and it's db on
separate VMs for reasons that are not important to this scenario. MySQL is
5.0.51a-24+lenny4-log (Debian); I don't have th
- Original Message -
> From: "Alex Keda"
> To: mysql@lists.mysql.com
> Sent: Friday, 15 February, 2013 12:16:18 PM
> Subject: Re: MySQL 5.1: incorrect arithmetic calculation
>
> sorry, I'm too many work... =)
Heh :-) I was thinking, why would that not be correct? It's exactly what the
15.02.2013 14:43, Johan De Meersman пишет:
- Original Message -
From: "Alex Keda"
mysql> SELECT SUM(`Amount`*`Cost`*(1-`Discont`)) as `Summ` FROM
`WorksCompliteAgregate` WHERE (`ContractID` = 10369 AND `Month` = 497);
Based off the select you printed, this comes to EXACTLY 548.595 f
- Original Message -
> From: "Alex Keda"
>
> mysql> SELECT SUM(`Amount`*`Cost`*(1-`Discont`)) as `Summ` FROM
> `WorksCompliteAgregate` WHERE (`ContractID` = 10369 AND `Month` = 497);
Based off the select you printed, this comes to EXACTLY 548.595 for the first
row and 0 for the seco
15.02.2013 15:07, Alex Keda пишет:
OK. But, how about:
mysql> SELECT 365 * 1.67 * ( 1 - 0.10);
+--+
| 365 * 1.67 * ( 1 - 0.10) |
+--+
| 548.5950 |
+--+
1 row in set (0.00 sec)
mysql>
??
sorry, I'm too many
2013/2/14 Robert Citek
>
>
> According to the client, nothing is writing to the slave and
> everything is being logged at the master. I have not had the
> opportunity to independently verified any of this, yet. I do know
> that the slave is not in read-only mode, but rather "we promise not to
>
18 matches
Mail list logo
