2 moodles on same server using the same DB server could develop issues in only one instance *IF* there is a difference in the moodle implemations setups. I speak from experience there - have a 'sandbox' server with 3.1, 3.2, and 3.3 ... and original 3.0's that am 'marching upwards' to latest greatest as test. Not bragging here ... just relating experiences and am aware that there are differences and requirements for 3.3 for DB that if not implemented prior to upgrade attempt might come into play.
Googling for dmlreadexception
one sees multiple hits ... some here in these forums ... resolutions may or may not be present ... and may not relate to the issues you are seeing with the authentications.
The link above says to turn on debugging all the way to developer and then share back what moodle is saying - the stack trace. Since you've reverted back to working version that may not show what you need to see.
Maybe you could view your apache error logs from the day of the upgrade attempt to see if there is some hint/clue in those?
Are both using the same authentication methods?
Are both instances databases using the same character set/collation as there is now a change in 3.3 that will in the future become the standard ... utf8mb4
Have you run the environment checks (update the component before reporting what that check says) on both instances to see if one is reporting there needs to be a change in DB?
Then there is the upgrade method ... how are you upgrading? Via new code/FTP etc. etc. old method?
Where hosted? Is there some sort of hosting restriction that might be a factor?
And finally, what operating system? Ok, call me a Linux bigot ... but think that sometimes is a factor in things like upgrading. ;)
Can you setup a sandbox implementation that's a clone of the instance having issues on the same server (better as you would be using the same environment). A sandbox clone you wouldn't have to worry about ... could turn on debugging to the hilt ... try the upgrade ... and report back any details to that here.
'spirit of sharing', Ken