The database architecture
Liferay Portal requires storing its data on database systems. It is possible to store custom portlet data in a separate database. But for the core features of Liferay Portal, we need to connect Liferay with a database. In our reference architecture, we suggested using the MySQL cluster for this purpose. In this section, we will talk about various deployment strategies for the database server.
The read/write database
In case of transaction-centric applications, it is a good idea to separate read and write databases. In this situation, all write transactions will be executed on the write database and all read transactions will be executed on the read-only database. Using database replication mechanism, data from the write database is replicated to the read database. By using this mechanism, we can optimize the write database to perform extensive write transactions and the read database to perform extensive read transactions. Liferay Portal supports configuring read and write databases through portal-ext.properties
. Here are some high-level steps to configure the read/write database through portal-ext.properties
.
In
portal-ext.properties
, append the following value at the end of original values. This configuration change will load the following spring configuration file during startup and load the rest of the read/write database properties:spring.configs=<Existing config files>, META-INF/dynamic-data-source-spring.xml
Add the following properties to
portal-ext.properties
to configure the read database:jdbc.read.driverClassName=<Read Database Driver Class Name> jdbc.read.url=<Read Database JDBC URL> jdbc.read.username=<Read Database User Name> jdbc.read.password=<Read Database Password>
Add the following properties to
portal-ext.properties
to configure the write database:jdbc.write.driverClassName=<Read Database Driver Class Name> jdbc.write.url=<Read Database JDBC URL> jdbc.write.username=<Read Database User Name> jdbc.write.password=<Read Database Password>
Tip
If data sources are configured through JNDI, we need to configure the
jdbc.read.jndi.name
andjdbc.write.jndi.name
properties respectively for the read data source and the write data source.
Database sharding
Database sharding is the architectural solution to separate the data of same the tables in multiple database instances. Liferay supports this feature. Liferay Portal can be used to host multiple portals within the same portal server using Portal Instances (Companies). By default, Liferay Portal stores data of all the instances in the same database. If we are hosting multiple portals using portal instances, the same tables will have data from multiple instances. Gradually, tables will grow rapidly because of the data from multiple portals. At some point in time, this will affect the performance as tables grow rapidly, and for any request internally the system will need to scan the data of all instances. We can configure multiple database shards (separate databases), and we can provide how shards should be chosen. Depending on the shard selection algorithm, each portal instance will be mapped to a specific shard database. By using this architectural approach, data from multiple instances will be distributed in multiple databases. By default, Liferay supports configuring three shards. But we can add more shards by changing configuration files. We can enable database sharding by changing portal-ext.properties
. Here are some high-level steps to configure database sharding:
Append the following property in
portal-ext.properties
to enable database sharding:spring.configs=<Existing config files>, META-INF/shard-data-source-spring.xml
Configure database shards by adding the following properties in
portal-ext.properties
:#Shard 1 jdbc.default.driverClassName=<Database Driver Class Name for shard 1> jdbc.default.url=<Database JDBC URL for shard 1> jdbc.default.username=<Database User Name for shard 1> jdbc.default.password=<Database Password for shard 1> #Shard 2 jdbc.one.driverClassName=<Database Driver Class Name for shard 2> jdbc.one.url=<Database JDBC URL for shard 2> jdbc.one.username=<Database User Name for shard 2> jdbc.one.password=<Database Password for shard 2> #shard 3 jdbc.two.driverClassName=<Database Driver Class Name for shard 3> jdbc.two.url=<Database JDBC URL for shard 3> jdbc.two.username=<Database User Name for shard 3> jdbc.two.password=<Database Password for shard 3>
Tip
If we want to add more than three shards, we will need to provide our own
shard-data-source-spring.xml
with more than three shards, and we need to provide s similar configuration inportal-ext.properties
for those additional shards.
By default, shards will be assigned to each portal instance based on the round ribbon algorithm. Liferay also supports the manual selection algorithm. This algorithm allows for the selecting of a specific shard through the control panel. To enable the manual shard selection algorithm, we need to add the following property in portal-ext.properties
:
shard.selector=com.liferay.portal.dao.shard.ManualShardSelector