List:Replication« Previous MessageNext Message »
From:Johan De Meersman Date:August 16 2010 12:18pm
Subject:Re: Multi-Master -> Slave -> Long Term Storage
View as plain text  
An interesting idea. I would probably go for a script that copies/moves the
data from the small locations to the centralized archive, as that would be
the easiest way to take your data structure and integrity into account.

On Fri, Aug 13, 2010 at 5:53 PM, Jacob Steinberger <
trefalgar@stripped> wrote:

> I don't know if what I'm wanting to do is crazy, but I'm hoping I can get
> pointed in either a better direction or to be told what I want isn't easy ;)
> I have multiple small data centers with storage limitations. Inside those
> data centers, I currently have a single mysql database which stores the
> data. What I'm wanting to do is to migrate to a multi-master setup in the
> small data center to be fault tolerant - I've read the docs and that doesn't
> seem to be much of an issue.
> In order to deal with the storage limitations, I'd like to be able to
> connect to that multi-master setup in multiple small data centers to a
> centralized location that I can throw hard drive space at like there's no
> tomorrow. The obvious difference is in the small data centers, I'd want no
> more than X days of data, while in the centralized location I'd want data
> for as long as possible.
> For this, I was thinking of two possible things ...
> 1) To have a slave, or another master, get the data via replication, maybe
> with a filter to prevent deletes from being sent across. However, in that
> case of a resync (and I'm not certain how this works, or if its a concern),
> I wouldn't want the remote locations to sync off the centralized location.
> 2) Have a slave collect the data with normal replication, then use another
> database to scrape the data out via reads (maybe a mysql->mysql procedure)
> that could then be the "long term" database. Downside here is it would be a
> multi-step process and "feels" flimsy (even if it wouldn't be).
> In either case, the database name would be different for each remote data
> center in the "long term" database. This isn't a bad thing, and is probably
> desired so isn't a big concern.
> Would #1 or #2 be more recommended? Am I totally going the wrong direction
> for this kind of database requirement / configuration?
> Jacob
> --
> MySQL Replication Mailing List
> For list archives:
> To unsubscribe:

Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

Multi-Master -> Slave -> Long Term StorageJacob Steinberger13 Aug
  • Re: Multi-Master -> Slave -> Long Term StorageJohan De Meersman16 Aug
    • Re: Multi-Master -> Slave -> Long Term StorageDatabase System16 Aug