Automated Backups

[ataylor]

This feature is basically to make HA as transparent as possible. When a live server starts it will be able to request that another live server will start a backup that will be colocated and serve its needs. Since the configuration for HA is now becoming more complex I was going to add a new configuration in the main config file that would look something like.

   <ha-policy>

      <request-backup>true</request-backup>

      <backup-request-attempts>-1</backup-request-attempts>

      <backup-request-retry-interval>5000</backup-request-retry-interval>

      <backup-request-type>SHARED_STORE</backup-request-type><!--or REPLICATED-->

      <allow-backup-request>true</allow-backup-request>

      <max-backups>2</max-backups>

      <backup-port-offset>100</backup-port-offset>

      <backup-strategy>SCALE_DOWN</backup-strategy>

   </ha-policy>

we could also move the current HA config in here as well, backup, shared-store etc.

I was thinking of also adding some templates so something like:

<ha-policy template="AUTOMATIC_SHARED_STORE"/>

and we could add templets like AUTOMATIC_SHARED_STORE, AUTOMATIC_REPLICATION, LIVE_ONLY, BACKUP_ONLY_SHARED_STORE etc

any thoughts?

[jbertram]

I like the idea of consolidating the HA configuration to a sub-element.  However, it seems like you'd need to add something to identify the location of the backup (e.g. cluster-connection-name or connector-ref).

Some of the other details are fuzzy too.  For example, would the REPLICATED <backup-request-type> require a <max-backups> = 1 or would we add the ability to have > 1 replicated backups?

Also, how does the SCALE_DOWN <backup-strategy> fit with the different choices for <backup-request-type>?

This would all need thorough and clear documentation.

[ataylor]

I like the idea of consolidating the HA configuration to a sub-element.  However, it seems like you'd need to add something to identify the location of the backup (e.g. cluster-connection-name or connector-ref).

well for now we use the default cluster connection which covers 99.999% of scenarios (not sure if anyone deploys multiple clusters cons). from this we connct to the cluster and request a backup.

Some of the other details are fuzzy too.  For example, would the REPLICATED <backup-request-type> require a <max-backups> = 1 or would we add the ability to have > 1 replicated backups?

yes multiple backups

Also, how does the SCALE_DOWN <backup-strategy> fit with the different choices for <backup-request-type>?

well it should work with any apart from LIVE_ONLY obviously.

This would all need thorough and clear documentation.

indeed, but yes there will be several configs, which is why i suggested having default templates for each.

[mnovak]

In domain mode (Wildfly/EAP) it'd be great to have one profile for all "live" servers and one profile for all "backup" servers. So it's easy to scale without big configuration burden. At this moment there must be one profile per one live or backup server. There is problem how to specify unique shared store for each live/backup pair. For replication this would also require to specify unique backup-group-name for each live/backup pair.

[synclpz]

Hi there, did any features you described are implemented or at least filed in jira?