MySQL Proxy learns R/W Splitting
The trunk version of the MySQL Proxy 0.6.0 just learnt about changing backends within running connection. It is now up to lua-script to decide which backend shall be used to send requests too. We wrote a complete tutorial which covers ever
The trunk version of the MySQL Proxy 0.6.0 just learnt about changing backends within running connection. It is now up to lua-script to decide which backend shall be used to send requests too.
We wrote a complete tutorial which covers everything from:
- building and maintaining a connection pool with high and low water marks
- transparent authentication (no extra auth against the proxy)
- deciding on Query Level which backend to use
and implement a transparent read/write splitter which sends all non-transactional Queries to the slaves and the rest to the master.
As the splitting is in the hands of the lua-scripting level you can use the same to implement sharding or other rules to route traffic on statement level.
Connection Pooling
For R/W Splitting we need a connection pooling. We only switch to another backend if we already have a authenticated connection open to that backend.
The MySQL protocol first does a challenge-response handshake. When we enter the query/result stage it is too late to authenticate new connections. We have to make sure that we have enough open connections to operate nicely.
In the keepalive tutorial we spend quite some code on connection management. The whole connect_servers() function is only to create new connections for all pools.
- create one connection to each backend
- create new connections until we reach min-idle-connections
- if the two above conditions are met, use a connection from the pool
Let's take a glimpse at the code:
<code>--- config -- -- connection pool local min_idle_connections = 4 local max_idle_connections = 8 --- -- get a connection to a backend -- -- as long as we don't have enough connections in the pool, create new connections -- function connect_server() -- make sure that we connect to each backend at least ones to -- keep the connections to the servers alive -- -- on read_query we can switch the backends again to another backend local least_idle_conns_ndx = 0 local least_idle_conns = 0 for i = 1, #proxy.servers do local s = proxy.servers[i] if s.state ~= proxy.BACKEND_STATE_DOWN then -- try to connect to each backend once at least if s.idling_connections == 0 then proxy.connection.backend_ndx = i return end -- try to open at least min_idle_connections if least_idle_conns_ndx == 0 or ( s.idling_connections 0 then proxy.connection.backend_ndx = least_idle_conns_ndx end if proxy.connection.backend_ndx > 0 and proxy.servers[proxy.connection.backend_ndx].idling_connections >= min_idle_connections then -- we have 4 idling connections in the pool, that's good enough return proxy.PROXY_IGNORE_RESULT end -- open a new connection end </code>
The real trick is in
<code>--- -- put the authed connection into the connection pool function read_auth_result(packet) -- disconnect from the server proxy.connection.backend_ndx = 0 end </code>
The proxy.connection.backend_ndx = 0 we disconnect us from the current backend (lua starts indexing at index 1, 0 is out of bounds). If a second connection comes in now it can use this authed connection too as it is in the pool, idling.
By setting proxy.connection.backend_ndx
you control which backend is used to send your packets too. A backend is defined as a entry of the proxy.servers
table. Each connection has (zero or) one backend. The backends all have a address, a type (RW or RO) and a state (UP or DOWN).
As we also might have to many open connections in the pool we close them on shutdown again if necessary:
<code>--- -- close the connections if we have enough connections in the pool -- -- @return nil - close connection -- IGNORE_RESULT - store connection in the pool function disconnect_client() if proxy.connection.backend_ndx == 0 then -- currently we don't have a server backend assigned -- -- pick a server which has too many idling connections and close one for i = 1, #proxy.servers do local s = proxy.servers[i] if s.state ~= proxy.BACKEND_STATE_DOWN and s.idling_connections > max_idle_connections then -- try to disconnect a backend proxy.connection.backend_ndx = i return end end end end </code>
We only search for a backend which has to many open idling connections and use it before we enter the default behaviour of disconnect_client: shutdown the server connection. if proxy.connection.backend_ndx == 0 then
is the "we don't have backend associated right now". We already saw this in read_auth_result
.
Read/Write Splitting
That is our maintainance of the pool. connect_server()
adds new auth'ed connections to the pool, disconnect_client()
closes them again. The read/write splitting is part of the query/result cycle:
<code>-- read/write splitting function read_query( packet ) if packet:byte() == proxy.COM_QUIT then -- don't send COM_QUIT to the backend. We manage the connection -- in all aspects. proxy.response = { type = proxy.MYSQLD_PACKET_ERR, errmsg = "ignored the COM_QUIT" } return proxy.PROXY_SEND_RESULT end -- as we switch between different connenctions we have to make sure that -- we use always the same DB if packet:byte() == proxy.COM_INIT_DB then -- default_db is connection global default_db = packet:sub(2) end if proxy.connection.backend_ndx == 0 then -- we don't have a backend right now -- -- let's pick a master as a good default for i = 1, #proxy.servers do local s = proxy.servers[i] if s.idling_connections > 0 and s.state ~= proxy.BACKEND_STATE_DOWN and s.type == proxy.BACKEND_TYPE_RW then proxy.connection.backend_ndx = i break end end end if packet:byte() == proxy.COM_QUERY and default_db then -- how can I know the db of the server connection ? proxy.queries:append(2, string.char(proxy.COM_INIT_DB) .. default_db) end proxy.queries:append(1, packet) </code>
Up to now it is only making sure that we behave nicely:
- don't forward
COM_QUIT
to the backend as he will close the connection on us - intercept the
COM_INIT_DB
to know which DB the client wants to work on. If we switch to another backend we have to make sure the same DB is used.
The read/write splitting is now following a simple rule:
- send all non-transactional SELECTs to a slave
- everything else goes to the master
We are still in read_query()
<code> -- read/write splitting -- -- send all non-transactional SELECTs to a slave if is_in_transaction == 0 and packet:byte() == proxy.COM_QUERY and packet:sub(2, 7) == "SELECT" then local max_conns = -1 local max_conns_ndx = 0 for i = 1, #proxy.servers do local s = proxy.servers[i] -- pick a slave which has some idling connections if s.type == proxy.BACKEND_TYPE_RO and s.idling_connections > 0 then if max_conns == -1 or s.connected_clients 0 then proxy.connection.backend_ndx = max_conns_ndx end else -- send to master end return proxy.PROXY_SEND_QUERY end </code>
If we found a slave host which has a idling connection we pick it. If all slaves are busy or down, we just send the query to the master.
As soon as we don't need this connection anymore give it backend to the pool:
<code>--- -- as long as we are in a transaction keep the connection -- otherwise release it so another client can use it function read_query_result( inj ) local res = assert(inj.resultset) local flags = res.flags if inj.id ~= 1 then -- ignore the result of the USE <default_db> return proxy.PROXY_IGNORE_RESULT end is_in_transaction = flags.in_trans if is_in_transaction == 0 then -- release the backend proxy.connection.backend_ndx = 0 end end </default_db></code>
The MySQL Protocol is nice and offers us a in-transaction-flag. This operates on the state of the transaction and works across all engines. If you want to make sure that several statements go to the same backend, open a transaction with BEGIN. No matter which storage engine you use.
Possible extensions
While we are here in this div of the code think about another use case:
- if the master is down, ban all writing queries and only allow reading selects against the slaves.
It keeps your site up and running even if your master is gone. You only have to handle errors on write-statements and transactions.
Known Problems
We might have a race-condition that idling connection closes before we can use it. In that case we are in trouble right now and will close the connection to the client.
We have to add queuing of connections and awaking them up when the connection becomes available again to handle this later.
Next Steps
Testing, testing, testing.
<code>$ mysql-proxy / --proxy-backend-addresses=10.0.0.1:3306 / --proxy-read-only-backend-addresses=10.0.0.10:3306 / --proxy-read-only-backend-addresses=10.0.0.12:3306 / --proxy-lua-script=examples/tutorial-keepalive.lua </code>
The above code works for my tests, but I don't have any real load. Nor can I create all the error-cases you have in your real-life setups. Please send all your comments, concerns and ideas to the MySQL Proxy forum.
Another upcoming step is externalizing all the load-balancer code and move it into modules to make the code easier to understand and reuseable.

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











다음 단계를 통해 phpmyadmin을 열 수 있습니다. 1. 웹 사이트 제어판에 로그인; 2. phpmyadmin 아이콘을 찾고 클릭하십시오. 3. MySQL 자격 증명을 입력하십시오. 4. "로그인"을 클릭하십시오.

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템으로, 주로 데이터를 신속하고 안정적으로 저장하고 검색하는 데 사용됩니다. 작업 원칙에는 클라이언트 요청, 쿼리 해상도, 쿼리 실행 및 반환 결과가 포함됩니다. 사용의 예로는 테이블 작성, 데이터 삽입 및 쿼리 및 조인 작업과 같은 고급 기능이 포함됩니다. 일반적인 오류에는 SQL 구문, 데이터 유형 및 권한이 포함되며 최적화 제안에는 인덱스 사용, 최적화 된 쿼리 및 테이블 분할이 포함됩니다.

Redis는 단일 스레드 아키텍처를 사용하여 고성능, 단순성 및 일관성을 제공합니다. 동시성을 향상시키기 위해 I/O 멀티플렉싱, 이벤트 루프, 비 블로킹 I/O 및 공유 메모리를 사용하지만 동시성 제한 제한, 단일 고장 지점 및 쓰기 집약적 인 워크로드에 부적합한 제한이 있습니다.

데이터베이스 및 프로그래밍에서 MySQL의 위치는 매우 중요합니다. 다양한 응용 프로그램 시나리오에서 널리 사용되는 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1) MySQL은 웹, 모바일 및 엔터프라이즈 레벨 시스템을 지원하는 효율적인 데이터 저장, 조직 및 검색 기능을 제공합니다. 2) 클라이언트 서버 아키텍처를 사용하고 여러 스토리지 엔진 및 인덱스 최적화를 지원합니다. 3) 기본 사용에는 테이블 작성 및 데이터 삽입이 포함되며 고급 사용에는 다중 테이블 조인 및 복잡한 쿼리가 포함됩니다. 4) SQL 구문 오류 및 성능 문제와 같은 자주 묻는 질문은 설명 명령 및 느린 쿼리 로그를 통해 디버깅 할 수 있습니다. 5) 성능 최적화 방법에는 인덱스의 합리적인 사용, 최적화 된 쿼리 및 캐시 사용이 포함됩니다. 모범 사례에는 거래 사용 및 준비된 체계가 포함됩니다

MySQL은 성능, 신뢰성, 사용 편의성 및 커뮤니티 지원을 위해 선택됩니다. 1.MYSQL은 효율적인 데이터 저장 및 검색 기능을 제공하여 여러 데이터 유형 및 고급 쿼리 작업을 지원합니다. 2. 고객-서버 아키텍처 및 다중 스토리지 엔진을 채택하여 트랜잭션 및 쿼리 최적화를 지원합니다. 3. 사용하기 쉽고 다양한 운영 체제 및 프로그래밍 언어를 지원합니다. 4. 강력한 지역 사회 지원을 받고 풍부한 자원과 솔루션을 제공합니다.

Apache는 데이터베이스에 연결하여 다음 단계가 필요합니다. 데이터베이스 드라이버 설치. 연결 풀을 만들려면 Web.xml 파일을 구성하십시오. JDBC 데이터 소스를 작성하고 연결 설정을 지정하십시오. JDBC API를 사용하여 Connections, 명세서 작성, 매개 변수 바인딩, 쿼리 또는 업데이트 실행 및 처리를 포함하여 Java 코드의 데이터베이스에 액세스하십시오.

Docker에서 MySQL을 시작하는 프로세스는 다음 단계로 구성됩니다. MySQL 이미지를 가져와 컨테이너를 작성하고 시작하고 루트 사용자 암호를 설정하고 포트 확인 연결을 매핑하고 데이터베이스를 작성하고 사용자는 데이터베이스에 모든 권한을 부여합니다.

Centos에 MySQL을 설치하려면 다음 단계가 필요합니다. 적절한 MySQL Yum 소스 추가. mysql 서버를 설치하려면 yum install mysql-server 명령을 실행하십시오. mysql_secure_installation 명령을 사용하여 루트 사용자 비밀번호 설정과 같은 보안 설정을 작성하십시오. 필요에 따라 MySQL 구성 파일을 사용자 정의하십시오. MySQL 매개 변수를 조정하고 성능을 위해 데이터베이스를 최적화하십시오.
