I'm using the multi master replication (fantastic piece of software btw., thanks!!!) and have installed memcached_functions_mysql functions that allow to talk to a memcached daemon directly from within MySQL using UDFs, i.e.:
SELECT memc_set('myid', 'myvalue'); --- to set value for given key
SELECT memc_get('myid'); --- to get value for given key
SELECT memc_delete('myid'); --- to delete key/value pair
It would be fantastic if one could replicate these calls (or triggers utilizing these functions) across the cluster to be able to invalidate local caches. It is my understanding that with ROW based bin log, only INSERTs and UPDATEs are replicated, not the actual trigger calls.
Imagine that every cluster node has its own memcached instance (nodes are across continents) and this could be used to invalidate cached data across continents too.
What is the point of having node local memcaches? Would it not be more
effective to have shared cache for whole cluster?
Technically it would be quite straightforward to replicate these UDF
calls. UDF replication could go through same pipeline as we use for
MyISAM replication now. Only challenge is in identifying which calls
to replicate, and to make the replication generic enough. Maybe there
should be a list of to-be-replicated UDFs, like:
wsrep_replicate_UDFs='memc_set,memc_delete'
...and these could be caught in parser.
-seppo
On 4 touko, 11:09, Ludek Dolejsky <lu...@dolejsky.com> wrote:
> I'm using the multi master replication (fantastic piece of software btw.,
> thanks!!!) and have installed memcached_functions_mysql functions that
> allow to talk to a memcached daemon directly from within MySQL using UDFs,
> i.e.:
> SELECT memc_set('myid', 'myvalue'); --- to set value for given key
> SELECT memc_get('myid'); --- to get value for given key
> SELECT memc_delete('myid'); --- to delete key/value pair
> It would be fantastic if one could replicate these calls (or triggers
> utilizing these functions) across the cluster to be able to invalidate
> local caches. It is my understanding that with ROW based bin log, only
> INSERTs and UPDATEs are replicated, not the actual trigger calls.
> Imagine that every cluster node has its own memcached instance (nodes are
> across continents) and this could be used to invalidate cached data across
> continents too.
<seppo.jaak...@codership.com> wrote:
> What is the point of having node local memcaches? Would it not be more
> effective to have shared cache for whole cluster?
> Technically it would be quite straightforward to replicate these UDF
> calls. UDF replication could go through same pipeline as we use for
> MyISAM replication now. Only challenge is in identifying which calls
> to replicate, and to make the replication generic enough. Maybe there
> should be a list of to-be-replicated UDFs, like:
> wsrep_replicate_UDFs='memc_set,memc_delete'
> ...and these could be caught in parser.
> -seppo
> On 4 touko, 11:09, Ludek Dolejsky <lu...@dolejsky.com> wrote:
>> Hi all,
>> I'm using the multi master replication (fantastic piece of software btw.,
>> thanks!!!) and have installed memcached_functions_mysql functions that
>> allow to talk to a memcached daemon directly from within MySQL using UDFs,
>> i.e.:
>> SELECT memc_set('myid', 'myvalue'); --- to set value for given key
>> SELECT memc_get('myid'); --- to get value for given key
>> SELECT memc_delete('myid'); --- to delete key/value pair
>> It would be fantastic if one could replicate these calls (or triggers
>> utilizing these functions) across the cluster to be able to invalidate
>> local caches. It is my understanding that with ROW based bin log, only
>> INSERTs and UPDATEs are replicated, not the actual trigger calls.
>> Imagine that every cluster node has its own memcached instance (nodes are
>> across continents) and this could be used to invalidate cached data across
>> continents too.
>> Any ideas? Thanks.
> --
> You received this message because you are subscribed to the Google Groups "codership" group.
> To post to this group, send email to codership-team@googlegroups.com.
> To unsubscribe from this group, send email to codership-team+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/codership-team?hl=en.
> Wouldn't they get replicated already if instead of SELECT you use
> UPDATE and a MyISAM table:
> UPDATE myisamtable SET foo=memc_set(...)
> henrik
> On Mon, May 7, 2012 at 10:54 AM, Seppo Jaakola
> <seppo.jaak...@codership.com> wrote:
>> What is the point of having node local memcaches? Would it not be more
>> effective to have shared cache for whole cluster?
>> Technically it would be quite straightforward to replicate these UDF
>> calls. UDF replication could go through same pipeline as we use for
>> MyISAM replication now. Only challenge is in identifying which calls
>> to replicate, and to make the replication generic enough. Maybe there
>> should be a list of to-be-replicated UDFs, like:
>> wsrep_replicate_UDFs='memc_set,memc_delete'
>> ...and these could be caught in parser.
>> -seppo
>> On 4 touko, 11:09, Ludek Dolejsky <lu...@dolejsky.com> wrote:
>>> Hi all,
>>> I'm using the multi master replication (fantastic piece of software btw.,
>>> thanks!!!) and have installed memcached_functions_mysql functions that
>>> allow to talk to a memcached daemon directly from within MySQL using UDFs,
>>> i.e.:
>>> SELECT memc_set('myid', 'myvalue'); --- to set value for given key
>>> SELECT memc_get('myid'); --- to get value for given key
>>> SELECT memc_delete('myid'); --- to delete key/value pair
>>> It would be fantastic if one could replicate these calls (or triggers
>>> utilizing these functions) across the cluster to be able to invalidate
>>> local caches. It is my understanding that with ROW based bin log, only
>>> INSERTs and UPDATEs are replicated, not the actual trigger calls.
>>> Imagine that every cluster node has its own memcached instance (nodes are
>>> across continents) and this could be used to invalidate cached data across
>>> continents too.
>>> Any ideas? Thanks.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "codership" group.
>> To post to this group, send email to codership-team@googlegroups.com.
>> To unsubscribe from this group, send email to
>> codership-team+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/codership-team?hl=en.
On Mon, May 7, 2012 at 2:22 PM, <seppo.jaak...@codership.com> wrote:
> Quoting Henrik Ingo <henrik.i...@avoinelama.fi>:
>> Wouldn't they get replicated already if instead of SELECT you use
>> UPDATE and a MyISAM table:
>> UPDATE myisamtable SET foo=memc_set(...)
>> henrik
>> On Mon, May 7, 2012 at 10:54 AM, Seppo Jaakola
>> <seppo.jaak...@codership.com> wrote:
>>> What is the point of having node local memcaches? Would it not be more
>>> effective to have shared cache for whole cluster?
>>> Technically it would be quite straightforward to replicate these UDF
>>> calls. UDF replication could go through same pipeline as we use for
>>> MyISAM replication now. Only challenge is in identifying which calls
>>> to replicate, and to make the replication generic enough. Maybe there
>>> should be a list of to-be-replicated UDFs, like:
>>> wsrep_replicate_UDFs='memc_set,memc_delete'
>>> ...and these could be caught in parser.
>>> -seppo
>>> On 4 touko, 11:09, Ludek Dolejsky <lu...@dolejsky.com> wrote:
>>>> Hi all,
>>>> I'm using the multi master replication (fantastic piece of software
>>>> btw.,
>>>> thanks!!!) and have installed memcached_functions_mysql functions that
>>>> allow to talk to a memcached daemon directly from within MySQL using
>>>> UDFs,
>>>> i.e.:
>>>> SELECT memc_set('myid', 'myvalue'); --- to set value for given key
>>>> SELECT memc_get('myid'); --- to get value for given key
>>>> SELECT memc_delete('myid'); --- to delete key/value pair
>>>> It would be fantastic if one could replicate these calls (or triggers
>>>> utilizing these functions) across the cluster to be able to invalidate
>>>> local caches. It is my understanding that with ROW based bin log, only
>>>> INSERTs and UPDATEs are replicated, not the actual trigger calls.
>>>> Imagine that every cluster node has its own memcached instance (nodes
>>>> are
>>>> across continents) and this could be used to invalidate cached data
>>>> across
>>>> continents too.
>>>> Any ideas? Thanks.
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "codership" group.
>>> To post to this group, send email to codership-team@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> codership-team+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/codership-team?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "codership" group.
>> To post to this group, send email to codership-team@googlegroups.com.
>> To unsubscribe from this group, send email to
>> codership-team+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/codership-team?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "codership" group.
> To post to this group, send email to codership-team@googlegroups.com.
> To unsubscribe from this group, send email to
> codership-team+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/codership-team?hl=en.
Having local memcached(s) makes lot of sense as nodes are located on different continents with quite some latency (typically >200 ms) between them.
Using MyISAM tables is an interesting idea, but I'm using Percona Cluster (should have mentioned that) which only replicates changes in InnoDB tables... I might try installing pure galera and check that out.
On Monday, May 7, 2012 10:18:07 PM UTC+10, Henrik Ingo wrote:
> Well, but the table is just bogus anyway. You could just create > table1, table2, ... table100 and update one of them at random.
> henrik
> On Mon, May 7, 2012 at 2:22 PM, <seppo.jaak...@codership.com> wrote:
> > Quoting Henrik Ingo <henrik.i...@avoinelama.fi>:
> >> Wouldn't they get replicated already if instead of SELECT you use > >> UPDATE and a MyISAM table:
> >> UPDATE myisamtable SET foo=memc_set(...)
> >> henrik
> >> On Mon, May 7, 2012 at 10:54 AM, Seppo Jaakola > >> <seppo.jaak...@codership.com> wrote:
> >>> What is the point of having node local memcaches? Would it not be more > >>> effective to have shared cache for whole cluster?
> >>> Technically it would be quite straightforward to replicate these UDF > >>> calls. UDF replication could go through same pipeline as we use for > >>> MyISAM replication now. Only challenge is in identifying which calls > >>> to replicate, and to make the replication generic enough. Maybe there > >>> should be a list of to-be-replicated UDFs, like:
> >>> wsrep_replicate_UDFs='memc_set,memc_delete'
> >>> ...and these could be caught in parser.
> >>> -seppo
> >>> On 4 touko, 11:09, Ludek Dolejsky <lu...@dolejsky.com> wrote:
> >>>> Hi all,
> >>>> I'm using the multi master replication (fantastic piece of software > >>>> btw., > >>>> thanks!!!) and have installed memcached_functions_mysql functions > that > >>>> allow to talk to a memcached daemon directly from within MySQL using > >>>> UDFs, > >>>> i.e.:
> >>>> SELECT memc_set('myid', 'myvalue'); --- to set value for given key
> >>>> SELECT memc_get('myid'); --- to get value for given key
> >>>> SELECT memc_delete('myid'); --- to delete key/value pair
> >>>> It would be fantastic if one could replicate these calls (or triggers > >>>> utilizing these functions) across the cluster to be able to > invalidate > >>>> local caches. It is my understanding that with ROW based bin log, > only > >>>> INSERTs and UPDATEs are replicated, not the actual trigger calls.
> >>>> Imagine that every cluster node has its own memcached instance (nodes > >>>> are > >>>> across continents) and this could be used to invalidate cached data > >>>> across > >>>> continents too.
> >>>> Any ideas? Thanks.
> >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "codership" group. > >>> To post to this group, send email to codership-team@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> codership-team+unsubscribe@googlegroups.com. > >>> For more options, visit this group at > >>> http://groups.google.com/group/codership-team?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "codership" group. > >> To post to this group, send email to codership-team@googlegroups.com. > >> To unsubscribe from this group, send email to > >> codership-team+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/codership-team?hl=en.
> > -- > > You received this message because you are subscribed to the Google > Groups > > "codership" group. > > To post to this group, send email to codership-team@googlegroups.com. > > To unsubscribe from this group, send email to > > codership-team+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/codership-team?hl=en.
