8ea7d8898a
The id has now been moved from mxs::Worker to mxs::RoutingWorker and the implications are felt in many places. The primary need for the id was to be able to access worker specfic data, maintained outside of a routing worker, when given a worker (the id is used to index into an array). Slightly related to that was the need to be able to iterate over all workers. That obviously implies some kind of collection. That causes all sorts of issues if there is a need for being able to create and destroy a worker at runtime. With the id removed from mxs::Worker all those issues are gone, and its perfectly ok to create and destory mxs::Workers as needed. Further, while there is a need to broadcast a particular message to all _routing_ workers, it hardly makes sense to broadcast a particular message too _all_ workers. Consequently, only routing workers are kept in a collection and all static member functions dealing with all workers (e.g. broadcast) have now been moved to mxs::RoutingWorker. Now, instead of passing the id around we instead deal directly with the worker pointer. Later the data in all those external arrays will be moved into mxs::[Worker|RoutingWorker] so that worker related data is maintained in exactly one place.
MaxScale by MariaDB Corporation
The MariaDB Corporation MaxScale is an intelligent proxy that allows forwarding of database statements to one or more database servers using complex rules, a semantic understanding of the database statements and the roles of the various servers within the backend cluster of databases.
MaxScale is designed to provide load balancing and high availability functionality transparently to the applications. In addition it provides a highly scalable and flexible architecture, with plugin components to support different protocols and routing decisions.
MaxScale is implemented in C and makes extensive use of the asynchronous I/O capabilities of the Linux operating system. The epoll system is used to provide the event driven framework for the input and output via sockets.
The protocols are implemented as external shared object modules which can be loaded at runtime. These modules support a fixed interface, communicating the entries points via a structure consisting of a set of function pointers. This structure is called the "module object".
The code that routes the queries to the database servers is also loaded as external shared objects and are referred to as routing modules.
An Google Group exists for MaxScale that can be used to discuss ideas, issues and communicate with the MaxScale community.
We're also on the #maria and #maxscale channels on FreeNode.
Please report all feature requests, improvements and bugs in the MariaDB Jira.
Documentation
For information about installing and using MaxScale, please refer to the documentation. The official documentation can be found on the MariaDB Knowledge Base.
- MariaDB MaxScale 2.1 Documentation
- MariaDB MaxScale 2.0 Documentation
- MariaDB MaxScale 1.4 Documentation
The module and configuration documentation can be found in the Documentation directory of the source tree.
Contributing Code
Read the Contributing page on the wiki for more information on how to do pull request and where to do them.