On Tue, Sep 16, 2014 at 12:38 PM, Kristian Nielsen wrote:
> Robert Hodges writes:
>
> > In that case it gets complex for outsiders to figure out how to restart
> if
> > there's a failure. Let's say my transaction fails after T1 commits but
> > before
On Thu, Sep 11, 2014 at 12:49 PM, Kristian Nielsen wrote:
> Robert Hodges writes:
>
> > What would be cool is something like a group transaction that other
> threads
> > can join so that the commit becomes atomic. Most of the parallel load use
> > cases I can th
eresting discussions about parallel transactions. It
sounds as if you have something similar baked in and just need to expose
it. (But you probably read W&V closely already before writing any code. :)
Cheers, Robert
On Thu, Sep 11, 2014 at 12:17 AM, Kristian Nielsen wrote:
> Robert H
Thanks Kristian. That's a nice optimization that is difficult to do outside
the DBMS engine.
Cheers, Robert
On Wed, Sep 10, 2014 at 2:39 PM, Kristian Nielsen
wrote:
> Robert Hodges writes:
>
> > There is one thing I have never understood about your parallel apply
> >
Hi Kristian,
There is one thing I have never understood about your parallel apply
algorithm. How do you handle the case where the server crashes when some
threads have committed but others have not? It seems as if you could have
a problem with recovery.
Cheers, Robert Hodges
On Wed, Sep 10
Hi Jonas and Kristian,
The idea of a hybrid approach seems very good. My experience implementing
parallel apply on Tungsten leads me to believe that masters can supply
useful metadata for replication but cannot supply a definitive plan. There
are a number of reasons for this.
1. Slaves do not al
Cheers, Robert
Pavel
On Fri, Mar 14, 2014 at 8:54 AM, Robert Hodges
wrote:
Hi Kristian,
Thanks for the prompt and detailed response!
I’m glad you clarified that GTIDs cannot ever walk backwards. It’s really bad
design if they are not monotonically increasing and comparable. This will
real
)
wrote:
Robert Hodges writes:
> a.) It seems logical that transactions within a group commit should appear
> together in the binlog and should be serialized before and after other
> transactions in the binlog. Is there *any* way this ordering could be
> violated, for example
Hi Kristian,
First of all thanks for the great on-list explanations of your parallel
replication features. It looks as if you are making good progress on a
very hard problem.
Second, this is slightly off-topic but can you expand somewhat on the
semantics of group-committed transactions in the bi
Hi Seppo,
Thanks, that was my assumption as well but life tends to a little more
complex than theory.
Cheers, Robert
On 1/30/10 1:10 AM PST, "seppo.jaak...@codership.com"
wrote:
> Hi Robert,
>
>>> Tungsten consistency checking technology works very well, and there
>>> is no need to "fix it"
> Just wanted to bring to the attention the possibility of opening
> consistency checking in replication API and SQL layers. And that
> multi-master
> consistency checking requires special attention.
>
> Cheers, Seppo
>
> --
> http://www.codership.com seppo.jaak...@co
Hi Kristian,
Thanks for kicking this thread off. I have had a bit of a busy week so it
has taken a while to get around summarizing Continuent thoughts on
improvements.
First of all, we Continuent Tungsten folk have a certain set of problems we
solve with replication. Here are the key use ca
Hi everyone,
We have gone through some of the same wiki vs. real doc thinking on Tungsten
that has come up here in the list. Our conclusion was that you need to do
documentation properly right from the start. This includes:
* Pick one technology and use it consistently.
* Ensure you can deal w
gt; Hi Sergey
>>
>> On 19/06/2009, at 8:12 PM, Sergey Petrunya wrote:
>>>
>>> On Thu, Jun 11, 2009 at 08:45:08AM -0700, Robert Hodges wrote:
>>>>
>>>> This brings up a question for the Maria dev team-what are your plans, if
>>>>
relevant for
this list.
The other question about replication features still is a relevant question.
I'll follow up on the other replies.
Cheers, Robert
On 6/11/09 8:45 AM PDT, "Robert Hodges"
wrote:
> Hi All,
>
> This is a heads-up that we are actively testing Tungsten
ld be pretty straightforward.
Cheers, Robert
On 6/11/09 4:24 PM PDT, "Arjen Lentz" wrote:
Hi Robert
On 12/06/2009, at 1:45 AM, Robert Hodges wrote:
> This is a heads-up that we are actively testing Tungsten Replicator
> against the latest MariaDB build and hope to complete initial
post builds for related
products. Any hints where to go? We would like to post our open source
offerings in a location that is easy for MariaDB users to find.
--
Robert Hodges, CTO, Continuent, Inc.
Email: robert.hod...@continuent.com
Mobile: +1-510-501-3728 Skype: hod
17 matches
Mail list logo
