[MySQL] Removal of MySQL backend from semver v1.0.2

[terwey]

#901 removed MySQL backend support. The PR claims it was removed pre-semver but we are on v1.0.2 which is a tagged and semver name.

The PR mentioned to file an issue if people depended on it, well we do. Yes we have some issues (e.g. fixed table names etc) but those can be worked around.

AWS as a replacement is not really a good option as it requires juggling two endpoints vs just the already in-use MySQL deployment, and it's just the MySQL with extra steps.

Can we have a discussion on returning the support and or providing a proper Interface that a storage backend can just implement itself against? The provided Driver is not for public use:

tessera/log.go

Lines 44 to 45 in de10380

	// Driver is the implementation-specific parts of Tessera. No methods are on here as this is not for public use.
	type Driver any

That would solve the problem too and doesn't require the upstream to maintain backends.

[mhutchinson]

Thanks for the report. We'll discuss this in the team meeting tomorrow. I can't guarantee this outcome will be broadly acceptable, but would you be open to maintaining the MySQL implementation in this repo?

I understand the confusion around the semver. The v1.0.2 README explicitly stated that MySQL was in BETA: https://github.com/transparency-dev/tessera/tree/v1.0.2#storage-drivers, but it's easy to miss.

[terwey]

Based on the design for the AWS one, it already fully integrates the MySQL bit just doesn't expose the read. It depends on the use-case but there was a lot of code duplication, that could be resolved and then the consumer can decide if they want to opt-in to using S3 for reading as a migration path when the scale requires it.

[mhutchinson]

Hi @terwey we discussed this as a team and our original motivation for deleting the standlone MySQL driver code stands. This isn't something we want to maintain. The big benefit of tlog-tiles is that it allows for static content serving, which gets away from the live DB serving lessons that we learned when trying to scale https://github.com/google/trillian.

We recommend that most people should use the POSIX implementation. This is highly portable, scales well, and comes with the benefit that it is highly tested, performance benchmarked, and deployed. Is this an option for you?

If you are still convinced you want to stay with MySQL then we can explore options together for making this available.