Hi,
Relative newbie here. I am a bit confused about the maximum table size that can be supported by MySQL Cluster. On the one hand everything says it is RAM-constrained, where each table needs to fit into RAM (and then some), on the other hand newer docs claim that disk-based tables are supported as long as the largest index fits into RAM. Also I read posts in this forum about supporting TB's of data (where I can't imagine the index fitting in RAM).
Suppose I use table sizes which cannot be supported by NDB (for whatever reason), would it be possible to make those table innodb and implement regular master->slave->slave synch, using the methods well-known from standard MySQL while accepting the lack of write-availability for these tables? My use case could use this for write-only logging, where the writer process would just store records locally as long as the master was not available.
Thanks,
Ron Arts
Relative newbie here. I am a bit confused about the maximum table size that can be supported by MySQL Cluster. On the one hand everything says it is RAM-constrained, where each table needs to fit into RAM (and then some), on the other hand newer docs claim that disk-based tables are supported as long as the largest index fits into RAM. Also I read posts in this forum about supporting TB's of data (where I can't imagine the index fitting in RAM).
Suppose I use table sizes which cannot be supported by NDB (for whatever reason), would it be possible to make those table innodb and implement regular master->slave->slave synch, using the methods well-known from standard MySQL while accepting the lack of write-availability for these tables? My use case could use this for write-only logging, where the writer process would just store records locally as long as the master was not available.
Thanks,
Ron Arts