9a6a528a3f
The cache filter consists of two separate components; the cache itself that evaluates whether a particular query is subject to caching and the actual cache storage. The storage is loaded at runtime by the cache filter. Currently using a custom mechanism; once the new plugin loading macros/mechanism is in place, I'll see if that can be used. There are a few open questions/issues. - Can a GWBUF delivered to the filter contain more MySQL packets than one? If yes, then some queueing mechanism needs to be introduced. Currently the code is written so that the packets are processes in a loop, which will not work. - Currently, the storage API is synchronous. That may work with a storage built upon RocksDB, that writes asynchronously to disk, but not with memcached that can be (and in MaxScale's case would have to be) used asynchronously. Reading may be problematic with RocksDB as values are returned synchronously. So that will stall the thread being used. However, as RocksDB uses in-memory caching and it is possible to arrange so that e.g. selects targeting the same table are stored together, it is not obvious what the impact would be. So as not to block the MaxScale worker threads, there'd have to be a separate thread-pool for RocksDB access and then arrange the data to be moved across. But initially, the inteface is synchronous. - How is the cache configured? The original requirement mentions all sorts of parameters - database name, table name, column name, presence of WHERE clause, regexp, date/time of query, user - but it's not alltogether clear exactly how they should be specified and how they should interract. So initially all selects will be subject to caching with a TTL.
# 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. Email: maxscale@googlegroups.com Forum: http://groups.google.com/forum/#!forum/maxscale Bugs can be reported in the MariaDB Corporation bugs database: https://jira.mariadb.org/projects/MXS/issues # Documentation For information about installing and using MaxScale, please refer to the documentation. It is in Markdown format. You can point your browser to the MaxScale project at GitHub. Look inside the "Documentation" directory, where you will find a file named Documentation-Contents.md. Click on that, and GitHub will show the documentation in its intended display format. The contents page lists the available documents and has links to them. If you do not want to rely on the internet, then clone the project from GitHub and point your browser to the Documentation-Contents.md file in your local file system and proceed as above.