Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: a solution for hot standby(From BitSuperLab)  (Read 877 times)

0 Members and 1 Guest are viewing this topic.

Offline alt

a solution for hot standby(From BitSuperLab)
« on: July 30, 2014, 05:33:00 AM »

hi, delegates. we have a solution for hot standby.

set up delegate wallet in 2 machines. one is master, and the other is slave.
master run  delegate_loop task at seconds 0,10,20 ....
slave run the task with 5 seconds delay, at 5, 15, 25 .....
Normally master will generate block in time, slave will receive the block less than 5 seconds, than slave will not generate block.
If for some reason, master missed generation, slave didn't receive block from master in 5 seconds, slave will generate.

here is the patch for slave program:
Code: [Select]
--- a/libraries/client/client.cpp
+++ b/libraries/client/client.cpp
@@ -729,6 +729,7 @@ config load_config( const fc::path& datadir )
 
           uint32_t slot_number = blockchain::get_slot_number( now );
           time_point_sec next_slot_time = blockchain::get_slot_start_time( slot_number + 1 );
+          next_slot_time += 5;
           ilog( "Rescheduling delegate loop for time: ${t}", ("t",next_slot_time) );
 
           time_point scheduled_time = next_slot_time;

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Re: a solution for hot standby(From BitSuperLab)
« Reply #1 on: July 30, 2014, 05:52:12 AM »
 +5%  +5%

I want to clarify again that for anyone who are going to try this code, please pay attention that there are *two* nodes, master and slave, with different schedule times but the same slot time!

Looking forward more review ...
« Last Edit: July 30, 2014, 06:05:31 AM by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12172
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: a solution for hot standby(From BitSuperLab)
« Reply #2 on: July 30, 2014, 05:55:14 AM »
Awesome! Never miss a block anymore ..

i guess best practice for the beginning would be to directly connect the mashines to each other

When will this patch be on github?
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline alt

Re: a solution for hot standby(From BitSuperLab)
« Reply #3 on: July 30, 2014, 05:57:25 AM »
Awesome! Never miss a block anymore ..

i guess best practice for the beginning would be to directly connect the mashines to each other

When will this patch be on github?
yes, should add node to the other side.
If it's ok to run like this, maybe we should have a parameter(from 0 to 5)  to setup the delay time.
« Last Edit: July 30, 2014, 05:59:00 AM by alt »

Offline sfinder

  • Hero Member
  • *****
  • Posts: 1205
  • 4 Cores CPU+100GB SSD+anti-DDoS Pro
    • View Profile
Re: a solution for hot standby(From BitSuperLab)
« Reply #4 on: July 30, 2014, 05:54:02 PM »
nice.i will try this out
hi, delegates. we have a solution for hot standby.

set up delegate wallet in 2 machines. one is master, and the other is slave.
master run  delegate_loop task at seconds 0,10,20 ....
slave run the task with 5 seconds delay, at 5, 15, 25 .....
Normally master will generate block in time, slave will receive the block less than 5 seconds, than slave will not generate block.
If for some reason, master missed generation, slave didn't receive block from master in 5 seconds, slave will generate.

here is the patch for slave program:
Code: [Select]
--- a/libraries/client/client.cpp
+++ b/libraries/client/client.cpp
@@ -729,6 +729,7 @@ config load_config( const fc::path& datadir )
 
           uint32_t slot_number = blockchain::get_slot_number( now );
           time_point_sec next_slot_time = blockchain::get_slot_start_time( slot_number + 1 );
+          next_slot_time += 5;
           ilog( "Rescheduling delegate loop for time: ${t}", ("t",next_slot_time) );
 
           time_point scheduled_time = next_slot_time;
微博:星在飘我在找|BTS X 受托人delegate ID:baidu
中国教育书店合作将20%收入捐献给贫困山区学生。
Cooperating with China Education Bookstore and will donate 20% of delegate income to the poor students

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
Re: a solution for hot standby(From BitSuperLab)
« Reply #5 on: July 30, 2014, 08:10:57 PM »
excellent. can even make a new command "wallet_delegate_set_slave {IP_of_master} {true/false}" which will add the node and add a 5 second delay to production
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12172
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: a solution for hot standby(From BitSuperLab)
« Reply #6 on: July 30, 2014, 08:15:02 PM »
excellent. can even make a new command "wallet_delegate_set_slave {IP_of_master} {true/false}" which will add the node and add a 5 second delay to production
Oh yhea .. would make things incredibly easy
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: a solution for hot standby(From BitSuperLab)
« Reply #7 on: July 30, 2014, 08:16:23 PM »
This will likely cause you to sign 2 different blocks.
How you ensure that they will not sign 2 different blocks ?

Offline liondani

Re: a solution for hot standby(From BitSuperLab)
« Reply #8 on: July 30, 2014, 10:04:48 PM »
This will likely cause you to sign 2 different blocks.
How you ensure that they will not sign 2 different blocks ?

This!

and if not, why would bytemaster not decrease the block production time  from 10 to 5 sec. on the next BTSX hard fork?

IS IT POSSIBLE ?  ;D

  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline Fox

Re: a solution for hot standby(From BitSuperLab)
« Reply #9 on: July 30, 2014, 10:13:48 PM »
Usage:
wallet_delegate_set_slave <delegate> <master_node> <delay> <enable>

Enable or disable block production for delegate following delayed block production on master node

Parameters:
  delegate (string, required): The delegate name to slave for (may use ALL for multiple delegates)
  master_node (string, required): The IP and port number of the master delegate node.  (Format IP:PORT)
  delay (int, optional) {0-10} : The delay in seconds the slave will wait for receipt of block production from master (default 5)
  enabled (bool, optional): true to enable block production, else false (default: true)

Returns:
  void
« Last Edit: July 30, 2014, 10:16:31 PM by Fox »
Witness: fox

Offline Fox

Re: a solution for hot standby(From BitSuperLab)
« Reply #10 on: July 30, 2014, 10:25:10 PM »
This will likely cause you to sign 2 different blocks.
How you ensure that they will not sign 2 different blocks ?
Networking the master/slave pair nearest each other will mitigate risks due to propagation delays. However, I do not see an elegant fail safe way with a single master/slave pair to ensure delegate block production.  Introducing additional slaves for consensus building will likely add too much time before the block production window is breached and the next delegate produces on time. 
Witness: fox

Offline alt

Re: a solution for hot standby(From BitSuperLab)
« Reply #11 on: July 31, 2014, 12:03:52 AM »
This will likely cause you to sign 2 different blocks.
How you ensure that they will not sign 2 different blocks ?
yes, this can happen.
If the rule forbid do this, we'll change to  another solution, ensure only 1 node active at the same time.

Offline alt

Re: a solution for hot standby(From BitSuperLab)
« Reply #12 on: July 31, 2014, 12:09:46 AM »
This will likely cause you to sign 2 different blocks.
How you ensure that they will not sign 2 different blocks ?

This!

and if not, why would bytemaster not decrease the block production time  from 10 to 5 sec. on the next BTSX hard fork?

IS IT POSSIBLE ?  ;D


In fact, I run master and slave at the same machine now.
And I add the node to each other to make sure they community with less latency.
for now,  most missed block is because of software issue,  no need to run in two different machine.

And another thing, it's better to  restart slave every 12 hours.
I forgot to set auto restart slave yesterday. my slave run long time, and met the old problem, connection lost much, and sign some wrong blocks...

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12172
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: a solution for hot standby(From BitSuperLab)
« Reply #13 on: August 17, 2014, 06:12:07 PM »
Ok .. I am finally setting up a back delegate with this solution ... python polling is shit :)
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12172
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: a solution for hot standby(From BitSuperLab)
« Reply #14 on: August 17, 2014, 06:37:27 PM »
Not sure if I did sth. wrong but by backup delegate produced a fork .. so it seems it does not work as intended... does the backup notice that a valid block is allready there and stops the production?
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

 

Google+