Advanced Replication Guide : Updating and maintaining the schema of a distributed system : Upgrading the schema of a distributed system : Upgrading the server version
  
Upgrading the server version
When the solidDB® server is upgraded (for example from version 6.1 to version 6.3), the master server must be upgraded prior to upgrading any replica servers. To ensure that data is converted from the previous format to the newer format, you should start the new server and use either the -x convert or -x autoconvert option on the command line. See section Upgrading solidDB® to a new release level in the solidDB® Getting Started Guide and Appendix solidDB® command line options in the solidDB® Administrator Guide for more details.
Note After the conversion, you cannot use the database with an older server version.
If you are using solidDB® HotStandby, then you must first set the Primary server to PRIMARY ALONE state to allow upgrade of the Secondary server. After the Primary server has been switched to PRIMARY ALONE state, the Secondary server can be shut down and upgraded. After the Secondary is upgraded, it is restarted. After successful catchup, the original Primary is shut down and the Secondary server is immediately switched to PRIMARY ALONE state. The original Primary server can be upgraded while former Secondary runs in PRIMARY ALONE state. Finally, the old Primary is started as a Secondary and runs in catchup mode using the transaction log of the new Primary. For more details, see solidDB® High Availability User Guide.
When you use solidDB® with shared memory access (SMA) or linked library access (LLA), the application typically changes when the schema changes. This means that a new build of the application and the SMA or LLA library might be needed as part of the schema upgrade process.
See also
Upgrading the schema of a distributed system