List:Replication« Previous MessageNext Message »
From:Diego Martínez Date:November 3 2011 11:55am
Subject:Re: sql_log_bin
View as plain text  
Thank you!!! The insert is not a problem, is a application with only
logical deletes and the tables under "physical deletes" has not unique
columns, etc. The aim is that the machine C is the input for a BI
application.

Something like a simple replication and when "depurate" some tables in hot
in A, stop slave in my C machine, depurate A machine (B machine process
deletes form A), stop slave B, apply the mysqlbinlog to B to pass the
transactions that occurs in parallel  with the depuration to C, (something
like mysqlbinlog <B bin logs> | grep -v delete | mysql <to C machine>) and,
run the slave B and C again (C with a CHANGE MASTER TO MASTER_LOG_POS=<pos
after deletes>).

Thank a lot for all comments! :)


2011/11/2 Ricardo <ricardo@stripped>

> Oh I see your point.
>
> Well, to the original poster of thr question there you have it - this
> system is not intended to allow, at least easily, this kind of maneuver
>
> Ricardo
>
> On 2 Nov 2011, at 21:35, Marcus Bointon <marcus@stripped> wrote:
>
> > On 2 Nov 2011, at 22:04, Ricardo wrote:
> >
> >> For instance run a cron every night to just replicate inserts, not
> deletes - of course this would not be a real-time slaving
> >
> > As said before, simply doing this won't always work. Take this sequence:
> >
> > INSERT INTO mytable SET id = 1, field1 = 'foo';
> > INSERT INTO mytable SET id = 2, field1 = 'bar';
> > DELETE FROM mytable WHERE id = 2; (delete the one we just made)
> > INSERT INTO mytable SET id = 2, field1 = 'foobar'; (insert another one
> to replace it using the same ID)
> >
> > That's fine with normal replication, but if you skip deletes you get
> this:
> >
> > INSERT INTO mytable SET id = 1, field1 = 'foo';
> > INSERT INTO mytable SET id = 2, field1 = 'bar';
> > INSERT INTO mytable SET id = 2, field1 = 'foobar';
> >
> > Which just won't work. This is just a simple (and somewhat obtuse)
> example, but it's not unreasonable and there are a zillion other more
> subtle ways you could do something similar. Anything working around this
> would have to be very clever and complex, and thus probably not worth the
> overhead.
> >
> > As an alternative solution, how about marking records as deleted, and/or
> moving them to another table (perhaps using a storage engine more suited to
> archiving) rather than actually deleting them. That way you simply avoid
> the problem.
> >
> > Marcus
> > --
> > Marcus Bointon
> > Synchromedia Limited: Creators of http://www.smartmessages.net/
> > UK info@hand CRM solutions
> > marcus@stripped | http://www.synchromedia.co.uk/
> >
> >
> >
> >
> > --
> > MySQL Replication Mailing List
> > For list archives: http://lists.mysql.com/replication
> > To unsubscribe:
> http://lists.mysql.com/replication?unsub=1
> >
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe:
> http://lists.mysql.com/replication?unsub=1
>
>

Thread
sql_log_binDiego Martínez2 Nov
  • Re: sql_log_binOleg Tsarev2 Nov
  • Re: sql_log_binJohan De Meersman2 Nov
    • Re: sql_log_binMarcus Bointon2 Nov
    • Re: sql_log_binMySQL)2 Nov
  • Re: sql_log_binRick James2 Nov
    • Re: sql_log_binMarcus Bointon2 Nov
      • Re: sql_log_binRicardo2 Nov
        • Re: sql_log_binMarcus Bointon2 Nov
          • Re: sql_log_binRicardo2 Nov
            • Re: sql_log_binDiego Martínez3 Nov