Mats,
Just a few thoughts.
1. Correct me if I'm wrong but, isn't replication going to be a module?
It makes me kind of nervous to hear about changes that will tie dirzzle
to one form of replication, what ever format that might be.
2. There are some very good reasons to use statement based replication.
-Users do dumb things from time to time and it is nice to be able to
restore a db w/ a known position, parse the output from mysqlbinlog to
remove a given transaction, and roll the database forward. I know this
doesn't work in all situations but, it has been a very good "undo"
button for us in the past.
-The performance gain you are talking about applies to the number of
seconds behind the db is but, in a situation where there is high latency
and the db is for disaster recovery I would rather have a faster relay
log. I am assuming that the "raw data" format you are talking about
would be a row based and probably larger than the tradition statement
based system.
I guess I would rather see drizzle stay flexible where replication is
concerned. I'm all for making a quicker executing replication the
default. What do you think?
Just my take on things.
--Koa
On Sun, 2008-08-03 at 21:32 +0200, Mats Kindahl wrote:
> Hi!
>
> Long-term, I would like to see the table definitions stored in
> (transactional) tables. That would mean that:
>
> - DDL operations can be replicated as tables changes, even in row format
> - DDL operations can be transactional (provided the tables holding the
> transactional data is transactional)
>
> Since we are aiming for a micro-server that can be a component of a
> cloud, I think that we, long-term, have to move to a raw data format for
> replication: the current replication system lacks in performance and it
> would be beneficial to be able to treat all changes that need to
> replicate in the same manner. This simplifies the logic, hence shrinks
> the code base and eliminates the number of code paths, hence improves
> performance of the replication (and of the system in general).
>
> Just my few cents,
> Mats Kindahl
>
> Brian Aker wrote:
> > Hi!
> >
> > 1) Engines should be asked about tables, and tables belong to engines.
> > 2) We still need some sort of FRM for Engines which have no ability to
> > handle their own data dictionaries.
> >
> > The current Unireg format is a real pain in the butt and has not been
> > scaling well with recent additions. It pre-set binary type.
> >
> > Three methods for storage:
> > 1) XML (slow)
> > 2) SQL (tamper-able/less slow)
> > 3) Binary Stream
> >
> > Personally I am for types 2 or 3 for a serial method. In fact I am for
> > both being added to the table class.
> >
> > For the binary type though I see a few choices:
> > 1) Google Protocols (not in distributions, beta)
> > 2) Science Types/ASN (also not in distributions)
> > 3) Envelope style (you have to roll your own, but cake to do (think ID3)).
> >
> > Thoughts? Additional ones?
> >
> > I lean toward #3 only because I fear the hassle factor in the above ones
> > (it is also simple and easy to understand). I am hoping we can get our
> > hands into Innodb and just use its for tables it has.
> >
> > Oh, and why do engines need to know? If an engine is not available we do
> > not want to know about its tables, and if an engine is network based
> > things get a lot more complicated.
> >
> > BTW for methods think:
> >
> > tbl = new Table(binary/char array);
> >
> > and:
> >
> > char *ptr= table->serialze();
> >
> > or
> > char *ptr= table->create_table_string();
> >
> > Cheers,
> > -Brian
> >
> > --
> > _______________________________________________________
> > Brian "Krow" Aker, brian at tangent.org
> > Seattle, Washington
> > http://krow.net/ <-- Me
> > http://tangent.org/ <-- Software
> > _______________________________________________________
> > You can't grep a dead tree.
> >
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~drizzle-discuss
> > Post to : [email protected]
> > Unsubscribe : https://launchpad.net/~drizzle-discuss
> > More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~drizzle-discuss
> Post to : [email protected]
> Unsubscribe : https://launchpad.net/~drizzle-discuss
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
