PIXILAB Wiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
blocks:server:mirror [2021-11-21 15:17] – Added some implementation notes adminblocks:server:mirror [2025-10-01 09:53] (current) – [Introduction] admin
Line 1: Line 1:
 ====== Blocks Mirroring Service ====== ====== Blocks Mirroring Service ======
  
-Our Linux-based server (dated 2020-05-25 and later, running Ubuntu 20.04), supports a redundancy feature for increased system reliability. While the Blocks server software is very robust, the complete system can never be more reliable than the hardware it runs on.+Our Linux-based server supports a hardware redundancy feature for increased system reliability. While the Blocks server software is very robust, the complete system can never be more reliable than the hardware it runs on.
  
 ===== Introduction ===== ===== Introduction =====
Line 21: Line 21:
 However, if your Blocks server dies, and won't come back by turning power off and back on again, things are a bit more difficult. Assuming you have an up-to-date backup of your Blocks root directory, as well as other relevant server settings, you can replace the server with a new one, and bring it back to life using those backups. However, that may take a while to accomplish, rendering your entire Blocks installation non-functional in the meantime. However, if your Blocks server dies, and won't come back by turning power off and back on again, things are a bit more difficult. Assuming you have an up-to-date backup of your Blocks root directory, as well as other relevant server settings, you can replace the server with a new one, and bring it back to life using those backups. However, that may take a while to accomplish, rendering your entire Blocks installation non-functional in the meantime.
  
-A better option is to have a spare server sitting in the rack all along, just as suggested for the main switch above. If you're sufficiently concerned about your system's reliability to keep such a spare on hand, this new feature is for you.+A better option is to have a spare server sitting in the rack all along, just as suggested for the main switch above. If you're sufficiently concerned about your system's reliability to keep such a spare on hand, this feature is for you.
  
 {{ :blocks:server:mirror:mirroring.jpg?nolink |}} {{ :blocks:server:mirror:mirroring.jpg?nolink |}}
  
-The new Blocks Mirroring Service will keep your spare computer up to date with any changes applied to Blocks. As soon as you make any changes, such as editing a block or adding a new spot, those changes are copied across to the mirror server. Note, in the illustration above, that the main Blocks server is still connected and used as it was in the stand-alone illustration shown at the beginning of this article. The Mirror server uses a //second// network port as a backdoor connection to your Blocks server. This backdoor is used as a secure channel for copying all changes across as the system runs. +The Blocks Mirroring Service will keep your spare computer up to date with any changes applied to Blocks. As soon as you make any changes, such as editing a block or adding a new spot, those changes are copied across to the mirror server. Note, in the illustration above, that the main Blocks server is still connected and used as it was in the stand-alone illustration shown at the beginning of this article. The Mirror server uses a //second// network port as a backdoor connection to your Blocks server. This backdoor is used as a secure channel for copying all changes across as the system runs. 
  
 Furthermore, the Mirror Server is en exact copy of the main Blocks Server. All its settings and configurations are identical. The only difference between the two is which one has the Blocks license key. The license key controls which of the two computers that run Blocks. Apart from this difference, they're identical. Furthermore, the Mirror Server is en exact copy of the main Blocks Server. All its settings and configurations are identical. The only difference between the two is which one has the Blocks license key. The license key controls which of the two computers that run Blocks. Apart from this difference, they're identical.
Line 268: Line 268:
   * Server Disk Space. Indicates the amount of free space on the Blocks Server itself. This also makes sens to keep an eye on – especially before adding a significant amount of new content.   * Server Disk Space. Indicates the amount of free space on the Blocks Server itself. This also makes sens to keep an eye on – especially before adding a significant amount of new content.
   * Server Time. Shows the current time of the clock in the Blocks Server. If your server has Internet access, this is generally adjusted automatically. If not, you may want to check this every few monts to make sure that it is reasonably accurate.   * Server Time. Shows the current time of the clock in the Blocks Server. If your server has Internet access, this is generally adjusted automatically. If not, you may want to check this every few monts to make sure that it is reasonably accurate.
 +  * Sync Errors. Cumulative count of data sync errors that have occurred, if any. Check the Mirror log file for details.
  
-The SYNCHRONIZE NOW button can be used to force a full synchronization. Use this after making manual changes to the files in the /home/pixi-server directory of the Blocks server, such as updating Blocks itself or the mirroring service (the files PIXILAN.jar and MIRROR.jar respectvely). Doing so pushes those changes over to the Mirror Server immediately rather than waiting for the next scheduled full synchronization.+The "Synchtronize Now" button can be used to force a full synchronization. Use this after making manual changes to the files in the /home/pixi-server directory of the Blocks server, such as updating Blocks itself or the mirroring service (the files PIXILAN.jar and MIRROR.jar respectvely). Doing so pushes those changes over to the Mirror Server immediately rather than waiting for the next scheduled full synchronization.
  
 ===== Testing the Mirror Server ===== ===== Testing the Mirror Server =====
Line 327: Line 328:
   * Set fullSyncOnStartup to //true// to run a full synchronization once when mirroring service is started.   * Set fullSyncOnStartup to //true// to run a full synchronization once when mirroring service is started.
   * Set java.util.logging.FileHandler.level to //ERROR// for less verbose logging, or //INFO// for more details (sometimes useful when troubleshooting).   * Set java.util.logging.FileHandler.level to //ERROR// for less verbose logging, or //INFO// for more details (sometimes useful when troubleshooting).
 +
 +The following additional, advanced settings are available in version 7.1 and later, then specified under the "mirror:" heading as shown above. 
 +
 +<code>
 +  interface: enp2s0
 +  subnet: 192.168.0.0/24
 +</code>
 +
 +:!: **NOTE**: There are two spaces at the beginning of each line, as required when used under the "mirror:" heading.
 +
 +  * The //interface// setting is useful if your computer have more than one network interface with link local addressing. If so, use this setting to specify the name of the desired synchronization backdoor network interface.
 +  * The //subnet// setting lets you specify a non link local subnet (in CIDR notation) for use as the data synchronization backdoor. This is useful in cases where you may want to use this interface for other purposes, such as remote management of the servers. You would then either set fixed addresses (within the specified subnet) or use dynamically assigned addresses (DHCP).
 +
  
 The settings under //logging// follow the java.util.logging standard, sometimes referred to as JUL, allowing you to use any settings available there, for example to log to an external log handler. The settings under //logging// follow the java.util.logging standard, sometimes referred to as JUL, allowing you to use any settings available there, for example to log to an external log handler.
 +
 +
 +=====Troubleshooting=====
 +Unless the advanced //subnet// setting is used (see above), the server-to-server backdoor connection assumes the use of self-assigned ("link local") addresses. Such adresses are in the 169.254.x.x address range. There must not be any additional network interfaces in either computer having such IP addresses. If there are, do either of the following:
 +  * Disable any such interface(s). in some cases this may need to be done in the computer's BIOS settings.
 +  * Change their addresses to keep them out of this address range.
 +  * Use the advanced //interface// setting to specify which interface to use. 
 + 
 +=== Verifying over SSH ===
 +The mirroring service shows its status window while running, as described above. If you're accessing your server using a terminal session over SSH, you can instead use this command to ascertain whether the mirroring service is running, while being logged in as the pixi-server user:
 +
 +<code>
 +systemctl --user status blocks.mirror
 +</code>
 +
 +=== Custom path to Blocks' Executable Files ===
 +The Mirror service assumes that the main Blocks executable file (named "PIXILAN.jar") is located in /home/pixi-server/, which is the case if you're using our Linux server image. However, if you're configuring a server on your own and chose to locate Blocks executable files elsewhere, you must specify the directory where PIXILAN.jar resides using the BLOCKS_HOME envirtonment variable. This is an advanced configuration option, and is normally not required.
  
 =====Implementation Notes===== =====Implementation Notes=====
Line 347: Line 378:
  
 ===Starting/stopping Blocks=== ===Starting/stopping Blocks===
-The Linux //systemd// feature is used to start and manage most programs that aren't started manually. This includes Blocks as well as the Mirroring service. You can see how this is done inside the start.sh and stop.sh scripts located in the home directory of the pixi-server user. When //not// using the mirroring service, systemd directly starts and manages Blocks. +The Linux [[https://en.wikipedia.org/wiki/Systemd|systemd]] feature is used to start and manage most programs that aren't started manually. This includes Blocks as well as the Mirroring service. You can see how this is done inside the start.sh and stop.sh scripts located in the home directory of the pixi-server user. When //not// using the mirroring service, //systemd// directly starts and manages Blocks. 
  
-However, when using the mirroring service, systemd starts the mirroring service (referred to by the name //blocks.mirror//). Then, when appropriate (i.e., when the license key is connected) the mirroring service starts Blocks. Likewise, if the license key is connected (e.g., to be moved to the other server), the mirroring service shuts down Blocks. Here, systemd isn't directly responsible for starting/stopping Blocks. Therefore, viewing its systemd status (e.g. using the //systemctl --user status blocks// command) will show its status as inactive, even though it's running. Other system commands can be used to look at running processes. +However, when using the mirroring service, //systemd// starts the mirroring service (referred to by the name //blocks.mirror//). Then, when appropriate (i.e., when the license key is connected) the mirroring service starts Blocks. Likewise, if the license key is disconnected (e.g., to be moved to the other server), the mirroring service shuts down Blocks. Here, //systemd// isn't directly responsible for starting/stopping Blocks. Therefore, viewing its //systemd// status (e.g. using the //systemctl --user status blocks// command) will show its status as inactive, even though it's running. Other system commands can be used to look at running processes.
- +
-===Troubleshooting=== +
-The mirroring service shows its status window while running, as described above. If you're accessing your server using a terminal session over SSH, you can instead use this command to ascertain whether the mirroring service is running, while being logged in as the pixi-server user: +
- +
-<code> +
-systemctl --user status blocks.mirror +
-</code>+
  
 The mirroring service also generates its own log, found in the logs directory inside your Blocks root directory. Check these log files if you encounter any problems related to the mirroring service. The mirroring service also generates its own log, found in the logs directory inside your Blocks root directory. Check these log files if you encounter any problems related to the mirroring service.