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 w
How would I do an inplace upgrade?
-Original Message-
From: Johan De Meersman
To: Machiel Richards
Cc: mysql mailing list
Subject: Re: Upgrading of mysql database
Date: Mon, 22 Nov 2010 15:25:44 +0100
That would work, yes.
You could also try to upgrade in place - the upgrade scripts
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 wrote:
> How would I do an inplace upgrade?
>
>
>
> -Original M
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.
You'll
On Mon, Nov 22, 2010 at 2:08 PM, John Daisley wrote:
> 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 tools tend to do useful ag
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 wrote:
> Hi All
>
>Sorry for all my posts
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
will
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
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 di
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 be
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, 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 specifically se
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.
-Ori
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. Tools
You are correct, in a master slave setup the slave does not accept writes.
John
On 22 November 2010 11:06, Machiel Richards 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 confirm.
>
>When
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 I
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 ac
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 t
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 changi
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 rath
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 r
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 -
21 matches
Mail list logo
