Repository navigation
Expand file tree
/
Copy pathreadme.txt
More file actions
162 lines (120 loc) · 8.19 KB
/
Copy pathreadme.txt
File metadata and controls
162 lines (120 loc) · 8.19 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
=== LudicrousDB ===
Contributors: johnjamesjacoby, spacedmonkey
Author: Triple J Software, Inc.
Author URI: https://jjj.software
Plugin URI: https://github.com/stuttter/ludicrousdb/
License URI: https://www.gnu.org/licenses/gpl-2.0.html
License: GPLv2 or later
Tags: database, mysql, performance, scaling, wpdb
Requires PHP: 7.4
Requires at least: 6.4
Tested up to: 7.1
Stable tag: 5.3.1
LudicrousDB is an advanced database interface for WordPress that supports replication, failover, load balancing, and partitioning.
== Description ==
LudicrousDB is an advanced database interface for WordPress that replaces much of its built-in database functionality.
The main differences are:
* Connects to an arbitrary number of database servers
* Inspects each query to determine the appropriate database
* Designed specifically for large, multisite, high-availability environments
It supports:
* Read and write servers (replication)
* Configurable priority for reading and writing
* Local and remote data centers
* Private and public networks
* Different tables on different databases/hosts
* Smart post-write primary reads
* Failover for a downed host
* Advanced statistics for profiling
It is based on the code currently used in production on WordPress.com and WordPress.org, with many database servers spanning multiple data centers.
It is a fork of Automattic's HyperDB.
= Previous Contributors =
HyperDB's original contributors: matt, andy, ryan, mdawaffe, vnsavage, automattic
== Installation ==
See https://github.com/stuttter/ludicrousdb/wiki/0.-Installation
== Frequently Asked Questions ==
= What can I do with LudicrousDB that I can't do with WPDB? =
WordPress.org, the most complex LudicrousDB installation, manages millions of tables spanning thousands of databases. Dynamic configuration logic allows LudicrousDB to compute the location of tables by querying a central database. Custom scripts constantly balance database server resources by migrating tables and updating their locations in the central database.
Stretch your imagination. You could create a dynamic configuration using persistent caching to gather intelligence about the state of the network. The only constant is the name of the configuration file. The rest, as they say, is PHP.
= How does LudicrousDB support replication? =
LudicrousDB does not provide replication services. That is done by configuring MySQL servers for replication. LudicrousDB can then be configured to use these servers appropriately, e.g. by connecting to primary servers to perform write queries.
= How does LudicrousDB support load balancing? =
LudicrousDB randomly selects database connections from priority groups that you configure. The most advantageous connections are tried first. Thus you can optimize your configuration for network topology, hardware capability, or any other scheme you invent.
= How does LudicrousDB support failover? =
Failover describes how LudicrousDB deals with connection failures. When LudicrousDB fails to connect to one database, it tries to connect to another database that holds the same data. If replication hasn't been set up, LudicrousDB tries reconnecting a few times before giving up.
= How does LudicrousDB support partitioning? =
LudicrousDB allows tables to be placed in arbitrary databases. It can use callbacks you write to compute the appropriate database for a given query. Thus you can partition your site's data according to your own scheme and configure LudicrousDB accordingly.
= Is there any advantage to using LudicrousDB with just one database server? =
None that has been measured. LudicrousDB does at least try again before giving up connecting, so it might help in cases where the web server is momentarily unable to connect to the database server.
One way LudicrousDB differs from WPDB is that LudicrousDB does not attempt to connect to a database until a query is made. Thus a site with sufficiently aggressive persistent caching could remain read-only accessible despite the database becoming unreachable.
= What if all database servers for a dataset go down? =
Since LudicrousDB attempts a connection only when a query is made, your WordPress installation will not kill the site with a database error, but will let the code decide what to do next on an unsuccessful query. If you want to do something different, like setting a custom error page or kill the site, you need to define the 'db_connection_error' callback in your db-config.php.
== Changelog ==
= 5.3.1 =
* Preserve explicit charset and collation settings during initialization.
* Leave collation unspecified when a custom DB_CHARSET has no DB_COLLATE, allowing the server's compatible default.
* Cached connections adopt later charset and collation changes without adding a charset query to ordinary reuse.
* Check client and server session charsets once per link when the effective charset is empty, rejecting unsupported defaults.
* Improve connection recovery and preserve active MySQLi results during busy-connection probes.
= 5.3.0 =
* Raise the minimum supported WordPress version to 6.4
* Fix unnecessary pings and add retry queries
* Fix that if check_tcp_responsiveness is disabled, time is wasted by looping over all possible servers while the last one is used instead of the first possible one
* Fix PHP 8.4 mysqli_ping deprecation and error code change
* Fix PHP 8.2+ dynamic property deprecation warnings
* Fix backward compatibility for renamed class variables in 5.2.0
* Replace deprecated mysqli_ping() with mysqli_errno() checks for PHP 8.4 compatibility
* Remove wrong duplicate escape
* Prevent "SELECT FOUND_ROWS" possibly returning an unrelated result
= 5.2.0 =
* PHP 8.3 compatibility
* Update default collation to utf8mb4_unicode_520_ci
* Fix a few PHP warnings under some configurations
= 5.0.0 =
* PHP 7.3 compatibility
* Update default collation to unicode_520_ci
* Global cache group, and add caching to TCP connection statuses
* Fix a few PHP warnings under some configurations
* Fix bug causing timeout for ping under some configurations
= 4.1.0 =
* Fix WordPress 4.8.3 SQLi vulnerability
= 4.0.0 =
* Support for custom mu / plugin paths
* Improved WordPress 4.6 capability
* New filter - pre_query
* New action - queried
* Allow db-config.php file to stored in wp-content directory.
= 3.0.0 =
* Improved support for mu-plugins installation location
* Remove APC support for TCP responses (use core caching functions instead)
* Fix typos in documentation
= 2.1.0 =
* Fixed wrong return value for `CREATE`, `ALTER`, `TRUNCATE` and `DROP` queries
* Merge improvements from WordPress core WPDB
* Undefined variable fixes
= 2.0.0 =
* Fork from HyperDB
* Include utf8mb4 support (for WordPress 4.2 compatibility)
* Remove support for WPDB_PATH as require_wp_db() prevents it
= 1.1.0 =
* Extended callbacks functionality
* Added connection error callback
* Added replication lag detection support
= 1.0.0 =
* Removed support for WPMU and BackPress.
* New class with inheritance: hyperdb extends wpdb.
* New instantiation scheme: $wpdb = new hyperdb(); then include config. No more $db_* globals.
* New configuration file name (db-config.php) and logic for locating it. (ABSPATH, dirname(ABSPATH), or pre-defined)
* Added fallback to wpdb in case database config not found.
* Renamed servers to databases in config in an attempt to reduce ambiguity.
* Added config interface functions to hyperdb: add_database, add_table, add_callback.
* Refactored db_server array to simplify finding a server.
* Removed native support for datacenters and partitions. The same effects are accomplished by read/write parameters and dataset names.
* Removed preg pattern support from $db_tables. Use callbacks instead.
* Removed delay between connection retries and avoid immediate retry of same server when others are available to try.
* Added connection stats.
* Added save_query_callback for custom debug logging.
* Refined SRTM granularity. Now only send reads to primaries when the written table is involved.
* Improved connection reuse logic and added mysql_ping to recover from "server has gone away".
* Added min_tries to configure the minimum number of connection attempts before bailing.
* Added WPDB_PATH constant. Define this if you'd rather not use ABSPATH . WPINC . '/wp-db.php'.