Bytes limitation on a single replication message

Question

Hi experts,
I have question on the amount of a single replication message.
In the BDB document (ver 4.7.25), DB_ENV->rep_set_limit() describes how to limit the amount of data.
But it describes that "The limit is not a hard limit, and the record that exceeds the limit is the last record to be sent".
Could anyone explain the exact meaning of that phrase?
For example, if I set the limit to 1 MB, then what's the possible maximum?
In which case the replication message could exceed the limit?
Thanks in advance!!
Jinsoo.

Answer 1

tojspark wrote:
What I'm understanding is that the limit is the size of data passed to the communication infrastructure (the function registered via rep_set_transport()). Am I correct?
No, I think you're still confused.
There is no limit on the size of a single replication message.
When the master gets a request (one of these "pull processing"
situations I described previously), it responds by sending out
a series of messages. That is, it sends multiple messages. If no
"limit" is in effect, it just sends as many messages as necessary.
If a limit is in effect, it stops sending messages when the total
cumulative amount of data has met OR EXCEEDED the configured limit.
This is what we mean by saying that it is "not a hard limit."
In other words, it's not a limit on any one single message. It's kind
of a limit on the total amount of data in several messages. But it's
not even really a limit on the total; it's a threshold after which
we'll stop adding more messages.
So, for example, let's say a client requests 10 log records from the
master. Let's say that the master has a 350-byte limit in effect.
- if the first log record is 100 bytes, we send it.
- if the second log record is 100 bytes, we send that.
- if the third log record is 100 bytes, we send it.
- if the fourth log record is 2,000,000 bytes, we send it!
But then we stop.
There are still six more log records that the client wants. But we
stop sending after the fourth. The client will have to request
records 5 through 10 separately. (The replication protocol handles
this automatically. The application doesn't have to do anything to
make this work, other than configuring the limit with
rep_set_limit().)
Thank you for explaining what your concern is. I believe I understand
it, and it does make sense. As I hope you can see, it has nothing to
do with this rep_set_limit() that we've been talking about.
Unfortunately, I'm not sure we can really give you a good, reliable
answer to what the maximum size of a single message could be. It
depends on many factors, including the sizes of update operations,
database page sizes, even the number of databases that exist in the
environment, as well as some of the details of how Berkeley DB is
configured and built.
I think, from a practical perspective, the application using the Base
replication API must be prepared to handle large messages, and do the
fragmentation and re-assembly as necessary.
(Obviously, the "control" and "rec" portions of the message passed to
the call-back function configured with rep_set_transport do have an
architectural size limit. They are both DBT's, and the size of a DBT
is expressed as a 32-bit unsigned binary number. So they can't be
more than 4,294,967,296 bytes each. But I'm sure such a high
theoretical limit is not helpful to you.)
Alan Bram
Oracle