What is your default LIMIT setting? but well .. a couple a 4 GB LONGBLOBS could be 'funny' 🙁
A reasonable proposal, I think, but TEXT (it is not binary!) and BLOB are equally problematic, whereas a BINARY or VARBINARY type is similar to a CHAR and VARCHAR(up tp 255). And even a lot of 64 KB varchars of MySQL 5 can be equally 'funny'. As of MySQL 5 a VARCHAR, a TEXT and a BLOB are all up to 64 KB.
We will discuss if it is possible to turn of BLOBS, MEDIUMBLOBS and LONGBLOBS (and similar TEXTS)
A workaround is to set LIMIT = 0 in preferences and use the RESULT tab.
offtopic .. well yes this has nothing with SSL-CERTIFICATES to do, right?
There is no known issue. SJA and SQLyog should be totally identical in this respect and normally are. The error message:
“ERROR: 1, HTTP Error. Could not connect to the tunneling URL.”
.. could imply that your URL is not entered correct. Please check the jobfile! URL's are case-sensitive – rememeber!
If you are perfectly sure that everything is OK, could we then have temporary access to the server? We won't need 'real data' – just a dummy database with a few small tables.
we do generate checksums allrady. We just do not save them. I think this save can be implemented on server side alone.
Quote:
what happens if one replication job isn't finished?
it puts a little more load on the server and the connection. that is the only thing that happens. That can happen with current version too. There could be an issue too with conflict when accessing the jobfile of sessionfile. Could cause one of the instance to crash. And so solved 🙂
I do not see any NEW issues with locked tables or CONSTRAINTS.
We have to be realistic and realize that most Webyog Customers use 3.23 and 4.0 hosting on shared server at an ISP. And it will be no less than 5 years before cheap ISP's change over to 5.0, I think!
you got than a big problem, what are you doing when on both (more than 1) servers you have a difference between last checksum and current checksum?
true! that was why I wrote this “it is still not possible to handle situations where THE SAME ROW has been updated on both servers”. 'rules', 'no touch and log' are both possible. I do not like user-interaction as I do not think it makes sense with SJA (and scheduling).
Quote:
i have seen client-applications that couldn't handle additional fields
so maybe something more generic with sqlyog specific tables
It will then have to be a SQLyog-specific DATABASE. ThumbsPlus would not accept an 'alien' TABLE in its database either
Quote:
automatically generated triggers on the tables
Actually Acces Replication Manager uses triggers. I would like to avoid them. Because it should preferably work with all MySQL versions and not only 5.x
I'm not sure if MySQL does have the feature of archive logs
It does not! With MySQL 5.1 you can configure the 'binary log' for row-based repleication, and that log could in principle be used. But in principle only – in practice it is not practicable for preformance reasons. It is alos a log for a complete server and not a database or a table.
Some on the new emerging Storage engines have better logging option. In particular the PrimeXT engine where the table itself is organised as a log.
Quote:
How about a simplified replication mechanism (simple & stupid)? some kind reduced to a timestamp-based replication
I still think that saving the 'checksum for last sync' and comparing each row of data with that for each row is a more perfect solution, because:
1: A MySQL timestamp has an accuracy of 1 second only. Certain data may be updated several times per second on fast servers running heavy business applications
2: System Clocks may get 'out of tune'. That is not only PC's actually. Even on servers that can occur. There is also timezone issues. 'light saving hours'.
With a saved checksum we could do like:
1) When data on the two hosts differ we generate checksum on both hosts and compare with 'last checksum'. The host where cureent checksum and last checksum differ is where data have changed! So for that individual row (only) that will define the host where change has taken place asBut true: it is still not possible to handle situations where THE SAME ROW has been updated on both servers. Also there will need to be a 'rule' whether DELETES has priority to UPDATES, or opposite. Or if such rows should be left untouched and logged instead.
And anything like this will of course need addition of data.
The problem is, SQLyog doesn't know “WHICH DATA IS THE LATEST”!
This is nothing new! We have been discussing for years! Once every second month someone gets the 'smart' idea' to use a timestamp. That is just too simple! There are 'replication managers' for Access and Oracle that we are studying. And yes: Once we get finisshed with the 5.1 stuff (events, partitions) we are actually planning what we can do of the stuff!
Now who says that 'latest is right' is the rule in this situation? It could also be a 'user hierachy'. Or one column could be more important than the other. There are lots of other possibilities. And what if a record has been updated at one server and deleted at the other?
I think the solution is another: To save the checksum on both servers! Because we can then compare the checksum just generated with the checksum from last sync and 'row-based synchronisation' will be possible – that is for each row it will be possible to tell on what server data has changed.
When trying to connect to a MySQL server at an ISP this error message often indicates that direct connection to MySQL has been blocked. You must then use HTTP-tunnelling or SSH-tunnelling to connect.
if your ISP has blocked port 3306 you will need to use tunnelling (available in ENTERPRISE version only)
peterlaursen
Participant
