Mysql Read-Write with Session Does not work as intended (Auth failure)

[wmwmwm]

• Laravel Version: 5.4.x & 5.5.x
• PHP Version: 7x
• Database Driver & Version:
  mysql 5.6

Description:

Laravel Database session is not compatible with laravel master-slave mysql read-write option. If you set a read and write server in your database config in laravel, then use database sessions. Session driver writes session into master mysql (write config), then instantly tries to read from slave server (read config) but in this short time, mysql didn't have enough time to sync slave server from master server. So, most of the session requests gets wrong session data or just get authentication failures.

Sticky mode is: true, but didn't fix.

Steps To Reproduce:

1- Set laravel sessions to stored in database.
2- Setup a master and a slave mysql server.
3- Setup laravel to use write and read servers to master and slave mysql servers.

Read-Write setting in laravel:
https://laravel.com/docs/5.5/database#read-and-write-connections

Then, try to log-in 20-30 times with laravel auth.

Suggestion to fix:
Always read & write to "write database server" in mysql config in laravel only in session management. It should fix the problem.

And related pull request (I don't know if it fixed the situation):
#20445

Thanks.

[themsaid]

Yes I believe this fixes the scenario you shared, but the fix is on master branch since it's a breaking change, @laurencei yes?

[laurencei]

That PR is already merged for 5.5 and fixes normal master/slave write issues. To be honest; I never tested it with the session driver (it never occurred to me). My guess is the session driver does not trigger the “sticky” write. But I suppose one question is if you have the requirements for a master/slave DB - then you probably also have the need for a proper session management like Redis or Memcache. I’ll check it out when I get home and see what I can find... should be an easy fix...

[wmwmwm]

Thank for your responses. We already started using redis for session storage. Just wanted to notice you guys.

Thanks.

[laurencei]

Actually - I think this a non-fixable problem.

The issue is when write does occur, it'll write to the database for a new session and the "sticky" session is working as intended.

But as the page is reloaded for a redirect, it will trigger a new request. This new request will be read only, so hits the slave database. If your slave database is slightly behind replication (even just 1s) - the session will not exist there. I dont see any way around it - there is no way to know in advance which connection to use if you dont actually have the session info.

So dont use master/slave databases for sessions - you'll get these errors and there's no real way around it. If you absoluletly have to - then configure a different database connection for the sessions only - which only reads/writes to your master database and does not use the slave/read connection. That ensures all sessions are valid and is a simple solution that can be implemented without any code changes.

[laurencei]

@themsaid - this can be closed. It's a non supported scenario and there is no way we can support (fix) it.

[wmwmwm]

At least, this situation should be notified in documentation in session and db read-write options. Don't you agree?

Thanks.

[laurencei]

@wmwmwm yes :)

You can do a PR on the laravel/docs to highlight this there :)