Hello,
Thank for your help
I just try mysqldump with --quick or --opt option ... to avoid
out of memory problem but
-- dump fails with --max_allowed_packet=2048M and --quick :
r...@pcjahia01:/# /usr/bin/mysqldump -A --max_allowed_packet=2048M
--quick --default-character-set=UTF8 -u
Good day all
Hope all is well.
I have something to ask as someone might have done this as
well and may have a good solution on how to fix this.
During a database migration this weekend to move a MySQL
database from windows to linux, we created a backup and
Hi All
Sorry but things have now changed, and I found the following.
The tables was in fact restored as Innodb, however someone seems
to have gone and changed something causing innodb to be disabled, this
caused the tables to be defaulted back to MyIsam.
Should this not
I have frequently seen Innodb 'silently' disabled if the
innodb_log_file_size is different to the files size on disk (quite common
when moving systems about). You wont be able to use innodb until you resolve
this either by deleting the log files and restarting mysqld so they get
recreated or
Thank you John
I have in the meantime fond this to be the case (** someone
changed config files without my knowledge it seems as this was setup
properly and working**)
Anyhow, in order for the innodb to be active again I need to
restart the database, however aftewards I assume the
Hi All
sorry to bother everyone again. but now I have a question from a
client which I am sure about my answer, however need to confirm.
When setting up a master/slave replication set.
As I understand it, the slave server can't accept any writes,
however it will be able to
Hi All
Sorry for all my posts today but this one client is keeping me
busy.
the version of MySQL installed on the ubuntu server is
5.0.51a-3ubuntu5.8-log as this was the latest one available in the
repository.
We will need to upgrade this to version 5.1.53.
Am
You are correct, in a master slave setup the slave does not accept writes.
John
On 22 November 2010 11:06, Machiel Richards machi...@rdc.co.za wrote:
Hi All
sorry to bother everyone again. but now I have a question from a
client which I am sure about my answer, however need to
Hi,
I think you are wrong, slaves will always accept writes unless you
set readonly in the mysql config.
Due to this, and if you dont specifically set readonly on the slave
you have to be very careful in order to maintain data integrity on the
slave and also not to break repliacton.
My reason for asking this is the following
The client have database A on one machine, Database B on a second
machine both of which are production.
They want to setup replication of Database B to Server hosting Database
A and still keep Server A as the primary production system.
The replicated database should not be accepting writes, if it is then you
haven't set it up correctly
On 22 November 2010 13:03, a.sm...@ukgrid.net wrote:
Hi,
I think you are wrong, slaves will always accept writes unless you set
readonly in the mysql config.
Due to this, and if you dont
Additionally, if a user has the SUPER privilege (eg. all privileges on
*.*) they can write to a database running in read-only mode. Yet
another reason to never allow this privilege for general purpose users.
Tyler
On 11/22/10 8:08 AM, John Daisley wrote:
The replicated database should not
Hi,
so yes you can do that, but then I guess you cannot set the server
hosting database A as readonly (from memory this can only be set
server wide, but worht checking it out). Which might leave you a few
options to ensure data integrity, for example simply by user security
either by
On Mon, Nov 22, 2010 at 11:55 AM, Machiel Richards
machiel.richa...@gmail.com wrote:
In this event I will need to manually alter each table, and I am
concerned about the impact of this on the system performance.
That will indeed make for quite some locking time, depending on the size
Machiel,
Each table will be write locked while it is being altered so this will
most likely impact the application. In addition to the write lock, the
conversion causes each table to be completely rewritten in the new
format so this will have a high impact on IO write activity and so it
That would work, yes.
You could also try to upgrade in place - the upgrade scripts *should* take
care of everything between those versions, I think. Make sure you have a
backup in any case :-)
On Mon, Nov 22, 2010 at 12:57 PM, Machiel Richards machi...@rdc.co.zawrote:
Hi All
Sorry
On Mon, Nov 22, 2010 at 2:08 PM, John Daisley daisleyj...@googlemail.comwrote:
The replicated database should not be accepting writes, if it is then you
haven't set it up correctly
*shrug*
I never bother. The slave is way too useful to fuck around with
optimisations and whatnot, reporting
Another option, if your data hasn't changed in the mean time (I know, rare
scenario) could be to set up a secondary instance from the same binaries and
changing only the datafile location and the port in the config,
re-importing, shutting both instances down and switching out the datafiles.
Replace the software - if you're using packaged versions, they should take
care of most anything. If not, there's mysql-upgrade or some script. See the
online docs for specifics.
On Mon, Nov 22, 2010 at 3:56 PM, Machiel Richards machi...@rdc.co.zawrote:
How would I do an inplace upgrade?
How would I do an inplace upgrade?
-Original Message-
From: Johan De Meersman vegiv...@tuxera.be
To: Machiel Richards machi...@rdc.co.za
Cc: mysql mailing list mysql@lists.mysql.com
Subject: Re: Upgrading of mysql database
Date: Mon, 22 Nov 2010 15:25:44 +0100
That would work, yes.
You
Another thing to keep in mind is to make sure all your foreign keys
are re-created if you have any. We had a similar accident in our
prod box a few years back and converting MyIsam to InnoDB won't
necessarily re-create the foreign keys.
Kyong
On Mon, Nov 22, 2010 at 6:39 AM, Johan De Meersman
21 matches
Mail list logo
