Update to v 1.6.5

M

marc8lange

New Member
Oct 29, 2018
25
2
3
Hello.

Started the HA update process as in https://www.fspbx.com/docs/updates/

Started by pausing syncthing, then on HA backup (secondary) server running
git pull
php artisan app:update
The HA server update ran and i confirmed FSPBX ow reading 1.6.5 in GUI

Then ran
git pull
php artisan app:update on main HA server and logged out and back in to FSPBX gui and GUI still reads 1.5.0

Cleared browsers cache and tried diff browser, still readin 1.5.0 on main HA server GUI

I ran git pull and php artisan app:update again on main server no change - update not sticking on main server only?

Suggestions for next steps?
 
Logs of main server dring the update show:

"php artisan app:update
Updating cec7d2a6..7a574429
error: Your local changes to the following files would be overwritten by merge:
app/Models/FaxFiles.php
install/setup_logical_replication.sh
Please commit your changes or stash them before you merge.
Aborting
Starting update..."
 
If I recall many months ago we were troubleshooting a time zone issue with Fax and our initial logical_replication also may have some customization since we use different passwords for fusionpbx database...could these customizations be messing up the update?

On the main HAs server should I push the following safely?:

git stash
git pull
git stash pop
php artisan app:update
 
Run these

git stash
git pull
php artisan app:update

Then make sure you run the migration commands in the correct order as per our official instructions.

You don’t need to stop Syncthing before updates.
 
updates seem to now work on FSPBX - however, the following error:

Querying subscriptions on connection: pgsql
Subscriptions to refresh:
- fspbx_subscription_b_to_a
Executing: ALTER SUBSCRIPTION "fspbx_subscription_b_to_a" REFRESH PUBLICATION;
Error: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "public.vm_notify_attempts" does not exist (Connection: pgsql, SQL: ALTER SUBSCRIPTION "fspbx_subscription_b_to_a" REFRESH PUBLICATION;)
 
Error is on main server A.

On server B I did the followin:
php artisan migrate:delete-last-batch
php artisan migrate

The back on server A i did:
php artisan db:refresh-subscriptions
and got the error.

One server B i did php artisan db:refresh-subscriptions and got no error
however here is server B msgs:
Querying subscriptions on connection: pgsql
Subscriptions to refresh:
- fspbx_subscription_a_to_b
Executing: ALTER SUBSCRIPTION "fspbx_subscription_a_to_b" REFRESH PUBLICATION;
Refreshed: fspbx_subscription_a_to_b
All done.

I was expecting server B to do a subscription from b_to_a when in fact it seems like it did an a_to_b
 
What may be causing the confusion is the use of the labels Server A and Server B. Those labels are not important by themselves. What matters is the order in which the steps are performed. To make this clearer, it is better to think in terms of the actual server locations, such as Miami and New York.

For example, if the update is started on the Miami server, run:

Code: 
php artisan migrate

Then switch to the New York server and run:
Code: 
php artisan migrate:delete-last-batch
php artisan migrate

After that, run the following command on both servers:
Code: 
php artisan db:refresh-subscriptions
If, instead, the update is started on the New York server, then the process is reversed.

On New York:
Code: 
php artisan migrate
Then on Miami:

Code: 
php artisan migrate:delete-last-batch
php artisan migrate

In other words, after running the migration on the first server in the cluster, the second server is always the one where you run both:

Code: 
php artisan migrate:delete-last-batch
php artisan migrate

So the key factor is the sequence, not whether a server is labeled A or B.

Please correct me if I am mistaken. I believe you have a support plan, so if you run into any issues, please feel free to reach out and we will help ensure the update is applied correctly.
 
You must log in or register to reply here.
Top Bottom