- Original Message -
> From: "Claudio Nanni"
>
> I think this is the best option for you:
> http://www.percona.com/docs/wiki/percona-xtrabackup:start
I must say, I still haven't looked very well at xtrabackup. How does it take
consistent backups of MyISAM tables? I didn't think that was
Both MYISAM & Innodb Engines are used.
Thanks
Nilnandan Joshi wrote:
Can you tell us which storage engine you are using?
On Tue, Jun 7, 2011 at 11:30 AM, Adarsh Sharma
mailto:adarsh.sha...@orkash.com>> wrote:
Dear all,
Is it possible to take backups of a table or complete database
Hi
We use the --single-transaction switch thinking it does less locking or waiting
for a required table lock. You then get a snapshot without stopping.
Subject should have included the word 'hot'? Looking forward to other
suggestions.
Mark
On 2011/06/07 08:00, Adarsh Sharma wrote:
> Dear all,
Can you tell us which storage engine you are using?
On Tue, Jun 7, 2011 at 11:30 AM, Adarsh Sharma wrote:
> Dear all,
>
> Is it possible to take backups of a table or complete database without
> stopping the application that continuously inserts and select data from the
> tables.
>
> For taking c
Hi Adarsh,
I think this is the best option for you:
http://www.percona.com/docs/wiki/percona-xtrabackup:start
There is also a commercial alternative, InnoBackup, but I imagine you like
it free.
Cheers
Claudio
On Jun 7, 2011 7:59 AM, "Adarsh Sharma" wrote:
> Dear all,
>
> Is it possible to take
Dear all,
Is it possible to take backups of a table or complete database without
stopping the application that continuously inserts and select data from
the tables.
For taking complete backup of a database I follow the below steps :-
1. First stop the application that insert & modifies table
- Original Message -
> From: sono...@fannullone.us
>
> description? Why would removing the NULL default cause data to be
> lost?
What exactly do you mean by "removing the NULL default"? Did you set your
colums NOT NULL?
--
Bier met grenadyn
Is als mosterd by den wyn
Sy d
Hopefully I won't look like too much of a numbskull here but after
reading some sites on table optimization, I decided to remove the NULL as
default on the fields in my products table. I thought everything went well
until I realized that we hadn't received any orders for 2 days. That's
I am trying to optimize a query that uses a group by on a varchar(255)
column. The column has a large enough cardinality that a 10 character
partial index uniquely covers over 99% of all values. I was hoping
that this partial index would be able to help with the group by
(though obviously not as
On Mon, 06 Jun 2011 18:54 +0200, "Johan De Meersman"
wrote:
> > Excluding 'performance_schema' appears to eliminate the error. And it
> > seems does NOT cause a reliability-of-the-backup problem.
>
> Hah, no, backing that up is utterly pointless.
that's a useful/final confirmation. thx.
> No,
>-Original Message-
>From: Johan De Meersman [mailto:vegiv...@tuxera.be]
>Sent: Monday, June 06, 2011 12:57 PM
>To: Jerry Schwartz
>Cc: mysql@lists.mysql.com
>Subject: Re: Timestamp value
>
>
>I may be mistaken, but isn't UTC pretty much GMT if you don't want subsecond
>precision? Set your
I may be mistaken, but isn't UTC pretty much GMT if you don't want subsecond
precision? Set your server's timezone to GMT and you should get what you want.
- Original Message -
> From: "Jerry Schwartz"
> To: mysql@lists.mysql.com
> Sent: Monday, 6 June, 2011 5:10:22 PM
> Subject: Timest
- Original Message -
> From: ag...@airpost.net
>
> Excluding 'performance_schema' appears to eliminate the error. And it
> seems does NOT cause a reliability-of-the-backup problem.
Hah, no, backing that up is utterly pointless. Never noticed it doing that.
It's basically a virtual schem
When you UPDATE a record, a timestamp field (`t`) is set to the current time
in the time zone given by @@time_zone, correct? That will usually be the local
time.
If somebody in another time zone needs to compare `t` against //their own//
local time, they need to use
CONVERT_TZ(`t`,'my_local_ti
On Mon, 06 Jun 2011 12:44 +0200, "Johan De Meersman"
wrote:
>
> I haven't bothered to look for the "bug", but it seems to me to be quite
> reasonable default behaviour to lock the whole lot when you're dumping
> transactional tables - it ensures you dump all tables from the same
> consistent vi
I haven't bothered to look for the "bug", but it seems to me to be quite
reasonable default behaviour to lock the whole lot when you're dumping
transactional tables - it ensures you dump all tables from the same consistent
view.
I would rather take this up with the ZRM people - it should "just
2011/06/05 23:30 +0200, Reindl Harald
BTW
WHY is everybody ans[w]ering to the list AND the author of the last post?
Because it is a damn' nuisance to enter "answer all" and therupon move the
list-email-address after "To" (as I now did). It would be easier if the
messages contai
17 matches
Mail list logo
